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

[Mariano Martinez Peck]

On Sat, Oct 3, 2015 at 12:44 PM, Esteban A. Maringolo <emaringolo at gmail.com>
wrote:

> 2015-10-03 12:35 GMT-03:00 Mariano Martinez Peck <marianopeck at gmail.com>:
> > On Sat, Oct 3, 2015 at 10:10 AM, Johan Brichau <johan at inceptive.be>
> wrote:
> >>
> >> They only way I can think of is to store a session id in the browser
> >> sessionStorage, which is unique to each tab.
> >> However, I do not think anyone has done so yet.
>
> > Thanks for the idea, I wasn't aware of the sessionStorage. I will read
> about
> > it.
>
> The problem with this is how you add the session parameter to requests
> (both full and xhr ones)
>
>
> >> The question that pops to my mind is: why do you want to hide the _s in
> >> the url? If this is about security, it’s probably because you do not
> want
> >> someone to copy/paste the url and hijack the session?
>
> > Exactly.
>
>
> >> You can prevent that by not using the session to track authentication,
> but
> >> a cookie. In other words:
> >> - use a cookie for authentication (i.e. always require the cookie to be
> >> present)
> >> - keep _s for session tracking
> >> -> a user will need both the session id in the url _and_ the cookie to
> >> work
>
> > That's exactly what I ended up doing. But I wanted to be able to have
> > multiple sessions so the same cookie keeps a list of active sessions.
> Also,
> > the session ID stored in the cookie are not the plain session ID because
> > otherwise it would be very simple to hack. So when a new session ID is
> > created I create another random token and I store that in a table at
> server
> > side. And yes, I keep using _s for tracking. For this, I made a subclass
> of
> > WAHandlerTrackingStrategy.
>
> > Then I had to make a request filter that would get the session ID from
> the
> > _s and check if there is a cookie that holds a correct "token" for that
> > cookie.
> >
> > If someone else is interested in this code I can share it. Even more if a
> > "seaside dev" guy could take a brief look since I suspect I may be
> missing
> > scenarios (like document handler expiration vs session expiration).
>
> Not a Seaside Dev guy, but if you share it I'll take a look at it.
>

Great, I will package it a bit better and do a "cleaning" pass since I made
it work Friday afternoon ;)


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

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?



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


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20151003/7dd51479/attachment-0001.htm