2

Is there a way to perform session fixation attack with XSS present if session id is passed in request header?

As far as I see it, theoretically there are three ways to do so:

  1. intercept request on login, substitute session id (have not found any ways to do with JS without additional installations for client like service workers which I couldn't make work yet or browser extensions)
  2. intercept response from the server and substitute session id that was offered by the server (also no information on that one expect for above options).
  3. get session id from local storage (at the moment it's not clear where the session cookie is stored) а. overwrite localStorage with setItem b. overwrite sessionStorage with setItem c. overwrite document.cookie d. if custom way of storing session is used, reverse engineer the client code to find out how and use in XSS. I understand that custom header is not the standard way to operate with sessions, therefore the responsibility for storing and getting saved session ids is on the client JS. So, there must be a way to overwrite local storage with cookies.

If my outline of available options is correct (please, correct me if there was a mistake), of all options the only one that seems real is attacking the storage. In this article it's said that:

As we can see, the session token is sent in a custom HTTP header X-AUTH-TOKEN. Sending session tokens in custom HTTP headers, protect applications from Cross-site Request Forgery (CSRF) attacks. Unfortunately, the fact that globals cookie, storing the token, must be available from javascript, in order to be included with a request, makes the application exceptionally vulnerable to token theft.

As for local storage attack, I generally understand, but what about intercepting requests and responses and changing them on the fly? As far as I understand, to intercept requests and responses there must be a malicious browser extension installed on the client. We certainly cannot set custom header from HTML, the only option left - JS (I know XHR can do that, but that would be a separate request which is not an option with session fixation). But how exactly and whether at all it can be done, is not yet clear to me. Are there ways to do that? Can anyone give some piece of advice on this one?

ShHolmes
  • 123
  • 1
  • 5
  • 1
    Are you interested in session *fixation* or session *hijacking*? – Anders Dec 19 '19 at 14:26
  • You mentioned session fixation when an XSS vulnerability has happened. Once XSS is in scope, it's effectively impossible to keep the session secure. If I have an active XSS attack in place then why would I bother with session fixation? I'd much rather just wait for the person to login and then have full access to their session anyway. As a result I'm confused about what you're looking for here. – Conor Mancone Dec 19 '19 at 14:58
  • @Anders I'm interested in session fixation attack. The mechanism of hijacking the session is used here as an example of possible API to get and set cookie. – ShHolmes Dec 19 '19 at 15:02
  • @ConorMancone My question is whether session fixation is at all possible with XSS present on the page when session id is passed in customheaders. – ShHolmes Dec 19 '19 at 15:07
  • @Anders If my understanding is right, there are three standard ways of storing the session id: localStorage, sessionStorage, cookie storage. In the case of localStorage and sessionStorage the session id would be accessible through setItem and getItem methods. In case of cookie storage session id would be accessible by document.cookie="asdasd". – ShHolmes Dec 19 '19 at 15:09
  • @Anders Anyway, if the application is using some custom way of storing cookie, it could be reverse engineered from the JS code of the front-end. So, as I see it, the easiest way here would be to attck local storage. But the question is whether there are other ways to do so. For example, intercepting and tampering with requests or responses. – ShHolmes Dec 19 '19 at 15:09
  • It sounds like you are talking about session hijacking and not session fixation. Session fixation has nothing to do with XSS, and you don't need to steal the token to do it. – Anders Dec 19 '19 at 15:17
  • During an XSS attack the attacker can do anything a client can do. So if the client can set the session, then so can the attacker. Still though, I don't understand why it matters: if an attacker has managed XSS then they can simply steal the session, which is both easier and more effective than attempting session fixation. So again, I'm just not quite sure what you're looking for here, or maybe I just don't follow the situation you're trying to outline? – Conor Mancone Dec 19 '19 at 15:30
  • @Anders Thank you for your comments! https://www.cgisecurity.com/lib/session_fixation.pdf page 6, describes a simple way to fixate the session with XSS. Session hijacking means that we steal the session we never knew, the session that the server issued to the client. Session fixation means that we set the victim's session to the one WE know and wait till he or she logs in. Pages 14 and 15 explain the differences in more details. – ShHolmes Dec 19 '19 at 15:34
  • @ConorMancone Thank you for your comments. Yes, I agree, that it probably would be an easier way to just steal a cookie (not always it is so). But the question was rather: are there ways to fixate the session other than just overwritting the local storage (for example, set the cookie in response from the server or in request from the client)? – ShHolmes Dec 19 '19 at 15:37
  • @ShHolmes My apologies for the confusing comments. Now I understand, I should just have been drinking more coffee earlier on. – Anders Dec 19 '19 at 15:42
  • @Anders It's ok) I've edited my question, since I think from the first version it was not quite clear what all the fuss was about. May be I need coffee too.... – ShHolmes Dec 19 '19 at 15:48
  • @ConorMancone By the way, as for this statement "Once XSS is in scope, it's effectively impossible to keep the session secure" I'd like to make a little adjustment: it's a valid statement if there is no httpOnly flag set, which is the case with sessions passed in headers. But if sessions are set in Cookie header with httpOnly flag, it's not accessible to JS client code. So, passing sessions in headers prevents CSRF but exposes them to XSS. Every technique has a drawback. – ShHolmes Dec 19 '19 at 17:24
  • @ShHolmes using httpOnly cookies for auth doesn't protect you from an XSS attack. It stops an attacker from stealing the auth credentials, which limits impact, but the attacker still has full use of the credentials as long as the user stays on the page with the XSS vulnerabilities. There are even packages that will deploy an XSS payload that let's the attacker use the user's browser as a proxy, allowing them full use of the victims credentials. So the httpOnly cookie limits impact some, but definitely doesn't protect credentials from misuse. – Conor Mancone Dec 19 '19 at 18:50
  • Your document is very out of date. The examples it gives are very basic and often inapplicable. However, I'm starting to get a better idea of what you're asking – Conor Mancone Dec 19 '19 at 19:00

1 Answers1

1

httpOnly Cookies

Just to be clear, your question is implicitly excluding sites that store session ids in httpOnly cookies. The reason is because such cookies are completely inaccessible to javascript, so it would not be possible for them to send the session id up in a custom header if the session id was stored in an httpOnly cookie. You already know this, but I want to state this requirement out loud.

All Other Methods of Session Management

In literally every other case for session management, session fixation is possible in the event of an XSS attack. In short, if the Session Id is in a custom header then it must be accessible to their javascript so that they can attach it. If it is accessible to their javascript, then it is accessible to the attacker's javascript. The only data source that javascript doesn't have access to are httpOnly cookies, which aren't being used here.

Session Ids are stored in local storage? An attacker's javascript can replace the value stored in local storage. The session ids are stored in a non-httpOnly cookie? The attacker can replace it there too. Other than an httpOnly cookie, there are no data sources that would be accessible to their javascript and not the attacker's. As a result, session fixation is just a matter of reverse engineering the javascript to figure out where the token is stored. There is no need to intercept requests or get web workers installed (although you can possibly intercept requests without web workers). A malicious extension could certainly modify requests in transit, but again this is not necessary - an XSS attack alone is sufficient.

Again, to try to emphasize the important point here: you wouldn't want to bother trying to intercept requests. That can be quite a pain. All you need to do is figure out where and how the session id is stored client side, and inject your chosen session id there. Since it is accessible to their javascript, it is accessible to the attacker's javascript.

Community
  • 1
Conor Mancone
  • 29,899
  • 13
  • 91
  • 96