0

Before logging in to the asp.net application, i checked the headers and there was already a session id in cookie header cookie: ASP.NET_SessionId=3de0es3brpfbcmvkzhkidsmt

And when i logged in to the application, the same cookie header was present there. When i send a request by removing this cookie header from the request, i am logged out. So my question is what is happening over there? Is it some bug? Please elaborate. Thanks

Usama Saeed
  • 1
  • 1
  • 2

2 Answers2

0

Not a bug, the Session Cookie is created regardless of 'user' authentication. The sessID cookie is ONLY an Identifier (X Client has X Cookie). Once a user has been authenticated with the server you may continue to use that cookie to identify the authenticated user.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Scrapps
  • 11
  • 1
  • so what if someone else captures that cookie? he will be impersonating me? – Usama Saeed Jul 24 '16 at 10:35
  • 2
    Yes if someone gets a sessID cookie they can impersonate you, which is why you need to develop risk mitigating strategies. Using HTTPS can help prevent MITM attacks from reading the Cookie in plaintext. XSS prevention should limit code injection to steal the cookie etc. – Scrapps Jul 24 '16 at 10:43
  • 1
    What you are describing is known to lead to session fixation vulnerabilities. https://www.owasp.org/index.php/Session_fixation – Neil Smithline Jul 24 '16 at 17:33
  • @NeilSmithline bang on target. I wish you had elaborated more and I would have upvoted it as an answer. – GhostSpeaks101 Jul 25 '16 at 11:16
0

Yes, this is a bug. Specifically, it is a type of session fixation vulnerability. The attack scenario looks like this:

  1. Person A uses a device (possibly a friend's phone, possibly a machine at an Internet cafe, whatever) to go to the target website W.
  2. Person A notes down the session token that the site generates for them.
  3. Person A gets off of that device, and person B (the device owner, or the next patron at the cafe, or whatever) takes over.
  4. Person B goes to the same site W, and logs in, so the session token is now associated with B's authenticated session.
  5. Person A uses the session token - which they noted while they had access to the device - to make requests to W in the context of B's authenticated session.

Person A is here able to hijack person B's session, remotely and after the fact.

Depending on whether or not the site changes the session token when a user ends their session, this could be even worse. In that scenario, an arbitrary number of users could all end up being compromised one after another.

It's fine to generate a pre-authentication session. That part isn't a bug, and indeed is useful for mitigating some vulnerabilities (such as login CSRF) as well as improving user experience. However, the session token MUST change every time a session changes from unauthenticated to authenticated, or from one authenticated user to another. It MAY also change any time the session changes from an authenticated session to an unauthenticated one, as a defense-in-depth measure.

CBHacking
  • 40,303
  • 3
  • 74
  • 98