El uso de enctype="multipart / form-data" crea una carga binaria y ascii
Considero que esta afirmación es incorrecta. Hay application/x-www-form-urlencoded donde el cuerpo de la solicitud POST consiste en la misma cadena que se usaría después de ? en la URL si se usara una solicitud GET, es decir, de esta forma:
POST /foo HTTP/1.1
Content-type: application/x-www-form-urlencoded
Content-length: ...
...
foo=one&bar=two
Y luego está multipart/form-data , que es un mensaje MIME de varias partes donde cada parte consiste en el nombre de la clave que se encuentra en el encabezado y el cuerpo que contiene el valor:
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--
Cada parte solo se envía una vez y los datos binarios (como las cargas de archivos) se envían solo como binarios.
Además de enviar datos innecesarios al servidor, ¿cómo puede ser explotado?
Se pueden usar ambas formas con varias variaciones para intentar evitar los firewalls de aplicaciones web (WAF). Con application/x-www-form-urlencoded , por ejemplo, podría intentar jugar con codificación de URL en lugares inesperados (como la codificación de las claves, = o & ) con la esperanza de que WAF y el servidor interpreten los datos de manera diferente. O podría usar claves duplicadas, etc.
Con multipart/form-data uno podría probar algunas de estas variaciones también. Pero MIME ofrece aún más posibilidades, especialmente si una biblioteca se usa para el análisis, que también se usa para MIME en los correos. En este caso, se podría intentar jugar con límites innovadores, límites duplicados (donde el servidor y WAF podrían elegir uno diferente), tratar de usar Content-Transfer-Encoding etc. Sin embargo, un WAF mejor simplemente descartará cualquiera de estos intentos ya que los navegadores No emitir tales solicitudes.