Using enctype="multipart/form-data" creates both a binary and an ascii upload
Considero questa affermazione errata. Esiste application/x-www-form-urlencoded in cui il corpo della richiesta POST è costituito dalla stessa stringa che verrebbe utilizzata dopo ? nell'URL se è stata utilizzata una richiesta GET, ad esempio:
POST /foo HTTP/1.1
Content-type: application/x-www-form-urlencoded
Content-length: ...
...
foo=one&bar=two
E poi c'è multipart/form-data che è un messaggio MIME multipart dove ogni parte è costituita dal nome della chiave dato nell'intestazione e dal corpo contenente il valore:
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--
Ogni parte viene inviata una sola volta e i dati binari (come i caricamenti di file) vengono inviati solo come binari.
Apart from sending unnecessary data to the server, how this may be exploited?
Entrambi i modi possono essere utilizzati con diverse varianti per cercare di aggirare i firewall delle applicazioni Web (WAF). Con application/x-www-form-urlencoded si potrebbe ad esempio provare a giocare con la codifica dell'URL in posti inattesi (come la codifica delle chiavi, = o & ) nella speranza che WAF e il server interpreteranno i dati in modo diverso. Oppure puoi usare chiavi duplicate ecc.
Con multipart/form-data si potrebbero provare anche alcune di queste variazioni. Ma MIME offre ancora più possibilità, specialmente se una libreria viene utilizzata per l'analisi che viene utilizzata anche per MIME nelle e-mail. In questo caso si potrebbe provare a giocare con limiti innovativi, confini duplicati (dove server e WAF potrebbero sceglierne uno diverso), provare a usare Content-Transfer-Encoding ecc. Ma un WAF migliore semplicemente scarterà uno di questi tentativi poiché i browser non emettere tali richieste.