HTTP Response Splitting Vulnerability on reddit.com(nealpoole.com)
nealpoole.com
HTTP Response Splitting Vulnerability on reddit.com
http://nealpoole.com/blog/2011/01/http-response-splitting-on-reddit-com/
27 comments
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.
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.
Don't forget about register_globals, too. shudders
Your last sentence =~ s/Python/any language/
Even PHP is horrible and insecure to use without a framework today.
Your last sentence =~ s/Python/any language/
Even PHP is horrible and insecure to use without a framework today.
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.
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.
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.
Is it ever reasonable to pass a redirect URL directly via the GET parameters? One other concern would be the ease of phishing attacks, e.g.
goodsite.com/login?redirect=http://www.mybadsite.com
User logs in to Goodsite, and is redirected to a similar-looking page on Badsite.
One safer alternative would be to store the redirect URL in the session (presuming one is available) and read it back later.
goodsite.com/login?redirect=http://www.mybadsite.com
User logs in to Goodsite, and is redirected to a similar-looking page on Badsite.
One safer alternative would be to store the redirect URL in the session (presuming one is available) and read it back later.
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.
Aww, someone submitted my blog post. :)
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.
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.
> "The attack is trivial to prevent; just don't allow newlines (and, ideally, active HTML characters) in redirect content."
Surely the more correct solution is to escape them properly.
eg in the example:
Surely the more correct solution is to escape them properly.
eg in the example:
Location: javascript:
<script>alert(document.cookie)</script>
Location: javascript:%0D%0A%0D%0A<script>alert(document.cookie)</script>
You're right; I wasn't prescriptive enough. Thanks for clarifying.
Wasn't Cache poisoning possible as well?
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.
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.
(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.
What Tom said. To be clear, nealpoole.com is my personal blog, not a company blog: I just happen to enjoy web application security. :)
[deleted]
also, add httponly to your cookies then javascript cant see them
This is an almost cosmetic defense, because Javascript can still launch requests that will bear those cookies, even if it can't bank them for later.
HttpOnly isn't evil, but it's not a solution to the problem.
HttpOnly isn't evil, but it's not a solution to the problem.
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.
The HTTP Response Splitting vulnerability can have many implications, XSS and CSRF attacks are just some examples.
Ah, right. Thanks!
If the server supports the HTTP TRACE verb you can still get the cookie. It would be rare, but possible non the less.
and drops the header.