Protocol Realism: HTTP POST Content-Type

As any semi-competent web application developer could tell you, when you fill out a form and submit it via HTTP, there are a few options your browser has in formatting the response. However, since I am not a semi-competent web application developer, I had to go look this up because we have a BreakingPoint Elite user who recently asked for exactly this functionality in our HTTP Application Simulator.

So, as of the latest Application Protocol and Strike Pack, the HTTP Application Simulator now asks for an optional "Content-boundary" value, to go along with the usual "Content-Type" header, like so:

To illustrate, if we had a test that specified the options as shown above, along with a text file with the specified boundary token of "BPS123" to demarcate each of the HTTP form's values, the result would look something like this:

POST /submit.html HTTP/1.1
Host: default
Connection: Keep-Alive
User-Agent: BreakingPoint/1.x (http://bpointsys.com/)
Accept: */*
Content-Type: multipart/form-data; boundary=BPS123
Content-Length: 395

--BPS123
Content-Disposition: form-data; name="value_one"

This is my first value. I just want to say
--BPS123
Content-Disposition: form-data; name="value_two"

Yo value_one, I'm really happy for you and I'mma let you finish,
but application/x-www-form-urlencoded is the one of the best form
encoding types of all time.

One of the best form encoding types of all time!
--BPS123--

If we had, instead, set the Content-Type to the more typical POST encoding of "application/x-www-form-urlencoded," we could specify another appropriately formatted text file and generate a result that HTTP-aware content inspection devices would understand:

POST /submit.html HTTP/1.1
Host: default
Connection: Keep-Alive
User-Agent: BreakingPoint/1.x (http://bpointsys.com/)
Accept: */*
Content-Type: application/x-www-form-urlencoded
Content-Length: 188

value_one=First+value&value_two=%09This+is+the+first+line%0d%
0aSecond+line,+and+honestly,+this+kanye+thing+isn%27t+all+that+funny+anymore.
%0d%0aNo,+really,+let%27s+just+end+this+now.

Of course, there's also the plain text encoding, which virtually nobody uses. But, just because it's unpopular doesn't mean that your inspection device shouldn't be tested on it. To do so, it's as simple as setting "text/plain" as the Content-Type, and providing the text to look for:

POST /submit.html HTTP/1.1
Host: default
Connection: Keep-Alive
User-Agent: BreakingPoint/1.x (http://bpointsys.com/)
Accept: */*
Content-Type: text/plain
Content-Length: 298

value_one=This is the first value.
value_two=Yo value_one, I'm really hap--
value_three=Yo value_two, I'm really happy for you, and I'mma let you 
finish, but the fake form value interruption in example one was the best 
"I'mma let you finish" joke of this entire blog post.

This entire blog post!

It's a little thing, of course -- just a few UI settings to make sure that the form data you're blasting out at dangerous speeds is formatted according to your fancy. But it's the little things like this that make the case for realistic testing. If a vendor claims a device inspects outgoing HTTP data, then, by gum, it ought to be handling all the vagaries of form encoding. And if the vendor claims it does that, then by double-gum, now you can test it to be sure.