On Friday, February 25, 2011 6:39:40 PM UTC+1, Jeff wrote: > > > > On Fri, Feb 25, 2011 at 12:30 PM, Thomas Broyer <[email protected]> wrote: > >> You contradict yourself (compare the HttpSession's ID with the auth token >> –the HttpSession is maintained by a cookie, whose value generally is the >> session's ID– vs. do not send the auth token in a cookie), but that's not >> the problem. > > > Actually I am not contradicting myself, Thomas. You just failed to > understand! >
And the other way around! ;-) The problem is: how are you initializing the auth token on the client side, >> and how you associate it with the user on the server-side? The client and >> server have to share some knowledge at some point, and if you have use "form >> based" authentication on another web page (i.e. your app's host page is >> protected and cannot be accessed without being authenticated), then the only >> way (not accurate, but that's how 99.999% of auth is done, because the >> alternative comes with a UX penalty) to "transfer" the authentication from >> the login page to the app's page is to use either a cookie or pass a unique >> token in the URL, both of which can be hijacked. >> > > If the user is authenticated the authentication process should then send > down the HttpSession id as part of the payload back to the client. The > client then stores the session id it receives as part of the payload from > the server as a local cookie. > 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. 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) *Victim*: goes to attacker.example.com, which sets the cookies with Domain=.example.com and redirects it to victim.example.com The victim's browser sends the cookies to victim.example.com (because of Domain=.example.com, they apply, even though they've been set by attacker.example.com) The victim is then authenticated to victim.example.com with the *same session* as the attacker. The session id is sent down to the client as part of the payload, but it's too late. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
