During a security assessment on a website I found a a redirection link that was reflecting the values in the Location header. The first thing that came to my mind was CRLF injection so I tried a few variation of "%0a" and managed to include my payload in the response:




HTTP/1.1 302 Moved Temporarily 
Date: Sun, 12 Jul 2015 14:18:41 GMT 
Server: Apache 
Set-Cookie: JSESSIONID=5C24F2C96CE37DAA026591F5CAD91900; Path=/; Secure; HttpOnly 
Location: mail.example.com

Set-Cookie: test

Content-Length: 0 
X-Content-Type-Options: nosniff 
Strict-Transport-Security: max-age=31536000 
Vary: User-Agent 
Connection: close 
Content-Type: text/plain; charset=UTF-8

However when I follow the redirection, my request changes to the following:

GET /Set-Cookie:%20test" HTTP/1.1
Host: main.example.com
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close

Where am I going wrong here?

  • 3
    Have you tried 0x0D0A instead of 0x0A ?
    – r00t
    Aug 3, 2015 at 13:28
  • Yeah, no luck either.
    – Mico
    Aug 3, 2015 at 14:09
  • 1
    So what the hell is "%E5%98%8D%E5%98%8A", could you link to some background information on this extremely obscure attack string? My guess is this is some kind of advanced multi-byte injection, care to elaborate? (hackerone.com/reports/52042)
    – rook
    Sep 7, 2015 at 19:36
  • Of course, the researcher who designed this string made a great post about it on this link: blog.innerht.ml/page/3
    – Mico
    Sep 10, 2015 at 9:59

4 Answers 4


I would try to just do something like this:

http://www.example.com/somepage.php?page=%0d%0aContent-Type: text/html%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0a%0d%0a%3Chtml%3E TEST TEXT %3C/html%3E

to start with. Then, if you see 2 different responses, and one of them is a 200, and if you see the text, you can then try whatever stuff with cookies.

  • %0d and %0a are replace with "space", also the response is still 302 (redirection).
    – Mico
    Aug 6, 2015 at 9:02
  • The only payload that creates a new line is "%E5%98%8A%E5%98%8D"
    – Mico
    Aug 6, 2015 at 9:03
  • An attacker shouldn't need two content-types to exploit this issue. In fact, this may confuse the browser. Controlling the header and the beginning of the HTML should be sufficient to control the content of the entire page. I have no idea what micro is referring to about "%E5%98%8A%E5%98%8D", that must be chinese (literally).
    – rook
    Sep 7, 2015 at 19:40

It's impossible to say from your "screenshot" above, but I'd say you're not getting back 0x0D 0x0A after the location, but instead the high bytes you've sent (0x8A 0x8D), including your Set-Cookie.

And you're not interpreting the returned high bytes as CRLF either, so your user agent interprets the Set-Cookie as the non-host-part of the URL.

Try switching the order of CR and LF, and look at a hex dump of the response from the web server.


I think you should send %E5%98%8D%E5%98%8A, not %E5%98%8A%E5%98%8D. Otherwise both tokens get expanded and you probably end up with an extra newline.

On the other hand, the extra newline apparently is not interpreted at all, so I'm wondering if your exploit is indeed working, or whether you're seeing your own payload echoed back harmlessly to you and then interpreted as a spurious newline.

I.e., you send


and the server echoes back a single line

Location: (same as above)

and this is why your browser sends that GET. You appear to see a newline in your response because the single line above gets interpreted as two lines by your terminal.

  • 1
    Could you provide a link to explain %E5%98%8D%E5%98%8A?
    – rook
    Sep 7, 2015 at 19:41
  • Of course, the researcher who designed this string made a great post about it on this link: blog.innerht.ml/page/3
    – Mico
    Sep 15, 2015 at 9:53

I have tried hard on same kind of bug you are talking about. But the same problem that I'm facing is, You can easily inject a cookie or Set-Cookie but Can't exploit further such as XSS, Content Injection etc. You can inject HTML content on 302 Redirection page but It doesn't make sense because very next you will get redirected to page.

In this case only %E5%98%8D%E5%98%8A will work for injecting cookie. Also as I guess you can't split the response header in two working response headers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.