0

If the form doesn't have any file upload, you just use enctype="multipart/form-data" everywhere, is it a bad idea from a security point of view?

Here someone says, in 2007

Uusing enctype="multipart/form-data" creates both a binary and an ascii upload, so there's a doubling of the traffic. I'm not aware of any other issues. However, it seems to me that allowing binary uploads may create some security concerns.

Apart from sending unnecessary data to the server, how this may be exploited?

5

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.

  • though the OP's citation wasn't clear, it might be referring to the fact that the 2nd example is twice a big as the first for most forms, whose params are typically short input like numbers, dates, and names, and that binary data is sandwiched with ascii delimiters. More than double for short values... – dandavis Jan 31 '18 at 22:41
  • 2
    @dandavis: the citation was very clear for me in that it stated that the same content is delivered as ASCII and binary - which is wrong. But, it is true that multipart/form-data has more overhead for each key, which can be significant if the value for the key is short. – Steffen Ullrich Feb 1 '18 at 5:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.