By comparison, PHP actually prevents you from using \r\n in your header() calls to inadvertently make multiple headers or break off into the body. It spits out a
Warning: Header may not contain more than a single header, new line detected.
PHP has a reputation for insecurity, but it also has a lot of built-in features that help you build secure web apps if used correctly. Some of PHP's earlier experiments were disasterous, (I'm talking about you, magic quotes!) but recent fixes like this actually seem to be pretty well thought out. PHP itself can be seen almost a lightweight web framework, albeit a particularly ugly one.
Other languages, such as Python, were not designed specifically with web apps in mind. So a web developer using such a language must make sure he's doing all the web-specific stuff properly. Which is tedious and error-prone, and that's one reason why nobody should use Python on the web without a decent framework.
Yup. That change dates back to PHP 4.4.2, which was released back in January 2006. It's listed at http://php.net/ChangeLog-4.php as "Prevent header injection by limiting each header to a single line."
I'm actually curious about a recent feature addition, in 5.3.4:
"Paths with NULL in them (foo\0bar.txt) are now considered as invalid. (Rasmus)"
If that's really the case, it seems like Rasmus has eliminated a large swath of null byte vulnerabilities in PHP applications (at least those null byte vulnerabilities involving the filesystem, which are the kind I'm used to seeing). I've been meaning to compile 5.3.3 and 5.3.4 locally to test out the different behaviors.
> If that's really the case, it seems like Rasmus has eliminated a large swath of null byte vulnerabilities in PHP applications.
Yes -- this specific change mitigates a lot of simple local file inclusion vulnerabilities. It's not a cure-all, but it does at least prevent many common antipatterns (e.g, include("languages/$_COOKIE['lang'].php")) from being trivially exploited.
You're talking about what's known as an open redirect. And you're correct: those can definitely be used to make a phishing attack more effective. But as I mentioned, reddit only redirects users to reddit content: you need to provide a relative URL or use a reddit subdomain (eg: http://code.reddit.com) in the dest parameter.
Can you help me better understand the risk to an end user this represents? I just recently implemented some similar login redirect logic and want to make sure I'm handling the redirect value properly.
It's a somewhat complicated variant of reflected cross-site scripting, a.k.a. Javascript injection.†
The vulnerability in response-splitting is passing attacker-controlled newlines unmolested through HTTP header content. Newlines terminate headers. Attacker-controlled content in a redirect that is allowed to contain newlines enables attackers to inject new headers or to terminate the header portion of the request.
Here, Neal's using the attack to inject a false end-of-headers newline and then a fake request body containing Javascript.
The attack is trivial to prevent; just don't allow newlines (and, ideally, active HTML characters) in redirect content.
† The goal of an attacker is to coerce a server into sending her own Javascript; the same-origin rules governing browser security allow that Javascript access to the server's cookies, even though the code is under the control of an attacker.
occurs because something unescaped the %0D%0A%0D%0A. If however you just leave it as it was originally, or alternatively encode it properly after you've decoded it.
Yes. I chose to demonstrate it using an XSS vulnerability because it makes for a much easier to understand PoC (you click on a link and see an alert box). ;)
Had the XSS vulnerabilities failed, I would have spent more time investigating the cache poisoning possibilities.
Was this discovered by chance or was it garnered through an exploit scanner/crawler of some sort? Looking at matasano I'm wondering if exploit scanning is a method of acquiring new customers.
(1) This is a Neal Poole finding, not a Matasano finding.
(2) Reddit isn't a customer.
(3) Suffice it to say that the market for software security is such that we don't really have to do do much other than excel at our work to acquire new customers.
Security noob follow-up: How do you exploit the fact that your javascript can launch requests bearing those cookies? I'm assuming your end goal is to get access to those cookies. Do you do something like POST the contents of the original HTTP request headers that follow your injected \r\n (including said cookies) to a malicious server?
The goal could be CSRF instead of actually reading the cookies. If there's a SessionID cookie for example, you can use JS to GET/POST the request to the server without needing to know the value of SessioID because the browser will send it as part of the request anyway.
The HTTP Response Splitting vulnerability can have many implications, XSS and CSRF attacks are just some examples.
