Why do browsers disallow accessing files from local file system even if the HTML document is also on the local file system?

Question

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.

Answer 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.

Answer 2

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 user's browser to that page to steal your data. Modern browsers may block automatic redirecting, but an attacker could trick people into pasteing the URL in your browser manually. Then even just entering a file: URL in your browser could be risky.

Answer 3

I'm guessing you are writing about Chrome(ium)

There may be (or were) some reasons for not allowing an access to any file on the local filesystem before CORS was widely adopted.

But now I see no reason for not allowing access that are in the same directory or under. No there's absolutly no reason except for lazy (or rather no) implementation of same-origin policy for file://.

Firefox gets it right. Chrome does not care to respond.

To access sensitive file (and back to a server) this supposes you circumvent both the same policy and CORS.

If there are sensitives files in or under a directory where one can write html files then you have bigger problems (or the browser is writing where it shouldn't or you user is a m*ron (or the sysadmin gives it too much rights))

It's a shame Chrome made obsolete all xml+xsl "application"

Answer 4

It's been a few years since this was an issue for me, but here I am. I came to confirm that I remembered the state, but what I didn't see was a reference to HTAs.

Hyper Text Applications (HTA) were an old tool MS had for the days in which vbscript and javascript where the languages of choice for scripting the OS. They offered a way to present an HTML form over your locally run logic scripts.

They still work.

Over the years, I've used them to deploy local dashboards that require access to a dataset or database. The thing I found useful was that you can load modern libraries into them, access a SQLite database stored on the disk (or read in a CSV file, or scan a folder filled with JSON objects), and load it into the browser's lcoal DB instance (I've used PouchDB for that). My favourite use was to read from Jira, edit memory in Browser/PouchDB, and write to QuickBooks billing (Access Database file), and display metrics on screen.

With the advent of Powershell, javascript on the OS became obsolete, and so did HTAs. These have been replaced by PowerShell GUIs in terms of support by Microsoft

... but as of a few moments ago, they still work.