1. 11
  1.  

  2. 5

    Let’s imagine that the front-end prioritises the first content-length header, and the back-end prioritises the second.

    This is my absolute favorite kind of vulnerability. It shows up all the freaking time, and can be really fun to exploit, although difficulty can run from “trivial” to “brutal”—in a way, it’s similar to polyglot programming where you have to have the same source file be valid code for two different compilers.

    1. 1

      I should mention that this falls under the umbrella of LANGSEC, if you’re interested in these things. http://langsec.org/occupy/

    2. 2

      It sounds like the most foolproof way to (hopefully categorically) fix this is that whichever box terminates TLS should (being the first piece of kit that sees the raw HTTP request the client sent) canonicalize the HTTP request before passing it on, by serialising a parsed representation of the request rather than by shovelling bytes from req into bereq. So e.g. duplicate content length headers should get squeezed out.

      Thinking about it, maybe the safest solution to the content length vs transfer encoding chunked would be to strip off the content length entirely and convert every incoming request body to chunked encoding? That way, backend code which can’t parse TE chunked will not pass integration tests and get fixed long before production.