- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 07 Sep 2010 10:20:03 -0400
- To: J David Eisenberg <jdavid.eisenberg@gmail.com>
- CC: public-webapps@w3.org
On 8/21/10 3:39 PM, J David Eisenberg wrote: > Is it possible to extend the spec to allow a script to read any file that > can been loaded as part of the HTML page, such as an<img/>? That would be a security hole, sorry. > I understand there are good security reasons for restricting file > reads; you don't want someone else's web page to be able to go > willy-nilly through your local hard disk and send all the information > back to the Bad Guys. But this scenario is different; if you have > loaded an<img/>, you must already have read permission for it No. The _user_ has read permissions for it. Your site may well not. > I'm just asking to be able to access its bits. Right; that's what you can't have. Note that if you _are_ allowed to have the image bits, you can just use XMLHttpRequest to get them, right? > Precedent: think of<link rel="stylesheet" href="blah.css"/>; you have > access to all the elements in that file via the DOM, and there's no > security issue involved, even if it's a cross-domain href. All the browsers I know that implement the CSSOM block cross-domain CSSOM access. A few now go further and block certain cross-domain CSS loads period. > That's because it is *not* an arbitrary file on the user's local file system; > it's one that the author has explicitly specified and is allowed to > read. You seem to be assuming that the author who put in the <link> is the same entity who put up the CSS file. This is precisely the assumption that fails in the cross-domain case. > I think my suggestion here meets the same criteria. Am I missing > something obvious on the security front? Yes. Reading information cross-domain without explicit opt-in by the domain being read from is a no-no, generally. -Boris
Received on Tuesday, 7 September 2010 14:20:37 UTC