I too would like to know the Wicket answer. The problem is that JSESSIONID is how the Servlet container differentiates the session with the user. It's part of the spec since the beginning. Because it is well known and certain browsers (Firefox, representing over a third of browser clients) make it pretty easy to look at the cookies it has become a known weakness to people who want to do bad things.
Now, if the entire interaction is done with HTTPS, theoretically you would be able to use the SSL session ID to match sessions. That would be a configuration setting on your Servlet container. The solution that some frameworks and roll your own security folks have come up with (like Ruby on Rails) is to use a secondary token as a salt for a secondary token. Rails uses this token for all POST requests and uses a constant time comparison for the token (another topic altogether). Of course, Rails stores all session data in a Cookie by default, encrypted and hashed with the secondary token. It makes it more difficult to steal a session that way. An approach similar to this (without storing session data in a cookie) can be done using a ServletFilter. The alternative I've seen is to change the secondary token periodically or every request. The problem with this solution is that you break the back button when the token changes. At the very least, the secondary token should be generated based on requestor information (IP address, user agent, etc.). That way the token is not simply a matter of simply matching the JSESSIONID string against a hash. You are recreating the master token the same way and comparing it with what you received. To summarize, I would most likely create a ServletFilter to handle the secondary token handling. The secondary token would be a SHA-1 hash of an application salt (random characters at least the length of an SHA-1), the user agent, and the requesting IP address, and the Servlet session ID. The ServletFilter either throws a 403 response, or invalidates the session if the newly generated key does not match the secondary token provided. Essentially, the user would have to be behind the same firewall/gateway, have the same exact browser and patch level, and the session id to successfully steal a session. Even within an organization the differences in user agent strings for Internet Explorer at any version vary greatly. Additionally, I would use the ServletFilter to actively reject automated clients. If the system lives in SSL, this is a valid approach because you don't necessarily want the contents indexed. You'd be surprised how many poorly behaving web crawlers there are out there. Many of them are home-brewed scripts that spider your site, ignoring your robots.txt file--even on private networks. -----Original Message----- From: Andrew Turner [mailto:grim_toas...@hotmail.com] Sent: Wednesday, December 02, 2009 4:24 AM To: users@wicket.apache.org Subject: Session stealing with wicket-auth-roles Good morning all, I'm hoping I've misconfigured something in my application, but we seem to be prone to session stealing in our wicket application. We're using wicket-auth-roles to provide the security, and if you are able to access the jsessionid you can get another machine to log straight into the application as the intercepted user. We're using HTTPS for the communication, so hopefully the likelihood of this occurring is quite small, but we are still being forced to contemplate rewriting the security layer (which I want to avoid if possible). So, my question, have I misconfigured something, or is it just not possible to prevent this sort of attack when using wicket-auth-roles? I've managed to create a completely stripped-down app that still has the problem, below is the AuthenticatedWhenSession implementation. public class HelloWorldWebSession extends AuthenticatedWebSession { public HelloWorldWebSession(Request request) { super(request); } public boolean authenticate(String username, String password) { return "helloUser".equals(username) && "password".equals(password); } public Roles getRoles() { return isSignedIn() ? new Roles(Roles.USER) : null; } } And the simple page: @AuthorizeInstantiation("USER") public class HelloWorldHomePage extends WebPage { } And the application: public class HelloWorldApplication extends AuthenticatedWebApplication { protected void init() { super.init(); mountBookmarkablePage("home", HelloWorldHomePage.class); mountBookmarkablePage("signin", SignInPage.class); } protected Class<? extends WebPage> getSignInPageClass() { return SignInPage.class; } protected Class<? extends AuthenticatedWebSession> getWebSessionClass() { return HelloWorldWebSession.class; } public Class<? extends Page> getHomePage() { return HelloWorldHomePage.class; } } The URL below, once logged in on one machine, could then be used on multiple machines to bypass the security layer. http://localhost:9090/HelloWorld/home;jsessionid=<SESSION_ID_TAKEN_FROM_ URL/COOKIE> Many Thanks Andy _________________________________________________________________ Add your Gmail and Yahoo! Mail email accounts into Hotmail - it's easy http://clk.atdmt.com/UKM/go/186394592/direct/01/ --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
