Questo sito ASP è vulnerabile all'XSS o no?

2

Ho fatto una scansione di un sito ASP e ho detto che la convalida della richiesta era disattivata. Lo ha rilevato inviando un URL di example.com/?foo=<script> e ha ricevuto un URL di risposta di example.com/?foo=<script> (Stesso).

Ho dato un'occhiata a me stesso, e ho cercato di vedere cosa succedeva. Ho dato un'occhiata più da vicino al codice sorgente e ho visto questo sotto i tag del titolo:

<form name="frm" method="post" action="/default.aspx" id="frm" enctype="multipart/form-data">

Quando provo l'URL suggerito dallo scanner, il codice sorgente cambia in:

<form name="Form" method="post" action="/default.aspx?bar=%3Cscript%3E" id="Form" enctype="multipart/form-data">

che è chiaramente codificato.

Questo significa che la webapp è protetta da XSS e lo scanner ha trovato un falso positivo?

    
posta Suhass 14.09.2015 - 04:22
fonte

2 risposte

1

La codifica che sta accadendo è codifica URL (" < " è codificata su " %3C " e così via). Questo viene fatto dal browser quando digiti caratteri speciali nell'URL.

Questo può essere verificato intercettando la richiesta che va dal browser al server usando un proxy come Burp Suite.

Ora, se aggiungi il tuo script in Burp invece del browser, lo script rifletterà sicuramente nella risposta senza codifica. Lo stesso può essere ottenuto creando manualmente una pagina HTML per attivare la richiesta.

La vera mitigazione che stai osservando è la corretta codifica HTML ( &lt; e &gt; per " < " e " > "). Per rendere la tua applicazione completamente blindata e protetta contro XSS, ti consiglio di utilizzare il filtro ValidateRequest di ASP.NET insieme a un filtro a livello di applicazione personalizzato che codifica caratteri speciali in tutte le richieste.

L'applicazione non dovrebbe accettare alcuno script, carattere speciale o HTML nei campi quando non richiesto. Dovrebbe sfuggire a caratteri speciali che potrebbero rivelarsi dannosi. I caratteri possono essere sfuggiti secondo l'elenco disponibile a questo link:

risposta data 14.09.2015 - 10:06
fonte
0

Sarà vulnerabile non appena echeggi la variabile foo senza alcun tipo di filtro.

Visualizza informazioni su come stampare in modo dinamico contenuti HTML sicuri: link

    
risposta data 14.09.2015 - 11:10
fonte

Leggi altre domande sui tag