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?

Mercious
  • 113
  • 2

1 Answers1

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.

Fleche
  • 4,024
  • 1
  • 17
  • 20
  • 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
  • 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 '15 at 16:54
  • I understand, yea. Thing is that it actually quite some work to implement the SID-renewal on authorization. The component that does the whole session-creation and validation is a component provided by the Hybris Software. It's a blackbox, i cannot modify it and i basically need to think of SOME way to screw with its functionality. However, the Filter does pre and post-requests-processing so i struggle a lot to get around it. I guess it infact is not possible. The reason i dont escape but filter is because escaping is only needed if you need to allow critical special characters. – Mercious Mar 16 '15 at 17:10
  • To elaborate a little further on the XSS-Filter thing: Imho, the only reason filter are struggeling so hard and the only reason it is considered so hard to filter out possibly XSS-attacks, is because people are trying to allow special characters as user-input. Then trying to parse for COMBINATIONS of special-characters, that might be critical, that is what makes the whole thing incredibly unstable and that is the reason people craft weird and complex syntax-attacks to get through these filters. My filter purges out all special characters, there is no logic behind it that could be beaten. – Mercious Mar 16 '15 at 17:12