4 ms·
Oh wow, that's a bit embarrassing :) The urls are now restricted to http and https only. Thanks for noticing!
by kimmobru 9y ago
Oh wow, that's a bit embarrassing :) The urls are now restricted to http and https only. Thanks for noticing!
- rocky1138 9y agoConsider adding FTP. It might be better to blacklist file:// rather than trying to have a comprehensive whitelist.
- nothrabannosir 9y agoNot 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.
- qw 9y agoI 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.
- kimmobru 9y agoI 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.
- cutcss 9y agoYou 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#URLBlacklist http://www.chromium.org/administrators/policy-list-3#URLBlac...
- jotto 9y agoBy 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"
- kbenson 9y agoThis 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...