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!!
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:
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.
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.
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.
