Re: mailmam, web bridge, forum, p2p

[tomas]

On Sun, Oct 27, 2019 at 01:32:54AM -0400, Mike Gerwitz wrote:

[...]

> > 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 [...]

> Since I was in the mindset of leaking information, I forgot to mention
> another negative side-effect of including tokens as query strings: it
> can turn link sharing into a weapon using session fixation.  E.g. I
> could create an account, send a link to you with my session token, and
> you may then be logged into my account.

Actually there are two scenarios: User A (say Alice) "has" the session
and passes a link to B (Bob), session token included.

This could be negligence, and now Bob might do something nasty with
Alice's session (e.g. go into a shopping spree)...

>                                          The user may then perform an
> action that may benefit the attacker (or the action could be part of the
> URL).

...but you seem to imply that there's a reverse scenario, where Alice
does something nasty to Bob?

> This is sometimes used as a poor-man's SSO. :x  It can also work with
> POSTs: direct the user to an auto-submitting form.

Yes, you could take your "session token" with you, to another computer,
but this seems somewhat fragile [1].

> Cookies are better suited for storing session tokens---you cannot set
> cookie values for other domains without some other type of exploit
> (e.g. XSS, but your cookies best be set to HTTP-only to mitigate that).

Cookies are, after all, client-side data. The browser might not allow
you to do something, but you can engineer all sort of HTTP requests:
that means the server has to do its own sanity checks anyway.

Cheers

[1] That's why I'd go for a fairly strict session expiry; perhaps
   (but I haven't played with it in practice!) you'd need transaction
   tokens instead (as those continuation based thingies use), which
   can be even more short-lived. Perhaps even some correlation
   between token and client profile (IP address, etc.).

-- tomás

signature.asc
Description: Digital signature