Re: mailmam, web bridge, forum, p2p

[tomas@tuxteam.de]

[-- Attachment #1: Type: text/plain, Size: 2767 bytes --]

On Sun, Oct 27, 2019 at 12:50:17AM -0400, Mike Gerwitz wrote:
> To make sure I see replies, please include me in the recipient list (not
> just the mailing list).  I missed this at first.
> 
> On Sat, Oct 26, 2019 at 09:48:37 +0200, tomas@tuxteam.de wrote:
> >> Passing session tokens via GET requests is a bad idea, because that
> >> leaks the token.
> >
> > Even in https?

Thanks for this complete account. I appreciate it very much!

> Transport is only part of the problem.
> Query parameters are also leaked to webserver access logs;

That's true -- but I'd call that "category B". The server realm
is full with sensitive data, and the logs are part of that.

> they can leak to 3rd party logs via the referrer header (I
> sometimes see sensitive data in my webserver logs from other
> domains);

That's more serious ("category A") -- third parties get to look
into sensitive data. The application has to take care of links
pointing to the "outside".

If we're trying to pull off this, we'll have to think hard
about this one.

> they're retained in browser history and written to disk;

Again "category B". The browser's cookie jar is, after all,
also there for all to see. As a forensics analyst or a data
"thieve", I'd take with me the whole browser subdir, anyway.

> may show up in proxy logs (e.g. when passing through load
> balancers); could be easily pasted unwittingly to third parties (e.g. a
> user sharing a link with someone else); etc.

Only for plain http (unless it's one of those corporate proxies
with an "open-all" root certificate, that is).

> Back in what feels like a previous lifetime by now, I used to do a lot
> of work with phpBB2, which had an option to either store sessions in
> cookies or place PHPSESSID in the URL.  It modified every link to
> include a session id.  It tried to mitigate the issue by checking the
> source IP address, but if you were logged on the same network (e.g. in
> the same place of employment; school; library; etc), then sharing a link
> would lead to session hijacking.

This all is in the context of plain http, I guess.

> Such link rewriting schemes also cause other types of problems.  For
> example, you may be able to cache most of the generated HTML (except for
> e.g. the header) regardless of what user is logged in.  But if you have
> to inject tokens into all links, that type of caching isn't useful.

Yes. But this has lost most of its bite in the last decade or
so. Machines have increased in power (speed, RAM) faster than
the network. Apart from really high-volume sites, where you
start thinking about load balancers, CDNs, etc. I think a bit
of server-side template substitution will drown in the noise.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]