CRLF Injection Vulnerability utilization and instance analysis

0x00 background

CRLF Injection is rare. I caught it this time. I think http://www.bkjia.com/Article/201406/312606.html has some students do not know much about this vulnerability, or even cannot tell it with CSRF, I will elaborate on it.

CRLF is short for "carriage return + line feed" (\ r \ n. In the HTTP protocol, the HTTP Header and the HTTP Body are separated by two crlf s. The browser extracts and displays the HTTP Content Based on the two crlf s. Therefore, once we can control the characters in the HTTP message header and inject some malicious line breaks, we can inject some session cookies or HTML code, so CRLF Injection is also called HTTP Response Splitting, HRS for short.

HRS is a security issue that is more dangerous than XSS. Let's look at the specific cause.

The simplest way to use HRS is to inject two \ r \ n, and then write XSS code to construct an xss.

0x01 instance

For example, the general website will use Location: http://baidu.com in the HTTP header for 302 jump, so we can control the content is Location: a URL of XXX in the end.

So a normal 302 jump package is like this:

HTTP/1.1 302 Moved Temporarily Date: Fri, 27 Jun 2014 17:52:17 GMT Content-Type: text/html Content-Length: 154 Connection: close Location: http://www.sina.com.cn

However, if we enter

http://www.sina.com.cn%0aSet-cookie:JSPSESSID%3Dwooyun 

A line feed is injected, and the returned packet will become like this:

 HTTP/1.1 302 Moved Temporarily Date: Fri, 27 Jun 2014 17:52:17 GMT Content-Type: text/html Content-Length: 154 Connection: close Location: http://www.sina.com.cn Set-cookie: JSPSESSID=wooyun

At this time, we set a SESSION for the visitor, resulting in a "SESSION fixing Vulnerability ".

Of course, HRS is not limited to session fixation. By injecting two crlf s, it can cause a reflected XSS that ignores the browser Filter.

For example, a website accepts url parameter http://test.sina.com.cn /? Url = xxx, xxx is placed behind Location as a jump. If we enter

http://test.sina.com.cn/?url=%0d%0a%0d%0a

Our return package will become like this:

 HTTP/1.1 302 Moved Temporarily Date: Fri, 27 Jun 2014 17:52:17 GMT Content-Type: text/html Content-Length: 154 Connection: close Location:

Previously, the browser will split the HTTP packet into headers and bodies based on the first CRLF, and then display the body. Therefore, this label will be displayed, resulting in an XSS.

Why is it that the browser filter is ignored? Another problem is involved here.

The Filter of the browser is a protection policy that the browser should protect against some reflective XSS. When the url contains XSS-related features, the Filter will be filtered out and not displayed on the page, so XSS cannot be triggered.

How can I disable the filter? Generally, this is not the case for users. the browser will not enable filter only when the http header in the data packet contains X-XSS-Protection and the value is 0.

It should be clear that HRS is not a vulnerability that injects HTTP headers. We can inject X-XSS-Protection: 0 into the data packet, use two CRLF s to inject XSS code, so that we can bypass the browser filter and execute our reflected XSS

Therefore, the harm of HRS is greater than that of XSS, because it can bypass the filter that the general XSS cannot bypass and generate Session Fixation vulnerabilities.

Let's take a real case. A sub-station in Sina has a url jump vulnerability, which is not very harmful. So I thought of CRLF Injection. When I tested

http://xxx.sina.com.cn/?url=%0a%0d%0a%0d%3Cimg%20src=1%3E

When the image is displayed on the page, CRLF Injection is successful:

Let's try XSS:

Check the console and it was intercepted by XSS Filter.

Then we inject

X-XSS-Protection:0

To the data packet to see what effect:

@ Mramydnei also came up with a method that uses character encoding to bypass XSS Filter. When the encoding is a is-2022-kr, the browser ignores % 0f, in this way, we can add % 0f after onerror to bypass the filter, provided that

<metacharset=ISO-2022-KR>

Of course, in Location: Only webkit kernel browsers can be injected here. other browsers may jump to and make mistakes. However, for chrome usage, the harm is enough.

0x02 repair

How to fix the HRS vulnerability is to filter line breaks such as \ r and \ n to prevent the input data from being contaminated with other HTTP headers.