No matter how application-savvy you are, it should be fairly obvious that this is not a typical Content-Type header for an HTTP request. According to the RFC, Content-Type is usually of the form “type/subtype”7. This leviathan contains a valid Content-Type header in the very first line—multipart/form-data—but even a rudimentary BNF parser would flag this as a giant fail. But the thing is that HTTP headers, like form data and query parameters, are user input.

Let me repeat that: HTTP headers are user input.

That means I can put anything I want in the header and pass it to an application. And that means if you aren’t sanitizing those HTTP headers, you run the risk of exploitation. More often than not, it just breaks your application—undesirable, but not inherently dangerous. But on occasion, like this one, it’s a rather serious situation that could result in Very Bad Things™ happening.

Nick Biasini, who has a great blog on this vulnerability8, has some uber-scary screen grabs of what’s possible. None of which are desirable. None.

I cannot say it often enough: web application security is a stack. That stack includes protocols, of which HTTP is often the most prevalent. A comprehensive web application security strategy cannot ignore HTTP. It must view headers with the same skepticism with which user-generated input is processed, which is to say with a high degree of suspicion.

Remember, security’s Rule Zero is “Thou shalt not trust user input. Ever.” That must include HTTP headers, because at the end of the day, they are (or can be) user-generated. Postman, a popular tool for developers and DevOps for interacting with RESTful APIs, lets me do whatever I want to an HTTP request. Including bulk editing of headers, which means I can pretty much put what I want in there and see what happens.