9

In HTTP response there is the following header with attacker controlled content:

Content-Disposition:attachment; filename="attacker_controlled.html"

The only characters that can't appear in attacker controlled value are [CR] and [LF] (they can't appear in any combination). In all places where I read about HTTP header injection it was told about injecting those characters.

Is it possible to do HTTP header injection or some other harmful attack without CRLF?

makerofthings7
  • 50,090
  • 54
  • 250
  • 536
Andrei Botalov
  • 5,267
  • 10
  • 45
  • 73
  • 1
    If the attacker controlled part is the filename, I'd filter `"` as well. Filtering `\0` (and possibly all codepoints <32) sounds like a good idea too. – CodesInChaos Jan 06 '13 at 16:43

2 Answers2

4

Depends what you mean by stripped. (python's string.strip() method only removes occurrences from the beginning and end, which doesn't stop CRLF injection.) If you are replacing all occurrences "\r\n" then you are still vulnerable to HTTP response splitting. This is because every http client and server I know of also recognizes the "\n" character alone as a delimiter. Although in this case all we care about is browsers.

The best way to always replace all occurrences of newline "\n" with nothing "" and the "\r" with nothing "", separately for good measure. I have never seen an implantation of the HTTP protocol that just looks for "\r", so as far as I know this has zero security impact, but you should do it anyway for good measure. If you are also worried about HTTP attributes then you also need to strip " ", "\"" and ";", but that also depends on where in the http header the attacker controlled string is.

rook
  • 46,916
  • 10
  • 92
  • 181
  • CR, LF, CRLF etc. can't appear there. Issue about LF was told in Michal Zalewski's Tangled Web. – Andrei Botalov Jul 13 '12 at 18:20
  • @Andrey Botalov I loved "a tangled web", beautiful book. If you can show me a platform where a cr alone is an issue i'll be impressed. That being said i always filter both for good measure, even though as far as i know the cr has zero security impact. – rook Jul 13 '12 at 18:42
  • @Andrey Botalov also if you replace all CR and all LR then CRLF can't exist. That right there is a classic logic error :). – rook Jul 13 '12 at 18:50
  • This year I've reported issues on two open source htp servers or proxy isues where CR in headers was managed like an LF. So sadly "it happens". – regilero Apr 23 '15 at 08:08
  • Does the HTTP specification allow \n as a delimiter? (If not, then isn't it technically a vulnerability in the browser?) – user253751 Jun 03 '15 at 23:37
  • @immibis yeah \n works alone for all servers/clients in common use. More broadly every CRLF delimited protocol will usually just accept a LF as a delimiter. Don't take my word for it, load up netcat and try it for yourself. – rook Jun 04 '15 at 18:05
  • @rook I know that most clients and servers accept it. I was wondering if the standard said it should be accepted. If not, then a program could introduce a vulnerability by following the protocol *correctly* - an interesting situation. – user253751 Jun 05 '15 at 02:19
3

I don't know of any way to do HTTP header injection, under the conditions you mention.

However, there are other risks, such as path traversal attacks, downloading of active content, or overwriting system standard files. I recommend reading RFC 6266, Section 4.3 and RFC 2183, Section 5, which describes some of the risks. (RFC 6266 is the one that defines the Content-Disposition header.) See also this blog post for discussion about XSS risks, if you allow the attacker to control both the filename and the contents of the file.

Community
  • 1
D.W.
  • 98,420
  • 30
  • 267
  • 572