5

Given the following conditions,

  1. Session ID does not change upon login
  2. Session ID travels in form of HTTP cookie
  3. There is no cross site scripting/redirection vulnerability on the login page

is it still possible to perform a session fixation attack?

Andrei Botalov
  • 5,267
  • 10
  • 45
  • 73
wxyzwebz
  • 51
  • 3
  • 1
    Do you have reason to ask for session fixation in particular, or do want to know if the scenario is safe (what it is not)? – martinstoeckli May 08 '12 at 19:29

3 Answers3

8

First, please read upon session fixation attacks and make sure you understand how they work. You didn't give us the information that is needed to determine whether standard session fixation attacks will work; all of that information is relevant to other attacks, but not to session fixation.

The fundamental characteristic of a session fixation attack is that the attacker manages to enroll the victim into a session that was previously established by the attacker. After this, the attacker has control of a session that is now being used by the victim as well, which may enable the attacker to do all sorts of bad things.

The primary precondition for a session fixation attack to be possible is the attacker has to be able to force the victim to start using a session ID of the attacker's choice. On some web sites, this is possible if the attacker can get the victim to visit a link like http://yoursite.com/?SID=1209023, because the web site will automatically assign the victim session ID 1209023 for the victim's future browsing on the site. On other web sites, this is not possible, because the web site doesn't work that way.

So, you haven't given us enough information to know whether session fixation attacks will work, because you haven't given us enough information to determine whether the precondition is met.

That said, the site almost certainly has security problems. It is vulnerable to eavesdropping (Firesheep-like attacks) and likely vulnerable to login CSRF.

D.W.
  • 98,420
  • 30
  • 267
  • 572
0

one possible scenario

  • Attacker open a the page on a browser, pick the session cookie
  • Leaves the on browser open ( browser session is not terminated and hence session scoped cookie would be alive on the browser)
  • Victim log in on the browser
  • Application associates the session with same cookie
  • Attacker already have the session cookie and hence the user session
Sachin Kumar
  • 820
  • 3
  • 9
  • 14
  • 3
    This isn't classical session fixation. If the attacker already has access to the computer account the victim is using, the attacker doesn't need any to use any special properties of the web site: the attacker can already steal all of the victim's browsing by installing a keylogger/cookie logger/spyware, or by faking up the site, etc. – D.W. May 09 '12 at 02:30
  • This is applicable in scenarios where attacker has limited access to the system. In real life scenarios, this attack works well. – Sachin Kumar May 09 '12 at 10:05
-1

Yes, the HTTP traffic is vulnerable to MITM attacks, either by direct packet modification or simply by routing the connection through an HTTP proxy or redirection via DNS poisoning.

symcbean
  • 18,278
  • 39
  • 73
  • 2
    Would this strictly be session fixation? We can steal their session id but we can't fixate it (as far as I understand the question) – Andy Smith May 08 '12 at 17:21
  • 3
    This isn't session fixation. wxyzwebz asked about session fixation. – D.W. May 09 '12 at 02:31
  • It is if the MITM subsistitutes their own cookie value. While if they've got MITM capability then there are other ways of compromising the data exchange, these fail if the session moves to HTTPS - but if the same session id is used, then the HTTPS session is compromised too. – symcbean May 10 '12 at 10:21