Cant you use http://www.mkyong.com/wicket/how-do-encrypt-encode-url-in-wicket/
But I guess it might still get the session id appended..? 2009/12/2 Loritsch, Berin C. <berin.lorit...@gd-ais.com> > 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 > >
