1

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?

3

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 '15 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 '15 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 '15 at 15:56
  • I'd like to assume that XSS is not a problem because if it is i have work to do. I don't quite understand the "from the Referer" or "URI" example? A request is ran through the filter and the requests params, if any, are checked. They are then stripped off any character that could become a problem in one of the possibly context (JS,HTML,attributes, ..). And these params are all that are ever used. I understand that someone might add stuff to the URL, but i dont care because i never adress them anywhere. And yea, UTF-8 is set in all required places, so i should be fine here too? – Mercious Mar 16 '15 at 16:03
  • 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 '15 at 16:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.