HTTP Response Splitting is a type of attack that occurs when an attacker can manipulate the response headers that will be interpreted by the client. This article goes into details on how this can be abused by an attacker to insert arbitrary headers and the impact of this type of attack.

- HTTP Splitv2 - HTTP response splitting exploitations and mitigations

But first… HTTP headers and CRLF

The HTTP protocol partly consists of the header section and the body of each response and request between a web server and a client. In the headers section several things can be transmitted such as URI, cookies, server information and status codes. These headers will be interpreted by the web server or client.

A simple HTTP response (from the server) may look something like:

A simple HTTP response (from the server) may look something like:   - HTTP Response Splitting   Google Docs 4 300x107 - HTTP response splitting exploitations and mitigations

In the above response we can see rn after each line which are two characters, carriage return (r) and a line feed (n), also abbreviated as CRLF. In the HTTP specification, you can set a CRLF to specify the end of the header.

How HTTP Response Splitting exploitations work

One of the most common attacks are to inject a second HTTP-response with defined headers and HTML content, which then leads to XSS. A vast majority of HTTP Response Splitting vulnerabilities occur due to the value of the `Location` header is not properly sanitized, and this is problematic for hackers as the browser will do the redirect and the hackers injected HTML will be ignored.

Imagine the following HTTP response (the red part is injected by the hacker):   

- HTTP Response Splitting   Google Docs 6 - HTTP response splitting exploitations and mitigations

The above attempt won’t be successful because the web browser will redirect to /username and the injected HTML will simply just be ignored.

But what if the attacker had complete control over the value in the `Location` header?

- HTTP Response Splitting   Google Docs 5 300x158 - HTTP response splitting exploitations and mitigations

- hacked image 1024x496 - HTTP response splitting exploitations and mitigations

Because the `Location` value is empty, the web browser will ignore that header, meaning that the rest of the headers will be parsed by the web browser. As a result, no redirect will be made which that the above attack would be successful.

If the attacker can control headers other than `Location`, then XSS is very easy as no redirect will take place that would otherwise ignore the injected headers. Headers that also may be vulnerable to HRS are `Link` and `Set-Cookie` as they often can be controlled by the user.

How about ‘Set-cookie’?

Another common attack is to inject a `Set-Cookie` header which will set a new cookie for the user. This can lead to Session Fixation, or even XSS if the value of the cookie is somewhere reflected and not sanitized. Example:

- HTTP Response Splitting   Google Docs 7 - HTTP response splitting exploitations and mitigations

Which the server then will respond with:

- HTTP Response Splitting   Google Docs 8 - HTTP response splitting exploitations and mitigations

The web browser then saves a cookie with the value of username=<script>alert(‘hacked’)</script>. If the website outputs this somewhere, for example in this context: “Welcome back username”, it would then display “Welcome back <script>alert(‘hacked’)</script>

Because the attacker can control the headers, it is possible to split the headers from the HTML content, and consequently some headers are reflected in the HTML (see first image). In some cases this can be headers with sensitive information, such as `Set-Cookie` thus bypassing cookie attributes such as `HttpOnly`. XSS via HRS can therefore be much more serious than standard XSS.

Learn more on HTTP-headers and the basics to securing web browsers here.

Mitigations

  • Properly sanitize values in the `Location` header. Filter characters such as r and n
  • Don’t let users control the whole value in the `Location` header
  • When using a Content--Policy, it should also be defined in the HTML

How does Detectify help?

Using Detectify’s online scanner, you can check whether your web applications are vulnerable to HTTP-response splitting exploitations mentioned in this article. We also check for other HTTP-header vulnerabilities.

Detectify is automated web application scanner checking for 00+ known vulnerabilities including OWASP 10 and SSRF. Start your Detectify free trial today to see whether your applications are missing HTTP headers and more.


Written by:
Kristian Bremberg

Edited by:
Jocelyn Chan



Source link

No tags for this post.

LEAVE A REPLY

Please enter your comment!
Please enter your name here