A product I work on got a tough security audit by a potential customer and they are upset that Tomcat sets a JSESSIONID cookie before authentication has happened. That is, Tomcat sets this cookie when our stateless Login Page loads, but before login.
They suggest either of the following:
I have been poring through everything JSESSIONID-related on this site and can find no easy answer. I'm just hoping for some ideas. My best solutions for each are:
I've got to get some sleep, but will be attempting these in the morning. It would be awesome to get some feedback or better suggestions from people much smarter than myself -- like you!
Regardless, I'll post my results here because it seems like a lot of other people have been wanting to do something similar.
You will not refresh after but just before. When executing the login action first do:
HttpSession session = request.getSession(false); if (session!=null && !session.isNew()) { session.invalidate(); }
Then do:
HttpSession session = request.getSession(true); // create the session // do the login (store the user in the session, or whatever)
FYI what you are solving with this trick is http://www.owasp.org/index.php/Session_Fixation
Lastly you can disable automatic session creation and only create the session when you really need it. If you use JSP you do that by:
<%@page contentType="text/html" pageEncoding="UTF-8" session="false"%>
I can't comment on @cherouvim's answer above as I don't have enough points. The new session ID should be set "after" the user successfully logs in, to avoid session fixation. I'll try and explain my reasoning.
Session fixation effectively means that an attacker somehow tricked a user into using a value known to the attacker. For simplicity's sake, let's assume that the attacker walked over to the user's desk, used Firebug and edited the user's cookie. Now when the user logs in, he/she will be logged in with the attacker controlled cookie. Since the attacker also knows this value he/she will refresh their browser and the resources mapped to that session ID (the victim's resources) will be served to them. That's session fixation. Correct?
Now let's say we ran a session.invalidate before the victim user logged in. Lets say the cookie initially had a value abc. On running session.invalidate the value abc is purged from the server's session.
Now comes the part where I disagree. What you suggest is to generate a new session before the user actually logs in (Enters username and password and clicks submit). This will no doubt cause a new cookie to get generated but it will be on the user's browser before they login. So if an attacker can edit the "prelogin" cookie again, the attack still persists, as the same cookie will be used even after the user logs in.
I think this is the correct flow.
What this means, is that even if an attacker manages to trick you into using a controlled value prior to logging in, you're still protected..as the application forcibly changes the value after you log in.
Here is a good blog about this issue - https://blog.whitehatsec.com/tag/session-fixation/
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With