[Seaside] Session tracking without URL field yet supporting "multi session"

[Esteban A. Maringolo]

2015-10-03 12:55 GMT-03:00 Mariano Martinez Peck <marianopeck at gmail.com>:

>> I think that for preventing session hijacking you don't need to remove
>> the _s parameter from the query arguments, but instead *add* new
>> information about the particular client to the session tracking in the
>> server, like IP, some sort of UA fingerprint, etc.
>>
>
> Exactly. Note that I discarded the IP filter (WAProtectionFilter) because it
> would be a pain for users. Imagine they move to another network, they move
> from house to work, they connect / disconnect from VPN, ISP assigning new
> IP, etc..and you loose sessions. At least for my app a session may contains
> LOTS of tabs for lots of current work. And my session expirations are about
> 2 hours. So... for MY usecase, adding IP filter is not worth.

Roaming users are a problem for IP filtering.

> What I indeed was thinking BESIDES adding that cookie thingy we are
> discussing here, is to add a WAUserAgentFilter (very very very easy to
> code), which would also make sure about user agent. From what I thought, it
> will only "loose" sessions in case the user updates the browser, which
> happens every in a while. But I am still not 100% convinced. I thought this
> could be cool if someone could still the cookies from a stolen machine or
> whatever. But... what I think is that if someone can have access to cookies
> of another machine, he could likely browse the app from there. Not sure.
> Thoughts?

UA is very easy to spoof, so not realiable at all to be used as the
only part in an auth token (together with _s, of course).

I think there is no way to have it both ways, it is... being able to
have "one session per tab" in your browser, and also having a single
session token that survives the browser session.

Local storage is just a dictionary, and it will be readable by ANY
user of the browser, so it is very much like Cookies in this sense,
with the added part of requiring to recover the session token from it
before performing any HTTP request, and being recoverable not only by
your site, but with anybody
with access to the browser.
Session storage is localStorage but just for the tab session, so it
isn't available when you want to restart the session.

It's challenging, and maybe there is a trick to overcome this, but you
have to decide whether it is worth chasing it.

>> So if somebody hijacks the session ID, it will be rejected by the
>> server because it's coming from a different client other than the one
>> that initiated the session.

> Exactly, that's what my cookie filter does.

And that's what most websites does. Ever tried to access Facebook from
the Tor network? :)

Regards!

--
Esteban.

ps: I love authentication as domain, so I'll help think about this if
you decide to go for it :D