search

IDPF / epub-testsuite

A collection of EPUB documents to systematically test EPUB Reading System conformance
Other
80 stars 26 forks source link

remote file test xhr-020 should fail when CORS is not supported #34

Closed whmccoy closed 9 years ago

whmccoy commented 11 years ago

scripting-003.xhtml has a simple test for getting a remote file:

// try to get a remote file testRequest("http://idpf.org/epub/30/spec/epub30-contentdocs.html", "xhr-030-result");
};

It indicates "PASS" on Readium but IMO it should fail because the http header for that URL does not presently return the CORS specified value: Access-Control-Allow-Origin: * Running scripting-003.xhtml standalone in a browser for example returns "FAIL" even though of course the browser supports remote file access.

I'm not sure it's explicitly defined anywhere in EPUB 3.0 specs (perhaps a spec issue!) but I believe that the EPUB file's internal relative URL space is implicitly the origin and that requests external to that should therefore be enabled only via CORS.

This implies that this test should probably fork into two variants, one that makes a request to a known CORS-enabled URL that is expected to PASS and one that makes a request to a known non-CORS-enabled URL that is expected to FAIL.

mattgarrish commented 11 years ago

Agree that it should be a failure for scripting without CORS, but “the EPUB file's internal relative URL space” is a sticking point if we’re also going to test access restrictions, no? By default, the browser/RS sends the origin domain for you, and we don’t specify what that should be in the specs. Without it codified, we could only reliably test that a server allows any access, not knowing what domain any RS will send.

The granularity of per-publication origins might prove a maintenance nightmare for restricted access, too. Publishers would have to update their servers for every book they release, and with only the book’s word for it’s origin, how does the RS know any book is what it says it is? (e.g., it’s easy to get an ebook, inject some malicious code, and spread it to unwitting people to use.) A rule like that might also conflict with web-based reading systems, which will send the app’s domain.

I realize I’m probably just rehashing some of the scripting security prose we already have, but it seems like CORS is limited to allow everything and deny nothing, or is that understood given the nature of reading systems?

(We’ll need to IDPF server configured to enable CORS headers to update that test, too.)

whmccoy commented 11 years ago

Yes, I think there are some EPUB spec issues lurking in here (that its runtime security context is underspecified), and Origin is one. But it may be good to let related work in recently charterd W3C System Application WG ripen and then look to adopt/align with it. See, e.g.: http://abarth.github.com/sysapps/drafts/security.html which does propose an Origin approach.

Meanwhile though i think you are right that XMLHttpRequest can succeed only accessing endpoints whose servers have CORS configured to allow everything. But this need not necessarily be done via a chance on idpf.org (although that's certainly doable), we could instead embed a test that pings a well-known 3rd party site that uses CORS.

mattgarrish commented 9 years ago

XHR test has been updated. Fails now when requesting from a server without cors headers set (idpf), including testing from local browser.