If your code accepts URIs as input, filter out “file://”
1–10 of 161 posts
Re: If your code accepts URIs as input, filter out “file://”
#2The original link seems down, but it has been saved at archive.org: http://web.archive.org/web/20160912105232/https://blog.steve...
Re: If your code accepts URIs as input, filter out “file://”
#3The original link seems down, but it has been saved at archive.org: http://web.archive.org/web/20160912105232/https://blog.steve...
Looks fine for me (the author), but glad to see a cached copy the content is pretty minimal.
Rate-limiting hasn't kicked in, and I'm seeing a steady stream of visitors.
Re: If your code accepts URIs as input, filter out “file://”
#4Wrong way around: only allow http:// and https:// (and generally filtering out anything thats not letters, numbers, slash or dot is probably a good idea. Remove any sequences of more than one slash or dot.
Re: If your code accepts URIs as input, filter out “file://”
#5I usually only do this, if I'm putting a user-submitted URL into file_get_contents: if(substr($_GET['url'], 0, 4) != 'http') { exit; }
Re: If your code accepts URIs as input, filter out “file://”
#6Wrong way around: only allow http:// and https:// (and generally filtering out anything thats not letters, numbers, slash or dot is probably a good idea. Remove any sequences of more than one slash or dot.
>Wrong way around: only allow http:// and https://
For myself, it's a subtle change in developer thinking - "what should I allow" vs "what should I exclude" - that's paid off massively over the years.
Re: If your code accepts URIs as input, filter out “file://”
#7I usually only do this, if I'm putting a user-submitted URL into file_get_contents: if(substr($_GET['url'], 0, 4) != 'http') { exit; }
> file_get_contents
FYI, if you ever need a quick performance boost, switch to using curl for these calls. The difference is noticeable to the naked eye.
Re: If your code accepts URIs as input, filter out “file://”
#8I usually only do this, if I'm putting a user-submitted URL into file_get_contents: if(substr($_GET['url'], 0, 4) != 'http') { exit; }
If thats the only validation on calls to file_get_contents, that could very easily be bypassed. Entering something like just "/etc/passwd" for example.
Re: If your code accepts URIs as input, filter out “file://”
#9Wrong way around: only allow http:// and https:// (and generally filtering out anything thats not letters, numbers, slash or dot is probably a good idea. Remove any sequences of more than one slash or dot.
Exactly.
Whitelist only trusted schemes, do not wait to blacklist untrusted.
I wrote the Go HTML sanitizer: https://github.com/microcosm-cc/bluemonday and have a rule for user generated (untrusted) content that basically does whitelist just the things that one can trust: https://github.com/microcosm-cc/bluemonday/blob/master/helpe...
That states that URIs must be:
1. Parseable
2. Relative
3. Or one of: mailto http https
4. And that I will add rel="nofollow" to external links, and additionally I'll add "rel="noopener" if the link has a target="_blank" attribute
Oh, and I do not trust Data URIs either.
Re: If your code accepts URIs as input, filter out “file://”
#10This is the confused deputy problem. The most general solution to this class of vulnerabilities, SELinux, has been largely ignored. Does SELinux need more work to "bring it to market", or is it just too complicated and needs to be simplified?