0

I was testing a web application where cookies (session ID, session values) are the same for all times. Even after successful authentication takes place it remains unchanged. The session ID travels in the form of a HTTP cookie.

To investigate a session fixation vulnerability, I sent my colleague a link like http://yoursite.com/?SID=1209023, because I thought the web site would automatically assign the victim session ID 1209023 for the victim's future browsing on the site. But it didn't work.

So my application isn't affected in this way but still has the same cookies. Is there any other way to test for the existence of a session fixation vulnerability in my application?

2

For there to be a session fixation vulnerability, the server most somehow save use some input that you (the attacker) can control as a value for the session ID. OWASP has a handy list:

  • Session token in the URL argument. (This is what you tried. But do note that the parameter could have any name, and you need to figure out what it is. It does not have to be SID.)
  • Session token in a hidden form field.
  • Session ID in a cookie. Since you can not set cookies cross domain, you need to some other vulnerability to exploit this, such as XSS or HTML injection (of a META tag).

If the server always sets a session ID on its own, without involving any user input in the process, this might very well not be exploitable.

  • Thanks @Anders. Following your clue and given OWASP page i was able to test my application against session fixation and found it positive. Now looking for remote testing. Trying to grab the cookie remotely using javascript script. Have any idea how to test it? – Shakir Mar 6 '17 at 3:36
0

You could consider using Burp, and overwriting the server issued cookie (pre-auth) with your own value.

Or, simpler still, you could initiate a request with whatever cookie value you choose, and validate whether the server at any point changes it (a single request would be sufficient to check).

You already known the cookie value isn't changed post-auth, so the potential is definitely there - it sounds like you just need to work out the right parameters to use.

How you actually exploit it is another matter - but knowing there is one, and then agreeing you should probably go with OWASP's recommendations, and create a new session on authentication, is half the battle.

  • Actually, my tested application was too vulnerable. Just used a browser add-on to get the cookie and insert them to another machine. Then I was able to log on using that session. Looking for retrieving the cookie's remotely sending links/XSS/Javascript. Do you have any idea? By the way, thanks for the info. – Shakir Mar 6 '17 at 3:41
  • Depending on the details, you might find it easier to try and set the cookie to a known value, rather than trying to retrieve an unknown cookie – iwaseatenbyagrue Mar 6 '17 at 7:35
  • I tried that too. Cookie changed so dynamically that, i could not assemble a pattern. So, i am trying to retrieve the cookie over javascript or similar technique for stealing the session. Any idea regarding that will be highly appreciated. @iwaseatenbyagrue – Shakir Mar 6 '17 at 8:40
  • I guess your options are session fixation (owasp.org/index.php/Session_fixation), or session hijacking (owasp.org/index.php/Session_hijacking_attack). Both pages provide some info about where to go from where you are now (I think). As you use HTTP rather than HTTPS, I guess man-in-the-middle will be the absolute easiest, but if there was a plan to migrate to HTTPS (which you might consider), I think I'd poke around what XSS and friends could do for me. – iwaseatenbyagrue Mar 6 '17 at 10:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.