Eccoci alla risoluzione della prima vulnerabilità che ho affrontato DVWA XSS Reflected, i requisiti per affrontare questo test sono:
- Browser senza filtri XSS, consiglio Mozilla **Firefox
**
L’obbiettivo di questo test è iniettare del codice javascript all’interno di una pagina web che stampa a video caratteri passati tramite un form.
La richiesta avviene tramite metodo GET e la variabile target si chiama “name“.
Analizzando il sorgente html si può notare come il valore da me inviato (homelab) venga stampato a video tra i tag
DVWA XSS Reflected – Low Level
Nel livello più basso mi aspettavo di trovare un minimo di filtro o accortezza invece non esiste alcun tipo di controllo.
Per cominciare ho inserito il classico payload “alert(1)” ed infatti ha funzionato subito:
Analizzando il codice sorgente si può notare come non ci sia alcun controllo in input sulla variabile $_GET[‘__name’]:
DVWA XSS Reflected – Medium Level
Anche in questo caso ho provato ad inserire il payload”alert(1)” per vedere il comportamento di un eventuale filtro:
Si può notare la rimozione automatica del tag , come una sorta di blacklist.
Spesso capita di imbattersi in filtri non propriamente efficienti, come ad esempio la mancanza di controlli case-sensitive.
Iniettando i tag “” alternando lettere minuscole a quelle maiuscole il filtro verrà bypassato:
Nel codice sorgente si può vedere come viene utilizzata, in maniera inadatta, la funzione php str_replace per eliminare la presenza della parola dalla variabile $_GET[‘name’] :
DVWA XSS Reflected – High Level
Come da prassi inserisco il precedente payload per vedere l’effetto del nuovo filtro XSS:
Il risultato è interessante, sembra che venga eliminata la parola case-sensitive script e tutto ciò che la precede, quindi sarà necessario evitare tag o attributi con la parola javascript.
Premetto che prima di scegliere un payload mi sono accertato che i caratteri < e > venissero accettati.
Tags html in cui è possibile inserire attributi javascript sono moltissimi, come ad esempio , nello specifico “”
Il codice sorgente mostra la regexp passata alla funzione php preg_replace che rimuove qualsiasi carattere case-sensitive di una stringa che comincia col simbolo minore “<” e che precede le lettere s,c,r,i,p,t.
Naturalmente anche questo tipo di protezione è errata!
DVWA XSS Reflected – Impossible Level (Mitigazione)
Questo livello non può essere exploitato ma consultando il sorgente è possibile capire una delle tecniche da attuare per evitare di scrivere codice vulnerabile.
Lo scopo di questo test era quello di rompere o comunque modificare i tag html ed inserirci del codice javascript.
Per evitare tutto ciò, in questo livello l’input è stato filtrato dalla funzione php htmlspecialchars che semplicemente converte i caratteri speciali (tra cui < e > ) in entità html.
Un’alternativa poteva essere anche la seguente:
$bad_chars = array("<", ">");
$safe_chars = array("<", ">");
$name = str_replace($bad_chars, $safe_chars, $_GET[ 'name' ]);
return stripslashes($name);
Nel precedente filtro tramite str_replace non faccio altro che emulare la funzione htmlspecialchars, ovvero trasformo i caratteri speciali < e > nelle corrispettive entità html < e > .
Naturalmente queste tecniche non possono essere utilizzate in tutti i casi, ad esempio se dovessimo filtrare l’attributo di un tag o sarebbe inutile filtrare solo i caratteri speciali.
Oltre al filtro XSS è presente anche una funzione checkToken() utilizzata per evitare attacchi CSRF.