Using enctype="multipart/form-data" creates both a binary and an ascii upload
I consider this statement wrong. There is application/x-www-form-urlencoded
where the body of the POST request consists of the same string as would be used after ?
in the URL if a GET request was used, i.e. like this:
POST /foo HTTP/1.1
Content-type: application/x-www-form-urlencoded
Content-length: ...
...
foo=one&bar=two
And then there is multipart/form-data
which is a multipart MIME-message where each part consists of the key name given in the header and the body containing the value:
POST /foo HTTP/1.1
Content-type: multipart/form-data; boundary=abcde
Content-length: ...
...
--abcde
Content-Disposition: form-data; name=foo
one
--abcde
Content-Disposition: form-data; name=bar
two
--abcde--
Each part is only sent once and binary data (like file uploads) are sent only as binary.
Apart from sending unnecessary data to the server, how this may be exploited?
Both ways can be used with several variations in order to try to bypass web application firewalls (WAF). With application/x-www-form-urlencoded
one could for example try to play with URL encoding on unexpected places (like encoding the keys, =
or &
) in the hope that WAF and and server will interpret data differently. Or can could use duplicate keys etc.
With multipart/form-data
one could try some of these variations too. But MIME gives even more possibilities, especially if a library gets used for parsing which gets also used for MIME in mails. In this case one could try to play around with innovative boundaries, duplicate boundaries (where server and WAF might pick a different one), try to use Content-Transfer-Encoding
etc. But, a better WAF will simply discard any of these attempts since browsers will not issue such requests.