3 ms·
Also make sure you don't follow 301/302, or someone can set up a http link which redirects to file:// .
by throwawayReply 10y ago
Also make sure you don't follow 301/302, or someone can set up a http link which redirects to file:// .
- kuschku 10y agoOr just, when following 301/302, call the same function again – which then validates the link completely again.
- throwawayReply 10y agoI'm not sure why you're getting downvoted, it's a little unfair for people to downvote a sensible suggestion without explaining why. One possible downside is that someone could Redirect A -> B and redirect B -> A, which risks tying up your resources following links, but browsers limit how many redirects will be followed, so it ought to be possible to limit redirects.
- 3pt14159 10y agoWait, what? Really!? Can this be used to get shell access somehow? I'm having trouble figuring out how you go from Chrome opening a remote file to _bad thing happens_.
- throwawayReply 10y agoIt's not necessarily browsers, they often mitigate this. The problem is with services that consume other content. For example you might have a service which generates thumbnails of sites. That service might GET https://attacker.example.org/301.html https://attacker.example.org/301.html which itself might 301 back to file:///etc/passwd . If there is insufficient validation then a screenshot of the contents of /etc/passwd might be returned by the service. All of that happens outside the context of browsers and sandboxing. For more of that kind of thing, here's an interesting write up on some vulnerabilities found in Pocket. https://www.gnu.gl/blog/Posts/multiple-vulnerabilities-in-pocket/ https://www.gnu.gl/blog/Posts/multiple-vulnerabilities-in-po...
- tonylucas 10y agoFor those using curl for this, it has flags to specify protocol filters for initial request and redirects https://curl.haxx.se/libcurl/c/CURLOPT_PROTOCOLS.html https://curl.haxx.se/libcurl/c/CURLOPT_PROTOCOLS.html