I have a followup question to this older question: How to exploit a misconfigured CORS policy when a per user authorization token is required?

According to the documentation here, the Access-Control-Allow-Credentials should be able to transport tokens such as Authorization headers because "Credentials are cookies, authorization headers or TLS client certificates."

However, when I attempt the following exploit, I can't seem to get any browsers to forward the token.

I'm attempting to perform the following cross domain request from https://my.domain/:

var req = new XMLHttpRequest(); req.onload = reqListener; 
req.open('GET','https://api.external.domain/',true); 
req.withCredentials = "true"; req.setRequestHeader('authorization',''); 
req.setRequestHeader('cache-control','no-cache'); 
req.setRequestHeader('content-type','application/json'); 
req.send('{}'); 

function reqListener() 
{ 
    alert(this.responseText); 
};

The request is prefligted (OPTIONS method) and the API responds with:

HTTP/1.1 200 OK
Access-Control-Expose-Headers: APIm-Debug-Trans-Id, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-Global-Transaction-ID
Access-Control-Allow-Headers: authorization,cache-control,content-type,pragma
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://my.domain/

So far so good. Now the browser immediately follows up with a GET request, but for this request to succeed I need it to include the header:

Authorization: bearer [redacted]

But the client's browser apparently can't access this token (?) even though I am authenticated to the API. Is there any way to grab this token from somewhere? I can't seem to find it in the browser's local storage and it's not a cookie value either.

up vote 1 down vote accepted

However, when I attempt the following exploit, I can't seem to get any browsers to forward the token.

Given that nothing in your code actually sets the Authorization header it looks like that you are assuming that the header gets automatically set by the browser based on cached credentials, i.e. similar to cookies.

But, such caching is only done for authentication credentials entered by the user in case of basic or digest authentication. If some script in the site instead explicitly sets the Authorization header for a specific XHR no caching of the credentials will be done and therefore also no automatic setting of the Authorization header from cached credentials.

  • I see. That makes sense. Thank you so much for clarifying Steffen! – Lykias Aug 9 at 17:57

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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