I am not dismissing your scenarios outright as I never said that the method was foolproof and I also said that only SSL will give you something close to that.
Also lets not forget that if the user manages to be lured to an attackers site via a link in an email for instance and then doesn't notice that they are then redirected to another site then they have bigger problems than having their session hijacked lol. However, there are ways to mitigate even the cross-subdomain attack that you use as an example... On Fri, Feb 25, 2011 at 2:20 PM, Thomas Broyer <t.bro...@gmail.com> wrote: > This is where you fail to understand me: you make the assumption that the > "authentication process" takes place, while I'm talking about bypassing it > with a session-fixation attack. I understood perfectly, Thomas. To reiterate, the attacker will have had to authenticate in order to acquire a valid sid which he then stores and waits in prey for the user to respond to his email with a link to his site. When the user takes the bait and visits the attacker's site the attacker redirects the user to another site including the sid as a query parameter. One possible scenario (easily mitigated through the use of your own domain > name): > *Attacker*: authenticates to victim.example.com, grabs the cookies in use, > store them at attacker.example.com (note: same domain, different > subdomains, much like appspot.com hosted apps) > At this point the request hits the server and the session id is set the query parameter, the same one as the attackers. This attack can be mitigated by changing the session ID when users logs in and to additionally require the user to authenticate on every important request. A pain in the rear for the user of course but it will largely work. The fact that it does work is due to the reluctance to require users to log in for every important request. Sure enough, even if you used SSL it would require that every request uses it in order to be close to 100% protected from this kind of attack. The only sites I know that do that are some banks. I believe Citibank does for instance. Interestingly I believe Facebook announced that they will be rolling this out to all their members. It will be interesting to see how it affects the performance of their site. Perhaps requiring every one to use SSL for every request is the right approach. Maybe we should all be going in that direction but service providers might be loathe to provide this service as it adds additional demands on their servers that they might not be able to handle and the users might complain because of the increased latency. Perhaps using HttpOnly headers would also mitigate this kind of attack. I don't think App Engine supports it though but I wish it did. The bottom line is this, it really comes down to a multi-faceted approach to security. One big wall isn't going to cut it and the more obstacles put up the less chances are that some malcontent will be successful. -- *Jeff Schwartz* http://jefftschwartz.appspot.com/ http://www.linkedin.com/in/jefftschwartz follow me on twitter: @jefftschwartz -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
