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?

Transport is only part of the problem.  Query parameters are also leaked
to webserver access logs; they can leak to 3rd party logs via the
referrer header (I sometimes see sensitive data in my webserver logs
from other domains); they're retained in browser history and written to
disk; 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.

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.

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.

-- 
Mike Gerwitz