HTTP Response Splitting (HRS) is one of those webappsec attacks that’s poorly understood, even among the experts (myself included), despite Amit Klein’s best efforts to show us the light. The common understanding is vulnerabilities are rare, severity is high, but the preconditions necessary for an attack lower the threat profile. Recently Arian Evans, WhiteHat’s Director of Operations, took a renewed interest in the complexities of HRS with the assistance of Amit (original discoverer) and several customers. Arian added new checks to Sentinel, adjusted others, and run scans across a few hundred websites to test the vulnerability identification rate. The results were eye opening to say the least. We sent out a customer newsletter last week talking a lot about our HRS R&D, which I thought other would be interested in.
HTTP Response Splitting is a little known, very complex, and frequently misunderstood website vulnerability.
The best way to think about Response Splitting is that it’s executed similarly to Cross-Site Scripting (XSS), but more powerful. Take a loose analogy of a written letter in an envelope. XSS targets the message inside the envelope, while Response Splitting targets not only the message inside the envelope, but the envelope itself.
There several different variations of Response Splitting and many emergent behaviors that make accurate vulnerability identification challenging. WhiteHat has been investing a lot of R&D time perfecting the accuracy of our tests and has started pushing the results to Sentinel users last week. WhiteHat Security plans to release a paper on this subject, breaking down the details of various conditions, implications, and how to measure them. In the meantime, the results of our testing contained a few surprises:
HTTP Response Splitting issues are far more widespread than expected.
Simply put: We’re finding it everywhere. The interesting thing about many Response Splitting vulnerabilities is that the Web application is not necessarily doing anything wrong compared to strict RFC specification. Though this doesn’t change the fact that the website is vulnerable to a malicious attacker taking control of it. Do not be surprised if we find this in a few places on your website(s).
HTTP Response Splitting issues are far more severe than expected.
HTTP Response Splitting issues can be very, very bad, especially on production sites if a caching server is present. If you are using an intermediary caching server/proxy/load-balancer there is a chance that one of several conditions could be true:
1. One-to-Many: One attack can target many users.
2. Persistence: HTTP Response Splitting attacks will be persistent.
3. Domino Effect: One vulnerability may be exploited to take over an entire site.
These issues only occur in very specific situations. We will actively notify you if we discover that those conditions are true. But, this can be tough to measure and we may not always know if the above worst case scenario conditions are possible. This evaluation may require some investigation on your end.
WhiteHat Website Vulnerability Management Practice Tips:
Q. How do I fix a vulnerability to HTTP Response Splitting?
A. Whew, tough question…you should likely take two approaches:
1. Input Validation: You can try to remove every CRLF (\r \n) from input. The problem you will have is that the CRLF is likely to be encoded in some fashion. It could simply be URI-escaped (%0d%0A) or some other Hex or Decimal encoding variant.
If you do not find all the encoded CRLF variants that your application is capable of decoding, you will still be vulnerable.
2. URI-escaping: If you properly escape the URI in every place it is output, like the HTTP Location Header, the CRLF will not be parsed by the browser.
The problem with this approach is that there are some conditions, like personalization cookies, that are not URI data but could be a Response-Splitting attack. We could take our personalization cookie that is name=WhiteHat and make that name=WhiteHat%0D%0A and craft our attack after that.
When your application goes to set that cookie with our name and subsequent attack, the HTTP Response Splitting attack will occur when it reaches the browser.
You would have to try and catch that on input validation, or write a special library to escape \r \n anywhere you found it in output that was potentially user-supplied data.