How does setting Origin to null in a redirected CORS request protect against a confused deputy attack?

If a cross-origin resource redirects to another resource at a new origin, the browser will set the value of the Origin header to null after redirecting. This prevents additional confused deputy attacks, but a cost of making it difficult to transparently move CORS resources that support (cookie-based) credentials and simple requests across domains with 3xx status codes as one can with non-CORS resources. It is possible to redirect same-origin resources to a cross-origin location (single hop only) because browsers will transparently apply the CORS algorithm to such requests and include the Origin header for the first hop.

It's set to the string null which you can match if you want to (but you shouldn't), but that still doesn't explain how you can execute a confused deputy attack if the origin header isn't changed.

Yes, obviously, but how does that protect against a confused deputy attack? What attack would be possible if the following origin check passes?

unless the request kept a log of each bounce, the 3rd hop would have no knowledge of the originating server with which to validate the request against a cors domain spec. if it's approved by default, bingo.

2 Answers 2

That paragraph is tersely written, and the use of "redirects to another resource at a new origin" in the first sentence isn't quite right.

Here's a simple contrived example. Let's say you are malicious, and there is a web application that uses the services of a privileged API via CORS, so the web application's Origin is trusted by the privileged API. And let's say you want to get access to the data behind that privileged API, but your Origin of course is not trusted.

You create a simple useful service that you offer via CORS, and you get the web application to include your service in a page- any page- under its trusted Origin. That page does not need to access the privileged API.

(Of course, once you're in the page of your victim you can do whatever you want, but bear with me.)

If you decide to change your CORS service from issuing a 200 with some data to issue a 3xx to the privileged API- crossing resource domains- this creates a trust problem.

The actual Origin- the page that embedded your resource- will be trusted by the privileged API. But it didn't issue the request, and it may not want to be talking to the privileged API at this particular point in time.

Instead, you issued the redirect, and while you are trusted, in part, by the Origin, you are not trusted by the privileged API. If the browser follows your 3xx and sends along the Origin, you get to illegitimately piggy back on the trust given by the privileged API to the Origin.

What is the browser to do? A reasonable answer is to not follow the 3xx at all, but that would disallow use cases for which trust is not concern. Issuing the request with a "null" Origin allows those use cases, but prevents the exploitation of trust that sending along the original Origin header would allow.