- From: Mike West <mkwst@google.com>
- Date: Thu, 10 Jul 2014 14:39:38 +0200
- To: Jake Archibald <jaffathecake@gmail.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
The general idea sounds quite plausibly workable to me. That said: On Thu, Jul 10, 2014 at 1:08 PM, Jake Archibald <jaffathecake@gmail.com> wrote: > http://w3c.github.io/webappsec/specs/mixedcontent/#requirements-script > > Currently, XHR & EventSource specifically fail when requesting insecure > content. This section notes that we'd throw exceptions synchronously when we can determine that a request would be blocked. That is, if XHR requests an HTTP resource on an HTTPS page, we'd fail the call to `open()`. I think we'd still want to do that. > This could be replaced with a general rule that CORS checks to HTTP > always fail. This also covers usually passive content that becomes active > via CORS, eg <img crossorigin>. We should totally try this out. It's another nice way to subdivide images into bits that might be blockable. Blink is now blocking mixed <picture> and <img srcset>, by the way. > This means font requests to http would also fail, they could be given an > exception if needed. We're already blocking mixed font requests in Blink. Let's not make an exception. > importScripts('http://...'); - fails > fetch('http://...'); - fails > cache.add('http://...'); - fails > > …as they're all CORS dependant. Yup, let's block these. > fetch('http://...', {mode: 'no-cors'}); > cache.add(new Request('http://...', {mode: 'no-cors'})); > > …these will give back a tainted response. Usual rules can apply if they're > used to satisfy requests to <script>, <img> etc. Why would we allow these requests? Wouldn't we want to block them as well? -- Mike West <mkwst@google.com> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Thursday, 10 July 2014 12:40:26 UTC