I am pen-testing an ASP.NET application that is exhibiting Session Fixation behavior. The application is using cookie based sessions. Basically:

  1. When you land on the page no Session cookie is created
  2. After login ASP.NET_SessionId cookie is created
  3. On logout and repeated login the cookie value remains the same (there is no cookie value regeneration)

I have been able to perform Session Fixation attack manually:

  1. I have landed on the page
  2. I manually created a ASP.NET_SessionId cookie with some value (for the attacker)
  3. I opened a new browser session and set the exact same cookie (for the victim)
  4. I logged in as victim in this new browser session
  5. In the attacker’s browser session I was now able to browse the web site as the victim

I am now having problems exploiting this Session Fixation vulnerability in real conditions. I need to create or modify ASP.NET_SessionId cookie in some manner. From what I am able to tell, there is no XSS vulnerability on the web site which I could use.

I have been playing with two most notable attack variations but with no luck (a case where a victim would click on a link which would set a cookie on the web page):

  • JavaScript

https://www.example.com/<script>document.cookie='ASP.NET_SessionId=THISISAFIXATEDCOOKIE; expires=Thu, 18 Dec 2015 12:00:00 UTC; path=/; domain=example.com; path=/'</script>

  • HTML Injection

https://www.example.com/<meta http-equiv=Set-Cookie content="ASP.NET_SessionId=THISISAFIXATEDCOOKIE; expires=Thu, 18 Dec 2015 12:00:00 UTC; path=/; domain=example.com; path=/">

Whatever I tried I’ve either hit a default error page or the landing page with no created/modified cookie.

Am I missing something with these two attack vectors?

Is there any other method I could try in creating or modifying the victim’s ASP.NET_SessionId cookie besides using man-in-the-middle or man-in-the-browser (malware based) attacks?

  • Both your js and HTML based attacks only work if leveraged through a cross site scripting vulnerability
    – wireghoul
    Commented Feb 27, 2015 at 4:52

2 Answers 2


It looks like you have copied the example attacks directly from the OWASP page on Session Fixation.

To clarify - these are intended to be examples specific to a system that has another vulnerability besides Session Fixation (XSS, HTML Injection, etc) - these are not attacks that are likely to work in any real world situation.

If you wanted to execute this attack there would be two steps:

  1. Find a vulnerability that would allow you to set the authentication cookie for another user. Your best best would probably be XSS or HTML injection. To find this type of vulnerability you would probably want to do a security assessment of the site where you catalog all HTTP requests that can be made. You would then fuzz all inputs at the HTTP level in an automated fashion and look for indications that a vulnerability exists. For possible vulnerabilities you would go in and manually test to see if anything is really there.

  2. If you find any vulnerabilities in the previous stage you could then attempt a Session Fixation attack.

Hope this helps.

  • To add to the options here, the first example on the OWASP page goes over the classic scenario: sniff the (usually) unencrypted traffic of the victim while they are not authenticated to obtain the session cookie. After they log in you can then use that session information in your own requests to masquerade as them.
    – Alex Kuhl
    Commented Mar 11, 2015 at 19:02
  • Yes that's another option. Technically I think that is Session Hijacking and not Session Fixation - but it's the same family of attack. Commented Mar 11, 2015 at 19:10

Right, a prerequisite for a session fixation attack is that the attacker can place a session identifier (cookie) on the victim's machine. Since cookies are tied to the domain they are issued by, this can't happen in the normal course of things; that is, the attacker needs a way to inject a cookie that looks like it came from the target site.

In practice, this means exploiting another vulnerability in the target application, such as XSS. That's what your example URLs are trying to do, but if the target page isn't vulnerable to that attack then it won't work. Session fixation is something of a secondary vulnerability in that it requires some other exploitable weakness in order to pull off an attack. In practice, it's easier make the necessary changes to prevent session fixation attacks than it is to prove that no XSS vulnerabilities exist.

OWASP is always a good reference.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .