DVWA XSS Reflected – Soluzione Completa

Eccoci alla risoluzione della prima vulnerabilità che ho affrontato DVWA XSS Reflected, i requisiti per affrontare questo test sono:

  1. 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.
DVWA XSS Reflected

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 <pre></pre>

DVWA XSS Reflected

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 “<script>alert(1)</script>” ed infatti ha funzionato subito:

DVWA XSS Reflected

Analizzando il codice sorgente si può notare come non ci sia alcun controllo in input sulla variabile $_GET[‘name’]:

DVWA XSS Reflected

DVWA XSS Reflected – Medium Level

Anche in questo caso ho provato ad inserire il payload”<script>alert(1)</script>” per vedere il comportamento di un eventuale filtro:

DVWA XSS Reflected

Si può notare la rimozione automatica del tag <script>, 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 “<sCrIpT></sCrIpT>” alternando lettere minuscole a quelle maiuscole il filtro verrà bypassato:
DVWA XSS Reflected

 

Nel codice sorgente si può vedere come viene utilizzata, in maniera inadatta, la funzione php str_replace per eliminare la presenza della parola <script> dalla variabile $_GET[‘name’] :

DVWA XSS Reflected

DVWA XSS Reflected – High Level

Come da prassi inserisco il precedente payload per vedere l’effetto del nuovo filtro XSS:

DVWA XSS Reflected

Il risultato è interessante, sembra che venga eliminata la parola case-sensitive script e tutto ciò che la precede, quindi sarà necessario evitare tag <script> 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 <img> , nello specifico “<img src=x onerror=alert(1)>

DVWA XSS Reflected

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

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.
DVWA XSS Reflected
Lo scopo di questo test era quello di rompere o comunque modificare i tag html <pre></pre> 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("&lt;", "&gt;");

        $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 &lt; e &gt; .
Naturalmente queste tecniche non possono essere utilizzate in tutti i casi, ad esempio se dovessimo filtrare l’attributo di un tag <img> o <a> sarebbe inutile filtrare solo i caratteri speciali.
Oltre al filtro XSS è presente anche una funzione checkToken() utilizzata per evitare attacchi CSRF.