Forwarded Header Sabotage | adam-pForwarded Header Sabotage<br>March 30, 2022<br>We all know by now that the leftmost values in the X-Forwarded-For header can be spoofed and only the rightmost IPs – added by your own reverse proxies – can be trusted. The Forwarded header (RFC 7239, 2014) has that same problem, and a new one: If the header is parsed correctly, an attacker can sabotage the whole header.<br>Let’s take a quick trip to understanding how that can happen and how complicated Forwarded parsing can get. (Think about how you’d parse the header as we go.)<br>##<br>Syntax<br>A simple Forwarded header might look like this:<br>Forwarded: for=1.1.1.1, For=2.2.2.2<br>Here’s what a header looks like with an IPv6 value:<br>Forwarded: for=1.1.1.1, FOR="[2001:db8:cafe::17]"<br>Colons and square brackets are not allowed in a “token”, so the IPv6 address needs to be quoted. But that means we could have:<br>Forwarded: host="with,comma=equals;semicolon";for=1.1.1.1<br>So now you can’t just split by comma – you need to be aware of quoted strings as well.<br>But characters can also be escaped, so this is also legal:<br>Forwarded: ext="escaped\"quote";for=1.1.1.1<br>The blessed semicolon-separated parameter names in an entry are “for”, “by”, “host”, and “proto” (case-insensitive). There is allowance for “extensions” using other tokens.<br>Some more legal things:<br>Anything can be escaped, including backslashes: \\. So don’t just delete all them all.<br>Any amount of whitespace around the commas and semicolons.<br>There can be multiple instances of the header, and they must be considered a single list, top to bottom.<br>And some illegal things:<br>Can’t have whitespace around the equal sign.<br>Can’t have disallowed characters in parameter names (and not quotable).<br>Can’t have disallowed characters in a parameter value, if not quoted. (Which mean, for example, that an unquoted IPv6 address is illegal.)<br>IPv6 addresses must have square brackets.<br>Backslash escaping is only allowed in quoted strings.<br>There is only one single library I’ve found that actually correctly parses the header: github.com/lpinca/forwarded-parse.1 Everything else just does what you were probably thinking after the first couple of steps above:<br>Split by comma.<br>Trim whitespace.<br>Split by semicolon.<br>Trim the quotes off the value.<br>Done.<br>Hilariously, this half-assed, RFC-violating parsing is resistant to sabotage and proper parsing is not.<br>##<br>Sabotage!<br>The Forwarded header is unique. It is the only header that:<br>Has untrusted values at the start and trusted values at the end.<br>Is official and specified.<br>This combination leads to its susceptibility to sabotage, where the whole header – including the trusted part – needs to be discarded because of chicanery in the untrusted part.<br>The RFC doesn’t (that I can find) provide any special instructions about salvaging the rest of the header if a single entry (“forwarded-element”) has a syntax error. So, in theory, the whole header needs to be thrown if a spoofer adds, say, f*r= instead of for=.<br>The sabotage is even more fun with an unclosed double-quote:<br>Forwarded: for="1.1.1.1, for=2.2.2.2, for=3.3.3.3<br>It’s illegal to have an unclosed quote, so the whole thing is immediately garbage. But even if you wanted to salvage the header… Where do you close the quote? What do you salvage and discard?<br>##<br>Why is X-Forwarded-For not sabotage-able?<br>Because there’s no spec! People just split by comma, trim, and that’s it. Your trusted reverse proxy will add ", 1.1.1.1" and you don’t really need to care about what comes before that. (Unless you want the leftmost-ish value, but then you’re in the danger zone regardless.)<br>##<br>Mitigations<br>“Half-assed, RFC-violating parsing” is the most obvious. If you’re using a rightmost-ish value, you should know if your reverse proxies are going to be quoting things, escaping, etc. – and they probably aren’t. So do a simple comma-splitting and throw away the stuff on the left.<br>Doing simple splitting means that you could end up with total garbage in your leftmost values – from spoofing or from valid-but-complicated values. You could probably make your parser more-complex-but-still-not-RFC-compliant by trying to handle quotes and escaping, without discarding everything in the case of bad data. Perhaps your deviation rule could be “no commas allowed in quotes or escaped; they always signal a new entry”. Or just don’t use a leftmost value.<br>(Note that differences in parsing at different points – reverse proxies, server, etc. – could result in parser mismatch vulnerabilities.)<br>At the reverse proxy level, the obvious mitigation is to discard any existing Forwarded headers and start fresh, so there are only trusted, well-formed values. If you don’t like the idea of discarding potentially valuable forensic information, maybe your reverse proxy could...