scapevilla.blogg.se - Session fixation attack

#Session fixation attack how to#
#Session fixation attack code#

Whether getSession(), getSession(true) or getSession(false) is called, the server relies on its own memory to determine if there is a valid session matching the value received from the client. (as discussed in the comments) This behavior is both intentional and correct. The servlet engine you are using securely handles session cookies when you call request.getSession(), and is not vulnerable to fixation. Why is it that the original cookie c1 does not persist after the authentication?

I am having trouble understanding this behavior.

#Session fixation attack code#

Which implies that the code is not vulnerable to session fixation. I found the cookies c1 and c2 to be different.

Observe the cookie ( c2) after the authentication.

The authentication was successful and I was redirected to LoginSuccess.jsp

Enter the correct credentials in the login form.

Observe the cookie ( c1) when login page loads (using an intercepting proxy).

In order to test the code I deployed it using tomcat 7 and tested for session fixation: HttpSession session = request.getSession(false) //return the existing session if(obj.checkLogin(username, password))//if credentials are valid In any case a new session should not be created. Referring to the documentation I came up with the following code which when used in the servlet to create a new session, should return the existing HTTP session if it exists and otherwise it should return null.

Have your application reject session cookies that don't match a server-side record, to prevent fixation.In the process of developing a vulnerable jsp/servlet based application I made an attempt to introduce the session fixation vulnerability.

This serves as a mitigation mechanism against all of the 3 attacks.

Regenerate session IDs on every privilege-changing action a user performs (login, logout, login as admin - if there's an extra form for that), as well as on regular, short time intervals.

If JS can't access cookies, that also means it can't leak them (can't be hijacked), but there's lots of other ways to exploit client-side code. JavaScript doesn't have access to the cookie.

Set the HTTPOnly flag on cookies, so that e.g.

browsers will only send when using the scheme).

Also set the Secure flag on cookies, to prevent them being submitted over a plain-text connecition (i.e. Use TLS (HTTPS) to prevent MITM attacks and thus the most common ways of hijacking.

#Session fixation attack how to#

How to protect yourself against these attacks: Note: I've used "session cookie" everywhere to simplify the explanations, but of course there are other means of transferring session IDs. For example, a user could be tricked into buying multiple quantities of a good that they only wanted a single unit of. Otherwise, it can refer to tricking the victim into re-submitting a previously valid request (with the same session cookie). If the attacker already has access to a session cookie (via fixation or hijacking), then it's just the act of reusing the cookie for whatever they want. Replay is a bit different and can mean two things. Of course that requires an attacker to have temporary access to the victim's browser itself, but the principle is very simple - there's no need to steal the data if it is under your control in the first place. So after the victim logs into a website, they will use the same session cookie that the attacker already knows, and thus the attacker-owned cookie is now authenticated and can be exploited. Session fixation is similar, but inverted - a pre-defined session cookie is planted into the victim's browser. Most commonly through sniffing network traffic (a MITM attack), but also through any other ways that a session ID may be leaked. Session hijacking is simply the act of stealing an existing, valid session cookie. They only differ in how you achieve that. Both fixation and hijacking have ultimately the same goal - gaining access to a session.