On Fri, Feb 25, 2011 at 8:49 AM, Thomas Broyer <t.broyer@gmail.com> wrote:
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.
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)
Not only does the above protect against session hijacking but it also solves the "how do I know if the session is timed out" question. So you solve two use cases in one implementation which isn't bad.
You can even use filters to do this eliminating the need for every Servlet method to implement this logic.
It's a simple, viable solution to an attack that is quite prevalent these days. It's implementation on both the client and server are trivial yet (I would venture to guess) is regrettably ignored by many if not most developers (to which I am not limiting to GWT developers).
Of course, having a secure transport protocol (ie SSL) is the ultimate solution but not every site or every page on a site requires SSL yet every page that communicates with the server on every site requires a proactive defense against these kinds of attacks.
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.
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)
Not only does the above protect against session hijacking but it also solves the "how do I know if the session is timed out" question. So you solve two use cases in one implementation which isn't bad.
You can even use filters to do this eliminating the need for every Servlet method to implement this logic.
It's a simple, viable solution to an attack that is quite prevalent these days. It's implementation on both the client and server are trivial yet (I would venture to guess) is regrettably ignored by many if not most developers (to which I am not limiting to GWT developers).
Of course, having a secure transport protocol (ie SSL) is the ultimate solution but not every site or every page on a site requires SSL yet every page that communicates with the server on every site requires a proactive defense against these kinds of attacks.
--
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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment