Hacker News Reader

Comment by linkmotif | Hacker News Reader

Just the other day I saw some file://-based exploit. Didn’t read the specifics of this, but not validating a URL’s scheme must be a very common source of problems. It’s so easy to overlook the scheme when everything is https?:// all the time. But alas, file://, it’s real, browsers attempt to work with it. Another edge to be aware of!!

View on HN

Lots of online services are vulnerable to this kind of attack. I've seen numerous forms that do things like check security headers, scan your HTML, or do benchmarking. You're supposed to enter a site like:

* https://example.com/

But instead you can access local files via file:////etc/passwd

The remote site does not get the contents of your /etc/passwd if you do that, due to same origin policy. And you cannot see the /etc/passwd of the remote site. If you want to see your own, you can also open your /etc/passwd in vim. So, there is no vulnerability there.

No. You can get the remote server's /etc/passwd in some cases. Most OS's would block a file that obvious from a non-privileged app but maybe /tmp/session.32eg3g3.txt is readable. There are sensitive local files that are readable by your web app so you must take precautions. This is in fact a common security hole caused by careless developers.

With a file:// URI? No you can't. That isn't how that works. You're confusing this with remote file disclosure attacks, which are totally different.

The code I'm talking about typically calls `curl`, or similar, to download a remote URL, and show "stuff" about the contents.

I certainly don't expect to see my own file, but it is very common for remote sites to show THEIR /etc/passwd file, because they've used PHPs fopen function, or a curl-wrapper which didn't disable file:// URIs.

One risk mitigation for that is to sandbox the browser with something like firejail and whitelist access to only the profile directory and /tmp

This is the same exploit, it's from Friday.

Reply on news.ycombinator.com