1

Many browsers do not allow you to access files on the local filesystem with JavaScript (even if the HTML document is also on the local filesystem).

(source)

Yes I know that the solution is to "install and use a HTTP server for local development" nonetheless I don't understand why should this be required? Allowing a webpage to access local filesystem would obviously be horrible, but what are the risks of accessing local filesystem from local filesystem?

Any time I run a shell script I'm doing this and shell scripts don't prevent me from running cat. The way I'm getting it if I run anything from local filesystem (be it an arbitrary executable, executable I've compiled myself, or an interpreted script, which includes a HTML or JS document!) I'm expected to know what I'm running. Why are JS scripts run in a browser exempt from this assumption? If I have the habit of carelessly running malware from local filesystem I can easily screw myself up in a plethora of ways other than opening a HTML document.

Also: isn't CORS supposed to prohibit cross-origin resource loading? To my understanding requesting a local filesystem resource from a local filesystem resource is hardly cross-origin, rather this is the very same origin, so I don't understand why would CORS be complaining.

On top of that, is requiring me to run a HTTP server for local development improving anything? Doing so requires me to needlessly open a port on localhost. Clearly this can be done in such a way that will prevent outside world from talking to my local server (isn't denying incoming connections enough?) but why open a listening port if I don't have to?

What am I failing to understand here?

EDIT: On the second thought, I do see one reason. Browsers allow users to save a webpage locally. It would make sense to be able to open such webpage in a way that will not damage the local system any more than loading this same webpage from the internet.

  • the concern is email-attached html files having dangerous perms. you can use .hta files (windows) to get high-level hardware access, and firefox lets you configure perms on local files. in terms of testing, localhost lets you run the app in a way that's closer to a production enviroment, rather than having a copy that might not work once uploaded (broken paths, different perms, etc). – dandavis Jan 10 at 19:05
1

I'm going to pull an old article here on an attack that used known image locations on hosts to map out networks for attacks (from 2006):

https://www.cnet.com/news/javascript-opens-doors-to-browser-based-attacks/

Initially, JavaScript had a lot more access to the system than it does today, but over time the value of having a widely permissive javascript agent allowed attacks more visibility to the end point than they should have. If you allow your browser to browse all your files, you give your attacker the ability to launch malware from your browser even while you're just looking at tame cat videos. Oops.

As systems progress, I imagine JavaScript will continue to retain a fairly restricted access level because of the issues open access caused in the past. As the most recent JavaScript zeroday announced on Microsoft demonstrated, it's a pretty big deal causing companies to rip out JavaScript libraries before they could be executed.

Now, you'll notice that I've focused a LOT on JavaScript and it's because of JavaScript that this is really an issue. HTML is certainly benign by itself, but as soon as you open a script block, you've opened a can of worms that need to be retained.

Finally, the reasons why browsers don't support this in any capacity is because it's not a feature you really need for 99% of the population. The webbrowser is not intended to be a web server and is only a client. Building in the server type functions would bloat the browsers which is the opposite function all the browsers are trying to implement (lightweight, fast, resource anemic)

That said, with the increasingly open model for browsers (Microsoft is adopting Chrome), I'm guessing you could attempt to write a module that bakes this functionality in, and I would further guess there would be some developers who would be happy. You just need to see if that niche really wants a local server that doesn't require installing apache, iis, or nginx.

0

If JavaScript in an HTML page could access the contents file system when opened on the file system, it could easily upload that data to a webserver. Then all an attacker needs to do is trick the user into opening an HTML document that was downloaded, and then they have your private data.

Basically, you would have to treat HTML as potentially dangerous like you would any other executable file. This would be kinda similar to how .js files are executable on Windows, which has been an issue recently for Windows users.

It actually gets a bit worse though. Imagine some major software vendor includes some help documentation in an HTML file, which has some common XSS vulnerability. Then an attacker can just redirect the users browser to that page to steal your data. Modern browsers may block automatic redirecting, but an attacker could trick people into passing the URL in your browser manually. Then even just entering a file: URL in your browser could be risky.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.