1210993 - CORS: broken origin comparisons when default ports are present in server header

Status: RESOLVED INVALID

(Core :: DOM: Security, defect)

Description

[François Marier [:francois]]

Something is wrong with origin comparisons in CORS because while this works:

  $ curl https://people.mozilla.org/~fmarier/cors/noport.html
  <script src="https://fmarier.org/cors/noport.js" crossorigin="anonymous"></script>

  $ curl -i https://fmarier.org/cors/noport.js
  ...
  Access-Control-Allow-Origin: https://people.mozilla.org
  Content-Type: application/javascript

  alert('ran noport.js!');

adding the port to the CORS header on the server:

  $ curl https://people.mozilla.org/~fmarier/cors/port443.html
  <script src="https://fmarier.org/cors/port443.js" crossorigin="anonymous"></script>

  $ curl -i https://fmarier.org/cors/port443.js
  HTTP/1.1 200 OK
  ...
  Access-Control-Allow-Origin: https://people.mozilla.org:443
  Content-Type: application/javascript

  alert('ran port443.js!');

makes the origin check fail with this devtool error:

> Cross-Origin Request Blocked: The Same Origin Policy disallows reading the
> remote resource at https://fmarier.org/cors/port443.js. (Reason: CORS header
> 'Access-Control-Allow-Origin' does not match
> 'https://people.mozilla.org:443')."

which is confusing because it implies that the origin of the page is the one
with the port and that the one in the CORS header doesn't have the port,
whereas it's actually the opposite.

Chrome has the same problem but returns a better error message:

> Script from origin 'https://fmarier.org' has been blocked from loading by
> Cross-Origin Resource Sharing policy: The 'Access-Control-Allow-Origin'
> header has a value 'https://people.mozilla.org:443' that is not equal to the
> supplied origin. Origin 'https://people.mozilla.org' is therefore not
> allowed access.

Comment 1

[(no longer active)]

This is security sensitive, right?  I'll take a look next week.

Comment 2

[(no longer active)]

I think this behavior is per spec, since the Origin header on the second request would be "https://people.mozilla.org" and the CORS spec just tells us to do a case-sensitive comparison against the Access-Control-Allow-Origin header value which is not the same, so the CORS check fails.  Anne, is my reading of the spec correct?

Comment 3

[François Marier [:francois]]

So this is a spec bug then?

It's really sub-optimal because it makes us fail two tests on http://w3c-test.org/subresource-integrity/subresource-integrity.html even though we actually pass when they are run locally.

Comment 4

[Anne (:annevk)]

Well if it makes us fail tests the tests are wrong. It's very much intentional that it's just a string comparison against the Origin request header (when it's not "*") and nothing more complicated.