<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 3, 2015 at 12:44 PM, Esteban A. Maringolo <span dir="ltr"><<a href="mailto:emaringolo@gmail.com" target="_blank">emaringolo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">2015-10-03 12:35 GMT-03:00 Mariano Martinez Peck <<a href="mailto:marianopeck@gmail.com">marianopeck@gmail.com</a>>:<br>
> On Sat, Oct 3, 2015 at 10:10 AM, Johan Brichau <<a href="mailto:johan@inceptive.be">johan@inceptive.be</a>> wrote:<br>
>><br>
>> They only way I can think of is to store a session id in the browser<br>
>> sessionStorage, which is unique to each tab.<br>
>> However, I do not think anyone has done so yet.<br>
<br>
> Thanks for the idea, I wasn't aware of the sessionStorage. I will read about<br>
> it.<br>
<br>
</span>The problem with this is how you add the session parameter to requests<br>
(both full and xhr ones)<br>
<span class=""><br>
<br>
>> The question that pops to my mind is: why do you want to hide the _s in<br>
>> the url? If this is about security, it’s probably because you do not want<br>
>> someone to copy/paste the url and hijack the session?<br>
<br>
> Exactly.<br>
<br>
<br>
>> You can prevent that by not using the session to track authentication, but<br>
>> a cookie. In other words:<br>
>> - use a cookie for authentication (i.e. always require the cookie to be<br>
>> present)<br>
>> - keep _s for session tracking<br>
>> -> a user will need both the session id in the url _and_ the cookie to<br>
>> work<br>
<br>
> That's exactly what I ended up doing. But I wanted to be able to have<br>
> multiple sessions so the same cookie keeps a list of active sessions. Also,<br>
> the session ID stored in the cookie are not the plain session ID because<br>
> otherwise it would be very simple to hack. So when a new session ID is<br>
> created I create another random token and I store that in a table at server<br>
> side. And yes, I keep using _s for tracking. For this, I made a subclass of<br>
> WAHandlerTrackingStrategy.<br>
<br>
> Then I had to make a request filter that would get the session ID from the<br>
> _s and check if there is a cookie that holds a correct "token" for that<br>
> cookie.<br>
><br>
> If someone else is interested in this code I can share it. Even more if a<br>
> "seaside dev" guy could take a brief look since I suspect I may be missing<br>
> scenarios (like document handler expiration vs session expiration).<br>
<br>
</span>Not a Seaside Dev guy, but if you share it I'll take a look at it.<br></blockquote><div><br></div><div>Great, I will package it a bit better and do a "cleaning" pass since I made it work Friday afternoon ;)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I think that for preventing session hijacking you don't need to remove<br>
the _s parameter from the query arguments, but instead *add* new<br>
information about the particular client to the session tracking in the<br>
server, like IP, some sort of UA fingerprint, etc.<br>
<br></blockquote><div><br></div><div>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. </div><div><br></div><div>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?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
So if somebody hijacks the session ID, it will be rejected by the<br>
server because it's coming from a different client other than the one<br>
that initiated the session.<br>
<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>Exactly, that's what my cookie filter does. </div><div><br></div></div><div><br></div>-- <br><div class="gmail_signature">Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br></div>
</div></div>