W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2015

Re: [MIX] Require HTTPS scripts to be able to anything HTTP scripts can do.

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Mon, 5 Jan 2015 11:36:25 -0800
Message-ID: <CALx_OUB_4ApY4gkwhExv8B87Bj3iVu-G9jGqGBXWg2iPyNYbkw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
>> - The first is necessary to access arbitrary open data out there on the
>> web.
>
> The problem is that it's somewhat common for pages to use dynamic script
> loaders which fetch script data via XMLHttpRequest and then execute it.

This constitutes a good chunk of the use of XHR; but it is even more
common to take XHR responses and assign them to innerHTML.

I think that as a matter of practical necessity, if we want mixed
content blocking to mean anything, we need to enroll XHR and treat it
similarly to scripts. There seem to be several possible ways to make
this less painful:

1) Content-Type heuristics to specifically allow certain safe
representations of data - but in the exceedingly common case of JSON
blobs, the heuristics can't distinguish between something that will
end up passed to innerHTML or eval, and something that won't.

2) Taint-tracking to detect the XHR data trickling down to unsafe
APIs. Probably extremely messy.

3) Making XHR mixed-content work with certain type of script-limiting
CSP policies. That will not satisfy Tim's requirement to make legacy
content work properly over HTTPS, though.

4) Allowing sites to expressly declare that the content is safe
(X-Not-A-Script-or-HTML: 1). I strongly suspect that such headers
would be copied and pasted to make sites work without undestanding
their implications.

/mz
Received on Monday, 5 January 2015 19:37:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:09 UTC