If you go with the latter, you will need to determine if you can replace the session generation in place or if you will write your own session management code. You either need to find an older, broken servlet engine that is vulnerable to session fixation or you need to replace the session management code. This prevents session fixation, since the server never allows the client to define the sessionid of a new session (new from the perspective of the server that doesn't have that sessionid in memory.) If there is no such session in server memory, then the servlet engine ignores the session id from the client. 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).These techniques range from Cross-site Scripting exploits to peppering the web site with previously made HTTP requests. Depending on the functionality of the target web site, a number of techniques can be utilized to 'fix' the session ID value. In order to test the code I deployed it using tomcat 7 and tested for session fixation: Session Fixation is an attack technique that forces a users session ID to an explicit value. HttpSession session = request.getSession(false) //return the existing session Session hijacking is simply the act of stealing an existing, valid session cookie. They only differ in how you achieve that. if(obj.checkLogin(username, password))//if credentials are valid 1 Answer Sorted by: 9 Both fixation and hijacking have ultimately the same goal - gaining access to a session. 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. ) under which Confluence is located (this cookie will be submitted to every page in any subdomain of that parent domain and can be set in any subdomain of that parent domanin).ī.The most common way that an attacker would store a cookie on a victim's browser is through an XSS hole ( ), but other vectors exist such as header injection.Ĥ.The victim clicks on a link that the attacker provides (which stores the cookie on the victim's browser and redirects them to the login page) and then the victim logs in normally.Ī.When the victim logs in, a record gets stored to some database tying the victim's account to cookie_val passed in.ĥ.The attacker (who has the same cookie as the victim now) goes to dashboard.action and can act as the victim.In the process of developing a vulnerable jsp/servlet based application I made an attempt to introduce the session fixation vulnerability.
This is a general authentication security hole with Confluence tested in version 2.10.2.ġ.Attacker logs in via the login page and two things happen:Ī.A cookie gets stored on their browser with name=JSESSIONID, value=cookie_val, path=/, domain= whaterver the domain is (perhaps A.B.).ī.A record gets stored to some database tying the attackers account to cookie_val.Ģ.The attacker logs out via the logout.action script.Ī.The record on the database tying the attacker's account to cookie_val gets deleted or inactivated.ī.The cookie on the attacker's browser doesn't get deleted (but even if it did they could restore it since the attacker has complete control over their own browser).ģ.The attacker stores a cookie to the victim's browser:Ī.The cookie that is stored has name=JSESSIONID, value=cookie_val, path=/, domain= the most general parent doman (perhaps.
0 kommentar(er)
