Le vulnerabilità degli URL possono essere evitate se viene utilizzato il metodo post?

No, usare POST non è affatto una difesa contro l'XSS.

Certo, un utente malintenzionato non può semplicemente inviarti un link che contiene il payload, ma può inviarti un link a una pagina web che contiene HTML / JavaScript che invia il payload.

Esempio:

<form method="post" action="http://yourserver.com/yourscript.php" id="myform">
    <input type="hidden" name="[XSS payload]"/>
    <input type="hidden" value="Send">
</form>
<script>
document.getElementById('myform').submit();
</script>

L'autore dell'attacco potrebbe anche inviare il modulo in un iframe nascosto o altrimenti nascondere l'attacco in modo che una vittima non se ne accorga.

Se invece hai una protezione CSRF per le tue richieste POST - cosa che dovresti avere - sfruttare gli attacchi XSS riflessi tramite POST diventerà più difficile o impossibile.

Esistono pochissime classi di vulnerabilità che risultano meno vantaggiose per gli attacchi se eseguite tramite POST, ad esempio Open Redirect (il phishing non è più possibile, ma la protezione CSRF che si basa su un controllo referer può ancora essere sfruttata in alcuni situazioni).

L'uso di POST offre i seguenti vantaggi rispetto a GET:

Evita la cronologia URL del browser . Qualsiasi dato sensibile nel modulo non viene passato nell'URL, il che significa che i dati nel modulo non sono visibili nella cronologia del browser e non possono essere salvati una volta inviati. (Nota: il corpo del modulo a volte viene memorizzato, a seconda del browser e delle impostazioni, ma di solito non è visibile).

Possibilità di passare token nascosti . L'uso di POST offre alla tua applicazione la flessibilità di includere più campi (c'è un limite rigido alla lunghezza di una richiesta GET), inclusi elementi importanti come token CSRF, checksum ViewState MAC, ecc. Non vorresti mostrare questi campi nel barra degli indirizzi.

Meno registrazioni . I dati nell'URL stesso sono conservati in un'intestazione HTTP, che è più probabile che venga registrata dalle appliance di rete intermedie (ad esempio se si utilizza la ripartizione del carico di lavoro SSL o l'ispezione deep packet) o dai registri del server web. IIS, ad esempio, registra l'intero URL e querystring con ogni singola richiesta, per impostazione predefinita, e questo viene archiviato in un file flat che rimane sul server Web per sempre. I dati nel corpo del modulo, d'altra parte, non sono registrati per impostazione predefinita.

Evita l'invio di informazioni personali alle analitiche . Se nell'URL ci sono informazioni riservate, si rischia che i dati finiscano per essere inviati a soluzioni di analisi o a terze parti che si stanno utilizzando. In generale, i dati nel corpo del modulo non finiranno per essere inviati a meno che tu non facciano il codice per farlo.

L'uso di POST riduce automaticamente il rischio di CSRF? NO !! Ma in genere una mitigazione CSRF comporterà l'utilizzo di HTTP POST + un token anti-CSRF, quindi potrei capire perché penseresti che vadano insieme. Senza il token, il verbo POST non fa nulla di per sé per mitigare CSRF tramite XSS riflesso o memorizzato.

No, l'igienizzazione dell'input è il controllo più efficace per mitigare l'XSS in questo caso: link