- From: Mark Goodwin <mgoodwin@mozilla.com>
- Date: Tue, 7 Oct 2014 07:50:47 -0700 (PDT)
- To: Brad Hill <hillbrad@gmail.com>
- Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, Frederik Braun <fbraun@mozilla.com>, public-webappsec@w3.org
> If we require that anything entering the cache have > CORS Access-Control-Allow-Origin *, does SRI meaningfully change this > threat model? It changes it; opinions on "meaningful" may differ. Cache timing is a useful, if slightly blunt, tool for an attacker. A key limitation is that you can get information from each cached resource exactly once; this means you can use it for single shot history scraping, but nothing else (since the act of fetching for timing changes the cache state). There would be no such limitation for content-addressable storage (CAS) if there were no way to limit allowed origins for a cached resource so the CAS equivalent could work for an attacker as often and as reliably as they like. There's another privacy issue lurking in the "determine cross-origin state without clobbering", but that's a different attack. > > Sandboxing the origin also seems to be the only logical answer to > dealing with content where the src/href and non-canonical are on > different origins. > > 2.2) How to interact with CSP. Sandboxed origins for anything > retrieved from CAS means that whitelisting such content by-origin > becomes impossible. You'd have to specify a hash-src in CSP, and the > same hash again in the integrity attribute. I don't think it's unreasonable to use a CSP feature to enable CAS in CSP protected documents (this is where this thread started out). The 'large policy' issue could be a problem though.
Received on Tuesday, 7 October 2014 14:51:14 UTC