-1

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.

user1178560
  • 313
  • 1
  • 4
  • 14
  • 2
    no, you cant create a session on the remote site by creating your own session id in the url –  Nov 15 '12 at 20:28
  • @Dagon you can, if session ids with url params are enabled. that is how PHP works by default. See [this](http://shiflett.org/articles/session-fixation), for example. – eis Nov 15 '12 at 21:41
  • the defaults of 8 years ago are not the defaults of today. trans_sid has been disabled by default for some time. –  Nov 15 '12 at 22:16

1 Answers1

2

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.

eis
  • 51,991
  • 13
  • 150
  • 199
  • "For more security, session id can (and in some cases should) be regenerated on every request/response." Now if you can give me a workable solution to do that on an xhr heavy site you would make me really happy. – PeeHaa Nov 15 '12 at 20:38
  • @PeeHaa, I haven't done this but there could be a simple way to do this with an algorithm that is known both by the server as well as the client. Of course if both client and server know the algorithm so does the attacker but if the algorithm depends on some data only the real client and real server share it's secure. – Mihai Stancu Nov 15 '12 at 20:46
  • One such example would be both server and client using a hash function based on the last communication's entire output buffer. Storing the new hash in an async-safe manner is a bit tricky though. – Mihai Stancu Nov 15 '12 at 20:47
  • First of all, thanks for the answers! I still have some additional questions: Why doesn't the attacker need to get in at the same moment? Normally, the host destroys the session on logging out, so there is no way the Attacker can still get on a session that doesn't exist anymore? – user1178560 Nov 15 '12 at 20:49
  • Additionally, if you regenerate a new sessionID on every request/response (so when login, logout, ..), in my simple opinion, there is no way the attacker can get on the same session using the steps above. Yet everyone still states it is actually possible.. – user1178560 Nov 15 '12 at 20:52
  • @PeeHaa :) the main problem would be race conditions, I'd imagine, if your site can do a lot of simultanious requests. Can't see a good solution to that, you'd need to throttle the requests. – eis Nov 15 '12 at 20:52
  • @user1178560 yes, normally session is destroyed on logout, but a) some hosts don't do it b) user does not necessarily log out. that's why there was a clause "just when the session is valid" - it is valid until destroyed. – eis Nov 15 '12 at 20:54
  • @user1178560 I don't see "everyone" or anyone stating that. can you provide an example? – eis Nov 15 '12 at 20:55
  • transparant session id's are disabled on default. I see you can disable URL and COOKIE sessionID storage. But you need at least 1 of them if you want to work with sessions? – user1178560 Nov 15 '12 at 21:02
  • @user1178560 you need some way to deliver the session identifier. the things you can use with http are cookies, query parameters and form parameters, and form parameters would not be very handy for the session id, as every request would have to be a form submit. also, it used to be enabled by default, which is why many sites have it. – eis Nov 15 '12 at 21:08
  • Sorry for all the questions, I'm really thankful for the help. Although I got another one: if the Attacker only needs an sessionID to get on the same session, Why would you use $_SESSION['pass'] = $row['pass']; and then check if $row['pass'] = $_SESSION['pass']; Can't you just use $_SESSION['initiated'] = true; or a separate $_SESSION['logged_in'] = true? Is this to protect a user from cross-site cooking? So the Attacker has to know the password as well to get in. – user1178560 Nov 15 '12 at 21:18
  • @user1178560 yes, you can. that check might be there to avoid a session id collision - if the id is regenerated a lot, there is an increased possibility for two users to get the same id, and that check would prevent using a session in that case. otherwise an attacker could force a regeneration of id until there was a valid one belonging to some other user. – eis Nov 15 '12 at 21:23