Why is regenerating the session not a solution for preventing spoofing?

Question

After hours of reading and trying to understand sessions, this is my general conclusion/perspective:

Simple (and realistic) situation:

• Attacker takes an existing website 'website.example.com' and put random SID behind URL '9gag.com/?SID=1234'
• Attacker paste this URL on a 'forum' with text: '9gag gives away free stuff for first 1000 logins!'
• Victim recognizes the website, because he has an account there, he quickly clicks on the given URL.
• Victim gets on the site and logs in.

Because Victim clicked on the '9gag.com/?SID=1234' and logged in; he is now logged in on a session with id=1234. Note that every session has a unique id. This is necessary for the server to handle each session individual. It is possible though to get on the same session (with same id) from several computers at the same time.

• Attacker goes to '9gag.com/?SID=1234' too. He is now on the same session as the Victim. This means that he is logged in like the Victim. He can see all the Victims account settings and change them.

To prevent this, the host of this site can use the following PHP code:

<?php

  session_start();

  if (!isset($_SESSION['initiated']))
  {

    session_regenerate_id();
    $_SESSION['initiated'] = TRUE;
  }

  ?>

When initiated is true (so when random sessionID has been generated) a new sessionID won't be generated. Otherwise, generate new sessionID. So when a victim logs in with a given sessionID '1234', it will throw it away and generate a new one. Now the Attacker can't get on the same sessionID as you because he does not know it.

The Attacker is smart and knows another way:

• Attacker goes to the site and logs in. A new sessionID has been generated from PHP server.
• Attacker looks in his COOKIES to see what sessionID he received. He finds SID='412e11d5'
• Attacker does the same steps as before, but uses the given ID instead of '1234'. -> '9gag.com/?SID=412e11d5'

QUESTIONS: How is this possible?:

• Is the $_SESSION['initiated'] based on the given ID? So 'initiated == true' because it uses the session of id '412e11d5'?
• Attacker made the session first, otherwise the ID couldn't have been generated. So shouldn't the Victim get on the Attackers session (on his account settings,..) instead of visa versa?
• It looks like session fixation is based on a lot off luck. The Attacker has to get on the website at the same moment as the victim. I guess I just don't get how this works..

EDIT: Attacks using cross-site cooking:

• Attacker creates an own website 'evil.example.com' that stores an specific sessionID in the COOKIE of an existing website '9gag.com'.
• Victim clicks on the URL 'evil.example.com' just like in the other examples. A sessionID has been stored in his COOKIE of '9gag.com'.
• Victim logs into '9gag.com' later that day.
• Attacker can now use Victim's account using the fixated session identifier.

QUESTIONS: again, how is this possible?:

• Even if the Attacker can store something in the COOKIE of another website. How/when can he get on the same session as the Victim? Seems he doesn't have to log in at the same time? Or can he just get the Victims private data in another way (but with use of sessionID)?

PLEASE MODIFY ANY MISUNDERSTANDINGS FROM MY PART! Thanks in advance.

Answer 1

Is the $_SESSION['initiated'] based on the given ID? So 'initiated == true' because it uses the session of id '412e11d5'?

No, it's based on a given session. But initiated == true, since for that given session it is initiated. The session is saved with that id at that time, yes, so that session with that id is initiated.

Attacker made the session first, otherwise the ID couldn't have been generated. So shouldn't the Victim get on the Attackers session (on his account settings,..) instead of visa versa?

Yes. But if the attacker created a session without logging in, and Victim would log in, it would be (originally) attackers session, but victims logging details.

It looks like session fixation is based on a lot off luck. The Attacker has to get on the website at the same moment as the victim. I guess I just don't get how this works..

No, the attacker doesn't need to get in at the same moment. Just when the session is still valid with the given id.

---

Now, an easy solution for all this is to disable session id in urls (trans_sid). This should be always done.

For more security, session id can (and in some cases should) be regenerated on every request/response.