Il primo step che si compie nell’analisi di un’applicazione web è il cosidetto mappaggio della stessa, andando ad enumerare gli utenti, le pagine passibili di vulnerabilità e quali sono le possibili strade che si possono compiere per riuscire ad aggirare eventuali blocchi. Nello scorso articolo abbiamo introdotto le funzionalità e alcuni dei problemi principali che affliggono le applicazioni web, in questo ci occuperemo di mappare un’applicazione e capire quali tools potrebbero esser utili.
L’approccio basilare per questo passaggio è navigare manualmente nel sito, prendendo nota delle possibili pagine da analizzare in seguito, o quali sono da scartare. Se il sito possiede una mappa (si trova sotto il nome di sitemap.xml solitamente), anch’essa può essere utili ai fini dell’operazione.
Nel caso non si voglia effettuare manualmente, esistono diversi software, come Burp Suite, ZAP proxy o WebScarab.
Le funzionalità di interesse potrebbero essere:
Durante questa fase è utile controllare anche il codice sorgente delle pagine, alla ricerca di commentio informazioni sulla versione di plugin o software che girano sull’applicazione.
Un altro metodo può essere quello di eseguire un attacco di forza bruta alla ricerca di pagine nascoste o amministrative, ovviamente non linkate e non visibili ai comuni visitatori. Un software utile potrebbe essere Wfuzz, utilizzato appunto per questo scopo.
Questa operazione consiste nel contattare il server al fine di ottenere informazioni come:
Si può eseguire sia con netcat che con telnet. Il comando da utilizzare è semplicissimo
nc indirizzo_ip porta
richiesta_http
Ad esempio, se volessi testare la home di un sito, sarebbe
┌─[mrtouch@parrot]─[~]
└──╼ $ telnet 192.168.1.105 80 #comando inviato
Trying 192.168.1.105...
Connected to 192.168.1.105.
Escape character is '^]'.
GET / HTTP/1.1 #richiesta GET della home page
Host: 192.168.1.105 #all'host dichiarato
HTTP/1.1 200 OK
Date: Fri, 03 Mar 2017 16:21:24 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze15
X-XSS-Protection: 0
Vary: Accept-Encoding
Content-Length: 6033
Content-Type: text/html
....altre informazioni...
Una volta definita la struttura dell’applicazione, bisogna identificare i vari attacchi che possono essere eseguiti contro di essa. Alcuni di essi possono essere:
Per verificare se è affetto da questa vulnerabilità, si possono iniettare nel form diversi caratteri, tra cui , in modo da controllare come reagisce l’applicazione con l’inserimenti di caratteri speciali. Se inserisco
''--!$<XSS>{}()
e la pagina non converte la stringa con caratteri speciali, significa che la pagina è vulnerabile e possiamo inserire l’attacco che preferiamo.
Come si può vedere nell’immagine e nel codice sorgente, l’applicazione non ha sanitizzato l’input, e ora si ritrova con un nuovo tag nel codice sorgente, appunto.
Nel prossimo caso, la stringa era bloccata. Dopo qualche tentativo ho notato che non bloccava invece iframe, ed ecco che sono riuscito ad iniettarlo.
L’esempio eseguito è stato preso da PentesterLab, che utilizzerò nella parte 3 per introdurre tutti i principali tipi di attacchi ad un applicazione web. Una delle migliori guide per testare applicazioni web, insieme alle linee guida per ogni vulnerabilità, è possibile trovarla su OWASP.