Session Fixation cookie delivery

Question

I found a possibility for session fixation in an application I am researching. It is a session fixation through a session ID cookie. Now I've read up on session fixation and the concept is clear and comes down to getting a victim to use the cookie value you (attacker) provide.

From what I understand you cannot set a cookie value for a different domain than you are from. So you cannot just put on your evil site (evil.com) set cookie: sessID=1234 from targetsite.com. So my question is what are all the different avenues that can be used to deliver the cookie to the victim? I already listed the ones I found, so the question is, is there more? (I want to use this information mostly to create some awareness in management that it is a serious thing session fixation).

The ones that I already know:

• XSS (stored and reflective, but you need a vulnerability in the site itself!)
• Leave computer open with page open and wait for someone to login
• MitM (but then you would be able to do a lot more than just fixate a session!)
• Meta tag injection
• DNS server hacking (which is a bit much I think for something like this, but comes down to getting into the domain of the target through the DNS server. As far as I understand it).

Answer 1

In addition to your list:

Uncontrolled subdomain

Your site runs on example.com although the attacker controls bob-usercontent.example.com. This could either be through poor design or a server admin has created a subdomain for a user unaware of the vulnerabilities this opens with cookies.

Attacker sets their website to output the header:

Set-Cookie: sessID=1234; Domain=example.com

and then entices their victim to visit bob-usercontent.example.com. This could be any resource, including an image embedded on another site.

When the user then goes to example.com and logs in, the cookie will log in the attacker.

Insecure subdomain

Similar to the above, but this time there is no design flaw.

static.example.com contains a DOM based XSS vulnerability (for example).

Attacker entices user to visit

http://static.example.com/page.html?name=<script>document.cookie = "sessID=1234; Domain=example.com";</script>

(Of course the name parameter would be percent-encoded, but left as is here for readability.)

When the user then goes to example.com and logs in, the cookie will log in the attacker.

Lack of HTTP Strict Transport Security policy

User visits arbitrary websites over HTTP.

Man-In-The-Middle attacker intercepts one of these requests and redirects it to http://example.com. Attacker also intercepts this request and responds with their own page that sets the following header:

Set-Cookie: sessID=1234

When user visits https://example.com, the cookie is already set and upon login the attacker is logged in. More on HSTS here.

Answer 2

Here are the two methods I would like to add with the ones that you already had provide:

• Inserting Session id in URL:

  1. First you(attacker) have to connect to the web server and you will be issued with a valid session id.
  2. Then you have to craft a link with the session id and send it to the victim. URL looks like: http://application.com/login.php?sessionid=abcd
  3. Then the victim clicks on the URL and request is made to the webserver with the attacker provided sessionid.
  4. Server thinks the victim already has the session id and start using the sessionid without providing a new session.
  5. Now the victim logs in the application and attacker will be able to hijack his session.

Note: This method only works if the session id is same Pre and post login.

• Using HTTP Response splitting:

If the site is vulnerable to HTTP response splitting, an attacker can insert a Set cookie header in response with the attacker generated sessionid.