- From: Michal Zalewski <lcamtuf@coredump.cx>
- Date: Mon, 5 Jan 2015 11:36:25 -0800
- 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