I was testing a website and noticed that changing the "Origin" Header's value of a request with an intercepting proxy application results in the web application sending a response with "Access Control Allow Origin" set to the same changed value. I read that the Origin header is protected by the browser and cannot be changed. I want to know if there can be any potential risk associated with this scenario.
If the server simply mirrors the Origin provided by the client into the Access-Control-Allow-Origin header of the response without further checks then it essentially allows any third party to access the resource cross-origin, i.e. it would be a security issue if cross-origin access should be restricted.
But, if this mirroring is only done after additional checks, for example only if the client is authorized, then this is less of a problem. Although there might also be cases where it can be a problem also in this case.
In summary: if this is a problem or not depends on information which are not provided in the question.
Before we go ahead and try to answer this question, I think a few dots need to be connected.
The same-origin policy (SOP) is a browser-level security control that dictates how a document or script belonging to one origin can interact with a resource from some other origin. Basically, SOP prevents scripts running under one origin from reading data from another origin. There may be cases where an app needs to allow other origins for resource access. This is achieved by using Cross Origin Resource Sharing. There can be potential security issues due to CORS mis-configurations.
Now, We understand that CORS can be used to allow cross origin data access in a controlled manner using Access-Control headers. However there is a problem. The
Access-Control-Allow-Origin header works fine if you need to trust only one third party domain with data access. However, there may be cases where a white-list of domains need to be provided cross domain access. This is where the problem lies. None of the browsers support specifying multiple origins in the Access-Control header. You can not even cover sub-domains using wildcards e.g.
Access-Control-Allow-Origin: abc.com xyz.com (NOT SUPPORTED)
Access-Control-Allow-Origin: *.example.com (NOT SUPPORTED)
This has forced many developers to use the origin header value form the HTTP request and dynamically generate the
Access-Control-Allow-Origin header to provide required access. Basically the Origin header value sent in the request is reflected back in the
Access-Control-Allow-Origin reponse header (For a detailed explanation, refer to the blog post above)
This behavior violates one of the basic principles of security:
All data coming from the client should be treated as untrusted until validated.
This behavior basically defeats the purpose of Same-Origin-Policy. As the Access-Control-Allow-Origin header can be controlled by the client, Any malicious domain can now request data from the target web application and read the response. The only condition being that the targeted user should have the target site and the malicious site opened in the same browser at the same time along with an authenticated session with the target site. This provides unlimited access to the malicious site allowing it to perform all kinds of user actions and capture user data.
This is a tricky vulnerability to fix and unless the browsers start providing better support to the CORS white-listing options, We need to programmatically validate the requesting domain before allowing cross origin access.