61–70 of 161 posts
Earlier quoted context omitted.
https://en.m.wikipedia.org/wiki/Robustness_principle
https://en.wikipedia.org/wiki/End-to-end_principle Most of the advice in this thread would accidentally disable ftp support.
(Anyway, only MSIE supports this from http(s) origin, and then people wonder, why MSIE is still being used).
Not that you shouldn't also validate input (in a whitelist rather than blacklist as others have said): just goes to show that security is a multifaceted problem with lots of ways to be paranoid. :)
Earlier quoted context omitted.
Ah yes, you're right. Totally mis-read the code. It'd still leave access to any files in the same (or sub) directory starting with http, which realistically would probably be none but still something to bear in mind.
Right, best to check the whole URL. Something like "http/../../../etc/passwd" might get through otherwise.
$url = rawurldecode($_GET['url']);
$url_without_protocol = str_replace(array('https://', 'http://'), '', $url);
$protocol = (stristr($url, 'https://') ? 'https' : 'http');
$page = file_get_contents($protocol . '://' . $url_without_protocol);This is a special case of a Server-Side Request Forget vulnerability. Validating schemes is part of the answer but not the whole answer because attackers can still forge requests to internal resources you have firewalled off from the internet. These were recently released to help people deal with these issues since the details can be finicky: http://blog.includesecurity.com/2016/08/safeurl-server-side-...
Oh, wait a minute.
Earlier quoted context omitted.
Can we please stop trying to enumerate badness [1]? When parsing input it is possible to define the set of valid input, not all possible invalid inputs. Also, anybody accepting input from an untrusted source (such as anything from a network or the user) that isn't verifying the data with a formal recognizer is doing it wrong[2]. Instead of writing another weird machine, guarantee that the input is valid with a parser…
guarantee that the input is valid with a parser generator OK, that works really well... until you learn how much non-RFC-specified behavior is built in to web browsers. Simply building a parser to the RFC will leave you wide open to all sorts of nastiness! The is_safe_url() internal function in Django is a bit of a historical dive into things we've learned about how browsers interpret (or, arguably, misinterpret) var…
Earlier quoted context omitted.
(Also be weary of imagetragick-type bugs too, where the URL starts innocuously and then contains some shellcode, because you pass the URL to something that'll paste it into system() call)
I certainly am weary of bug branding...
The 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.
Wrong 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.
Especially you, Hubspot. I should be able to set a protocol-relative thank you page URL on your forms. If my user reaches your embedded form on my page as http, you should give them http. If they do it on https, it should give them https.
Yes, I have an axe to grind.
"Despite reporting the problem to the author on Friday, and following up the report via Twitter this has not yet been fixed, but after four days I assume I'm not alone in spotting this." Giving someone a weekend to fix something doesn't exactly sound like responsible disclosure. I understand if you get excited because you found a flaw but if you find something like this please be more responsible with publishing your…
Well, I found the same by pure chance before reading this article, and I suspect many more in the HN crowd did. If already half a dozen people on HN report they’ve found it and emailed the person about it, it’s likely it’s too late for responsible disclosure.
Earlier quoted context omitted.
>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.
https://en.m.wikipedia.org/wiki/Robustness_principle