CORS headers for Access-Control of secondary resources

Hi all

I am wondering if we could extend CORS to allow applications to
opt-out of cross-origin inclusion of protected resources.

Currently, CORS headers are not checked for third-party secondary
resource inclusion. For example, imagine vulnerable.com/foo.js
includes data in the script that contains sensitive information based
on user cookies (or parameters in the URL). attacker.com can include
<script src=vulnerable.com/foo.js> and the script will execute in
attacker.com context, allowing the attacker.com to possibly learn some
secret (for how attacker.com can learn secrets in foo.js, see Adam
Barth et al.'s fantastic paper on Rootkits for JavaScript
Environments)

I was thinking if we could extend CORS to allow vulnerable.com to
opt-in to stricter protection (put another way, opt-out of
cross-origin inclusion). To do this, vulnerable.com could send
Access-Control-Allow-Origin:vulnerable.com and the browser will *only*
include and run the script in the context of vulnerable.com,
disallowing other includes.  This also provides a defense against
other scenarios where secondary resources like images/styles have
secret information in them (not clear how often though).

This isn't a defense for CSRF, since the browser needs to make the
request to decide whether to allow the response to go through. The
browser also doesn't need to send any new headers in the request
(although, sending a origin header will make this proposal a lot more
useful).

What do others think?

Cheers
Dev

Received on Wednesday, 4 December 2013 23:07:53 UTC