Im troubleshooting a server that behaves a bit odd. If I make a request that looks like this:

GET / HTTP/1.1
Connection: close
Host: hostname
Someheader: somevalue
Location: Woot?
Set-Cookie: test=funtimes;

I will get a response with all the headers I have sent.

HTTP/1.1 200 OK
Host: hostname
Set-Cookie: test=funtimes
Content-Type: application/json
Someheader: somevalue
Location: Woot?

As you can see, headers are echoed back to the client. I have not seen this before, and I do not think many other people have either.

Can you see any potential security issues with this kind of behavior?

  • It would be almost impossible to do anything malicious with this, unless the attacker can complete a TCP handshake with a spoofed address and have perfect timing, which is highly unlikely.
    – Rogue
    Jun 2, 2016 at 22:27

4 Answers 4


There is a vulnerability called HTTP Response Splitting that may be exploitable, depending on whether newline characters are filtered out.

  • I was thinking that response splitting might be possible, but after testing a couple of newline character variations, it seemed safe. But I might be able to control the content-length header, and I think there was a page that will echo the request body/parameter back to me in application/json format. It might be able to use that to do a response splitting attack. Thanks :) Jun 2, 2016 at 21:45

It may be possible to use this to craft malicious cookies for the website or to send insecure security headers in order to disable framing protection, open the cross domain policy or downgrade or disable cross site scripting protection, which would be very helpful when executing clicjacking, csrf or cross site scripting attacks.

The effectiveness of this would however depend on which headers the server already sets and how the target browser treats duplicate headers if the server have security headers for these things to begin with.

  • 1
    I only think I will be able to add headers using XHR, but even if I update the CORS header, I do not think I can manipulate headers in the preflight check. I did a small experiment, and a proper Access-Control-Allow-Headers will limit what headers I can add. Jun 3, 2016 at 8:08
  • In addition to @Dogeatcatworld's comment, disabling framing protection would only be possible in an XHR too (if there was a way to bypass the pre-flight), and framing protection headers have no effect no XHRs. Same with XSS protection headers. Jun 7, 2016 at 8:35
  • @SilverlightFox - Are there any other methods for adding custom headers? I only know of XHR who can do this. Jun 7, 2016 at 12:30
  • @Dogeatcatworld: Flash and Silverlight can send requests with custom headers. However, any headers received would be up to those plugins to interpret themselves, rather than the browser. Jun 7, 2016 at 12:50
  • I am not too familiar with Silverlight and Flash, so I do not know if this would enable you to do anything specific here. Maybe XHR would work through a silverlight/flash plugin. Do not know if they implement preflight check. Jun 7, 2016 at 18:33

It may be possible to view HttpOnly cookie values during an XSS attack. Also known as, Cross-Site Tracing (https://www.owasp.org/index.php/Cross_Site_Tracing).

Attack scenario


  1. The site is vulnerable to XSS.
  2. Session cookies have the HttpOnly flag set so JavaScript (XSS) can not read the cookie.
  3. XSS and page that echos HTTP request on same origin.


  1. Attacker entices victim into running malicious JavaScript (via XSS for example).
  2. Attacker sends a HTTP request (AJAX) on behalf of the victim to the page which echos the HTTP request.
  3. Attacker records the HTTP response (which includes the user's HttpOnly cookies) and sends it to a server they control.
  4. Attacker uses the cookies to authenticate as the victim. (account compromised)

That being said, session theft is just one risk with XSS, even with this page echoing HTTP requests an attacker may just find it easier to hook the victim's browser with BEeF for example. Or carry out a multitude of other possible attacks leveraging XSS.

EDIT ---

After re-reading your question I noticed that you did not specify where or how the server echos the HTTP request (I assumed via a response body). If this is via the TRACK/TRACE methods (traditional XST via response headers) then it will be much more difficult to view HttpOnly cookies as modern browsers do not allow AJAX TRACE/TRACK methods anymore.

  • 1
    The question specifies that it is a GET request, although the response does look more like that given from a TRACE request.
    – Matthew
    Jun 3, 2016 at 14:22
  • Hi, the server reuses whatever headers the client sent. So I get replies with "User-Agent" headers and whatever else my client sent. Jun 3, 2016 at 15:33
  • If it is a GET/POST request then you should be able to use it to read HttpOnly cookies during an XSS attack. Jun 3, 2016 at 18:57

If there is a Reverse Proxy Cache in front of this server this could easily lead to cache poisoning attacks.

You could build the query with some response headers automatically stored in the cached response like:

  • Content-Security-Policy headers
  • Set-Cookie headers (but usually caches removes theses headers)
  • Transfer-encoding or Content-Length could help building several responses intead of one (@see Http Smuggling and HTTP response splitting)
  • any other security related header you can find

If you have any CR\LF or Lf injections available, or as you said in @korockinout13 response's comment a page with headers in the body, then you can also exploit it to allow javascript access to headers which should not be readable. This is the same as Cross-Site-Tracing (exploiting the TRACE method) issues. Here's a good explanation of it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .