1

I am currently conducting a pentest and I found an application vulnerable to http header injection, where the user input is reflected after the Content-Type header, and the Content-Type is set to application/force-download. That is, the attacker can pass content in the GET parameter that is then reflected in the header. Imagine a request like so:

/vulnerable_application?param=reflected-header_malicious_payload

Which then yields a reponse like so:

HTTP/1.1 200 OK
Date: Wed, 06 Nov 2019 22:14:22 GMT
Server: [...]
Content-Length: 2
Content-Type: application/force-download; charset=UTF-16
Content-Disposition: attachment; filename=reflected-header_malicious_payload
Connection: close

I am trying to asses the severity of this finding, in particular whether it would allow for an reflected XSS attack. It seems to me that there is no way to get around the Content-Type: application/force-download which leads me to believe that the severity is pretty low.

1 Answers1

1

You're probably right that I also can't think of a way to get XSS this way, due to the Content-Type: application/force-download header.

That said, once you can write HTTP headers, there is a bunch of dirty stuff you can do that is totally unrelated to XSS. Off the top of my head:

  • HTTP Response Splitting and smuggling
  • Adding another cookie header, which lets you force cookies into the victim's browser under the domain of the vulnerable site (I'm sure if you start overwriting legitimate cookies, then you can get interesting behaviours the next time the user connects to the legitimate site using the poisoned cookies).

If this was my pen test, I would probably stop here and file "HIGH - HTTP Header Injection". If the customer wanted a PoC, my next step would be looking through the list of HTTP Headers for one that I could do some damage with.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207