1

I found a website that has a well implemented CORS configuration, but for some reason I am able to insert two Origin headers in a POST request, and both of these values are reflected in the reponse.

So if I try:

Host: example.com
Connection: close
Origin: https://evil.com
Origin: https://example.com

The response will be:

HTTP/1.1 200 OK

access-control-allow-origin: https://evil.com,https://example.com
access-control-allow-credentials: true

Is there any way to set this in a payload to be able to exploit this? How could I set the origin value for both of this to exploit it?

0

First of all, to be clear: A site that returns ACAO: {your origin} for arbitrary origins, and also returns ACAC: true, is completely insecure. That site has, for the most part, turned off the same-origin policy's protections for itself; any other site on the Internet is able to view the content of, and take control of, any user's session on the vulnerable site. If you're content with client-side attacks (the category that contains XSS, CSRF, clickjacking, etc.), a site configured the way you describe is wide open. You don't need double origins or anything like that.

Now, as for whether you can do anything interesting with the bizarre behavior the server displays when you send two Origin headers: I don't know. Assuming you can control the Origin header somehow - which isn't supposed to be possible from within a browser, and is easy from something like curl but non-browser clients don't have same-origin policy and thus don't require CORS anyhow - you can try to break the server's processing of the headers. Standard attacks include newlines in the header (using %09/%0D or other encodings) to see if you can inject additional headers or entire body responses, null bytes to try confusing string-parsing code, large numbers of keys that all hash to the same value (using the platform's hashCode implementation) to try overloading a hashtable and causing a DoS attack, and more. Most of those aren't in any way particular to either the Origin header or the behavior you're observing, though.

0

I don't think this is exploitable.

If you want your server to allow any origin (this might not be the safest setup, but anyways), a common way to do that is to simply echo back whatever the client sends as Origin in Access-Control-Allow-Origin. I guess that is what is happening here.

How are you setting two origins? I assume that it is not the browser that sets two of them. If you manipilate the Origin header outside of the browser, it is easy to break CORS in all sorts of ways. But the whole purpose of CORS is to configure the same origin policy, which is a thing maintained by the browser. It is completely expected and normal that CORS can be broken if you use a client that doesn't play along.

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.