Hacker News Reader

Comment by kimmobru | Hacker News Reader

Oh wow, that's a bit embarrassing :) The urls are now restricted to http and https only. Thanks for noticing!

I am not at a computer noe, so I can’t test it, but do you take redirects into account? I hope you are not just whitelisting the initial URL, but also any URL’s it redirects to. If you don’t already, you should probably just disable redirects in whatever library you use.

I gave this a thought for a moment. Since we're using a real browser, there are huge amount of different ways to get the browser display a file:// link. Redirect is one, window.location.href is another, etc. The service shouldn't be run publicly in the internet for real use cases. If you do, the server should be designed in a way that it's not dangerous if the web server user gets read access to file system. I added a warning about this in the top of the README.

You are using Chrome headless therefore you can use group policy to add "file://" to the URL blacklist; see http://www.chromium.org/administrators/policy-list-3#URLBlac...

By default: if Headless Chrome hits a redirect to a file:// it returns: net::ERR_UNSAFE_REDIRECT

window.location.href = 'file:///' will return console error: "Not allowed to load local resource"

This is ripe for an easter egg if you request a file:// URL PDFs support compression, right? I wonder how hardened they are to zip bombs...

Consider adding FTP.

It might be better to blacklist file:// rather than trying to have a comprehensive whitelist.

Not sure if this is sound advice. Blacklisting is a cat and mouse game, especially for security. The risk of a missing entry on a blacklist is worse than on a whitelist.

Reply on news.ycombinator.com