8
  1. Download example.html -file from random website to my computer desktop
  2. Open example.html -file from desktop with Google Chrome
  3. Now Chrome executes javascript from example.html -file that searches through computer files from desktop or documents -directory and sends them to attacker controlled website or server

Can javascript search through my files from desktop and send them to attacker? Is this possible?

If this scenario is possible, then how to block this attack?

nptxzs
  • 181
  • 2
  • 4

2 Answers2

6

Can javascript search through my files from desktop and send them to attacker?

Historically, yes, browsers have treated the file: scheme as one unique origin and the attack you describe would have been feasible.

But today, no, Chrome and Firefox enforce same-origin policies that restrict access between local files. (However, not all browsers do that. Most notably, Microsoft Edge still doesn't restrict read access between local files, as @dandavis has spotted.)

That is, when you open an HTML file at file:///downloads/malicious.html in one of these browsers, a script in that document can not freely search the file system and send home sensitive files. However, the exact way how SOPs on the file: scheme are implemented varies between browsers and it isn't really well documented - and there doesn't seem to be an established standard for it.

Mozilla has some (potentially outdated) details documented here:

Starting in Gecko 1.9 [Mozilla's browser engine], files are allowed to read only certain other files. Specifically, a file can read another file only if the parent directory of the originating file is an ancestor directory of the target file. Directories cannot be loaded this way, however.

For example, if you have a file foo.html which accesses another file bar.html and you have navigated to it from the file index.html, the load will succeed only if bar.html is either in the same directory as index.html or in a directory contained within the same directory as index.html.

I couldn't find any relevant documentation for Chrome, but inter-file access seems to be completely locked down. E.g., Chrome didn't let me issue a cross-origin request for a file: URI:

Failed to load file:///tmp/malicious.html: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https.

Even trying to have a file: document access the DOM of an iframe with the same URI failed:

Uncaught DOMException: Blocked a frame with origin "null" from accessing a cross-origin frame.

That said, opening untrusted HTML files locally is still more dangerous than loading them from a website. Although they may not be able to read all local files, they could still employ attacks such as XSSI (cross-site script inclusion) to make other local files potentially leak sensitive information.

Community
  • 1
Arminius
  • 44,242
  • 14
  • 143
  • 138
  • Nice find on the Mozilla documentation. I didn't know they sandboxes it that well. Nice to see that. – Alexander O'Mara Jan 13 '18 at 00:21
  • you can (could?) load local scripts and images files from child folders, otherwise "Save as Complete" wouldn't work. in this manner, you can load/inventory some of the FS contents. – dandavis Jan 13 '18 at 12:12
  • @dandavis Access != load. Loading scripts and embedding images obviously works. But accessing (reading) their content doesn't. – Arminius Jan 13 '18 at 14:35
  • 2
    i was going to talk about image dimensions, script inclusion side-effects (new globals) in chrome, and other minor leaks, but in testing, this works in Edge, which is the default .html file handler in windows: `fetch("../index.txt").then(x=>x.text()).then(console.log);`, where _index.txt_ is in the parent folder of the html file's parent folder; yikes. i know OP restricts to ch+ff, but i feel it's worth noting. – dandavis Jan 13 '18 at 14:48
  • @dandavis I'm not a Windows user and OP didn't ask for Edge, so I skipped that. But yeah, your finding sounds bad. If you're not planning to submit an answer detailing the issue with Edge and that XSSI on the file system is potentially worse than on the web, I'd amend my answer with that. – Arminius Jan 13 '18 at 15:10
  • go for it. it's an arguable aside, but it's one heck of an aside and needs aired imho, thanks. – dandavis Jan 13 '18 at 15:26
1

No, this is not possible, and with good reason.

Unprivileged JavaScript run in a browser does not have any API's to search the filesystem. Additionally, API's like AJAX and canvas data access will not work for files on the filesystem, preventing reading files at known paths. Some browsers go further, and will not even indirectly load anything at all (HTML, images, CSS, etc.) from a directory higher than the file itself.

Some browsers may offer a filesystem API to privileged content in a browser extensions (Firefox used to) but that would not be accessible to web content.

The only way this might be possible is if the code had a browser exploit that broke out of the JavaScript runtime and any OS-level sandboxing the browser used. Such an exploit would likely work just as well without downloading it first though.

Alexander O'Mara
  • 8,794
  • 6
  • 34
  • 38