Someone stepped up to me calling me out on not assigning a new session-ID on successfull login.

Basically i was told: The fact that i use the same cookie (with the same SID) in the login-page as well as the remaining authorized session makes my website vulnerable to session-fixation.

First of all, i don't even understand the term in this case: This has nothing to do with session-fixation, does it? My SIDs are sent back and forth using HttpOnly and Secure HTML-Cookies. Meaning fixation by calling an URL with a certain SID wont even happen, because my website doesn't use URL-SIDs.

I could not think of any other way a session could be set by a potential hacker to his desires. The only way he could would require him to execute a JS from my domain and that would require the domain to be XSS-vulnerable, right?

And then again i also always bind a request-IP into a session, meaning once a different request-IP from the one already bound to the session is trying to use that session i will invalidate this session and kick the user out.

Am i being ignorant towards a certain circumstance here or his my website not vulnerable to session-fixation as claimed? I searched through quite a good amount of examples regarding session-fixation and i feel like i have no need to take any actions here?

1 Answer 1


This is a session fixation vulnerability, even if it may be relatively difficult to exploit.

You make a lot of assumptions before you conclude that everything is fine. Your assumptions are:

  • “An attacker cannot set a cookie in the victim's browser, except through an XSS vulnerability.”
  • “There are no XSS vulnerabilities anywhere in my application.”
  • “IP addresses are never shared.”

I disagree with those statements.

Setting a cookie in the vicitim's browser doesn't necessarily require an XSS attack. For example, if there's a subdomain hosting a different application, then this application may also set cookies for the main domain.

XSS vulnerabilities do exist in many applications, even when all programmers do their very best. What makes you think you're the exception?

IP addresses do get shared. There are proxy servers and VPNs with thousands of users, there are public WiFis, there are large networks behind a single IP address (thanks to NAT), there's the Tor Project routing its entire traffic through a few exit nodes, there are ISPs which constantly re-assign their IP addresses. So one IP address does not equal one user. How difficult it is for an attacker to actively take over the victim's IP address depends entirely on the concrete network environment, and that's obviously not under your control.

Of course you may be lucky and not fall victim to any of the above problems. However, relying on luck is a bad idea in security. In fact, we usually assume the worst-case scenario, and that's why it's standard practice to generate a fresh session ID when the user logs in.

  • Well ... I understand your point. However, my assumptions hold truth for my case. I do not host any subdomain and my website is not vulnerable to any XSS-Attack, simply because i allow no special characters from user-input. I understand that the IP-Adress to session binding is not a stand-alone security, it was never meant to be. It was meant as additional layer of security. But i understand the general idea behind your statement and i guess it basically is: Renewing the SID after authorization is good practice as many factors could otherwise lead to vulnerability. Ill accept this as an answer
    – Mercious
    Mar 16, 2015 at 15:47
  • 2
    @Mercious Major, major flaw in your thinking: XSS doesn't have to be from standard user input. It could be from the Referer, the URI itself, HTTP headers, external content (e.g. included jquery.js), or even DOM-based from some dodgy JavaScript. Your filters may also be defective, ineffective against certain character classes (UTF-8, etc.), or not have 100% coverage. You should never presume that XSS will not be a problem.
    – Polynomial
    Mar 16, 2015 at 15:52
  • @Mercious You're also presuming that the user's browser is without bugs. What if there's a same-origin policy violation bug in the user's browser, and an attacker leverages it to create a cookie across origins onto your domain? With your session fixation issue present, your user's account gets hijacked. If you fix that bug, they're not quite so boned.
    – Polynomial
    Mar 16, 2015 at 15:56
  • 1
    @Mercious You can never be 100% sure that you didn't miss something. Everything has bugs, and you might not even be responsible for the bug that results in XSS (or a similar impact) on your site. As I noted, SOP bypass bugs in browsers are relatively common, so you should account for them where possible. Besides, the fix for session fixation on login is just to regenerate the token on login - it's not a lot of work.
    – Polynomial
    Mar 16, 2015 at 16:47
  • 1
    Defending against XSS is extremely difficult and pretty much an unsolved problem, which is why every application struggles with it. There are hundreds of attack variations, hundreds of ways to screw up and dozens of crazy syntax features lurking in the HTML spec, so if you think you've figured it all out, you probably haven't. In fact, it worries me that you seem to rely entirely on (self-made?) filters. The primary defense mechanism is escaping. Filters are, at best, a backup solution for some special cases.
    – Fleche
    Mar 16, 2015 at 16:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .