You are talking about using request cookies so of course the scenario you describe might be possible. Everyone knows they are vulnerable and hence their ease of hijacking. The right way to do it is not using request cookies at all on the server because they cannot be trusted - the auth token must be delivered to the server as part of the payload and it must never be read from a request cookie.
On Fri, Feb 25, 2011 at 11:38 AM, Thomas Broyer <t.bro...@gmail.com> wrote: > > > On Friday, February 25, 2011 3:21:18 PM UTC+1, Jeff wrote: > >> Hi Thomas, >> >> >> On Fri, Feb 25, 2011 at 8:49 AM, Thomas Broyer <t.br...@gmail.com> wrote: >> >>> Of course! I didn't mean to imply that you shouldn't secure your app, but >>> honestly if someone succeeds in hijacking your session, then he could >>> possibly do it before loading the host page, so that your GWT app will run >>> with the hijacked session, and the "auth token in the request payload" won't >>> be of any help. >> >> >> First off, the hacker couldn't have access to the local cookie on the >> user's machine unless the user has been infected with a virus. If the user's >> computer has been infected with a virus that can some how target local >> cookies then this user has a lot more to worry about than someone hijacking >> their session. So let's rule that scenario out. >> > > I can setup an web page at attacker.appspot.com that sets a cookie with > Domain=.appspot.com, and it'll target every appspot.com app out there. If > victim.appspot.com uses its own authentication mechanism and its own > cookies, I can then easily set a cookie to a user's browser visiting > attacker.appspot.com and redirect it to victim.appspot.com, and he would > then be automatically authenticated with my own session (session fixation > attack). > > >> Secondly, if the hacker could somehow manage to hijack your session - >> meaning they've some how coerced the request to use a different value for >> the session id) and do it before loading the host page it wouldn't make a >> difference if every Servlet method that is called does the following: >> 1) checks each payload for an auth token (a value equal to the sid stored >> as a cookie on the client) and >> 2) compares the auth token's value to the HttpSession's session id value. >> If they aren't the same then throw a custom exception and catch it on the >> client and authenticate the user (either form-based auth or some other >> method such as Google Account, OpenId, et. al) >> > > But if the auth token is initialized from the cookie (or somehow attached > to the authenticated user) and the attacker managed to set the cookie value > on behalf of the webapp (or at least do a session fixation attack), then > those two checks won't detect it. > > -- > 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. > -- *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.
