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?

  • 1
    Are you interested in session fixation or session hijacking?
    – Anders
    Commented Dec 19, 2019 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. Commented Dec 19, 2019 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
    Commented Dec 19, 2019 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
    Commented Dec 19, 2019 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
    Commented Dec 19, 2019 at 15:09

1 Answer 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.

You must log in to answer this question.

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