671608 - Access-Control-Allow-Origin header values comma or space delimiter / separator

Status: RESOLVED INVALID

(Core :: General, defect)

Description

[Michal Čaplygin [:myf]]

Attachment: webfont ("Bowlby One" form http://www.google.com/webfonts ), css and html file from description

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0a1) Gecko/20110713 Firefox/8.0a1
Build ID: 20110713030741

Steps to reproduce:

§ hosts:
127.0.0.1 test-cdn
127.0.0.1 test-web-1
127.0.0.1 test-web-2
127.0.0.1 test-web-3

§ local Apache httpd.conf:
LoadModule headers_module modules/mod_headers.so
…
<IfModule headers_module>
Header add Access-Control-Allow-Origin http://test-web-1,http://test-web-2
</IfModule>

§ webroot\test\font.woff: 
(some webfont)

§ webroot\test\style.css:
@font-face {
 font-family: 'font';
 src: url('./font.woff') format('woff');
}

.font {
 font-family: font;
}

§ webroot\test\page.html:
<title>Test page</title>
<link rel="stylesheet" type="text/css" href="http://test-cdn/test/style.css">
<p>
 mmm<br>
 <span class="font">mmm</span> - should not look the same as above
</p>


§ Accessed in Fx 5.0.1 and 8.0a1
http://test-cdn/page.html
http://test-web-1/page.html
http://test-web-2/page.html
http://test-web-3/page.html

§ Just a check, see line 8 :
C:\>wget http://test-cdn/test/font.woff  -S --spider
--20:01:25--  http://test-cdn/test/font.woff
           => `font.woff'
Resolving test-cdn... done.
Connecting to test-cdn[127.0.0.1]:80... connected.
HTTP request sent, awaiting response...
 1 HTTP/1.1 200 OK
 2 Date: Thu, 14 Jul 2011 18:01:26 GMT
 3 Server: Apache/2.2.8 (Win32) PHP/5.2.5
 4 Last-Modified: Thu, 14 Jul 2011 17:42:17 GMT
 5 ETag: "3c00000000810b-8de0-4a80b0dda0805"
 6 Accept-Ranges: bytes
 7 Content-Length: 36320
 8 Access-Control-Allow-Origin: http://test-web-1,http://test-web-2
 9 Keep-Alive: timeout=5, max=100
10 Connection: Keep-Alive
11 Content-Type: text/plain; charset=utf-8
200 OK



Actual results:

Webfont displayed properly just on the first URL.


Expected results:

Webfont displayed properly in first three URLs…

…according https://developer.mozilla.org/en/HTTP_access_control#Simple_requests : "The Access-Control-Allow-Origin header should contain a comma separated list of acceptable domains." 

Fact that it does not work this way was described in 2009 at its talk page: https://developer.mozilla.org/Talk:En/HTTP_access_control. Searching trough bugzilla for permutations of "Access-Control-Allow-Origin", "delimiter", "separator" and "comma" gave me no valid result, so I am creating this bug.

Comment 1

[Boris Zbarsky [:bzbarsky]]

That documentation is wrong.  Per http://tools.ietf.org/html/draft-ietf-websec-origin-02#section-7.1 the BNF for the origin list is:

 origin-list         = serialized-origin *( SP serialized-origin )

where "SP" is a space.  So it's a single-space-separated list, not comma-separated.

But that's the syntax.  The processing model is http://dev.w3.org/2006/waf/access-control/#resource-sharing-check-0 and defines just a case-insensitive string match.

The earlier spec prose that's normative for the server says that the Access-Control-Allow-Origin header must match the Origin header in the request for access to be allowed.  The Origin header in the request may be a whitespace separated list per the IETF draft.

So as far as I can tell, our behavior here is correct.  I've fixed the documentation.

That said, this seems like a huge pain; it means that allowing access to a small whitelist of origins _requires_ server-side scripting.  Jonas, Anne, that seems suboptimal.

Comment 2

[Michal Čaplygin [:myf]]

Re-tested with

<IfModule headers_module>
Header add Access-Control-Allow-Origin http://test-web-1 http://test-web-2
</IfModule>

No change.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> No change.

Yes, see the "processing model" thing above.  If the value sent in Access-Control-Allow-Origin is not a case-insensitive string match for the exact value sent in Origin, the client must disallow access to the resource as the spec stands now.

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

That was an intentional choice.

In almost all cases you either have a static resource which doesn't need protecting since it can be read using wget anyway, or you have a dynamic resource in which case you're doing scripting anyway.

There are exceptions, but they didn't seem common enough to optimize for.

Comment 5

[Michal Čaplygin [:myf]]

Oh, I've got it, sorry (I spent a whole day with this issue and am a bit tired right now.) I'm glad that documentations is accurate now.

I'm wondering if some Apache SetEnvIf Referer magic could be used for real-world whitelisting…

Anyway, thanks a lot for quick clarification!

Comment 6

[Boris Zbarsky [:bzbarsky]]

Jonas, that really sucks for fonts (which are static resources that may have licensing constraints on where you can use them).

Comment 7

[Michal Čaplygin [:myf]]

Boris: that's exactly what I meant; I am working on webpages spread on about twenty domains and I am using one extra as a static container for all design graphics, stylesheets and webfonts. For design it works well, but for webfonts it works in all-except-Firefox browsers (other browsers ignore Control Origin header completely). Yes, I may use just Access-Control-Allow-Origin *, but since fonts my client uses are licensed, I wanted to whitelist relevant domains for a sake of following font vendors TOS. As I see now, the only solution that remains is both
Access-Control-Allow-Origin * AND some server-side referrer-watching magic.

Comment 8

[Boris Zbarsky [:bzbarsky]]

I'd watch "Origin", not "Referrer".

Comment 9

[kadams]

Wow, seriously? I'll second comment #6. This issue sucks for fonts. Firefox requires the header to read webfonts, but won't allow multiple domains, which is perfectly valid by the spec. I'm having a hard time understanding why the bug is invalid.

Comment 10

[Boris Zbarsky [:bzbarsky]]

> but won't allow multiple domains, which is perfectly valid by the spec.

It's valid to _send_ per the IETF syntax spec.  But it does not actually  allow access per the W3C CORS spec.  See comment 1 and the links therein.  That's why this bug is invalid: because we're doing exactly what the CORS spec says to do.  If you think the result is suboptimal (which I do), please raise the issue on the CORS spec.