Nozioni basilari di (in)sicurezza delle applicazioni Web – Parte 2 - Footprinting

Tempo di lettura: 6 minuti
Data pubblicazione: March 4, 2017

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.

Enumerazione del contenuto

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.

Burp Suite
Burp Suite

Le funzionalità di interesse potrebbero essere:

  • Form di autenticazione, come login o registrazione;
  • Funzioni di recupero password;
  • Pagine di upload o download di file;
  • Sezioni protette, per gli amministratori o utenti privilegiati;

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.

Wfuzz all'opera
Wfuzz all'opera

Questa operazione consiste nel contattare il server al fine di ottenere informazioni come:

  1. Nome e versione del server;
  2. Linguaggio di programmazione utilizzato;
  3. Tipo di contenuti;

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...
Esempio di banner grabbing
Esempio di banner grabbing

Possibili attacchi

Una volta definita la struttura dell’applicazione, bisogna identificare i vari attacchi che possono essere eseguiti contro di essa. Alcuni di essi possono essere:

  • Interazione con il database: SQL Injection;
  • Upload o Download: Path trasversal o XSS;
  • Login: enumerazione degli utenti e possibile brute force;
  • Messaggi di errore: informazioni sulla tipologia di applicazione;
  • Componenti esterni: possibili vulnerabiltà pubbliche (come i plugin in Wordpress);

Esempio di attacco

Cross Site Scripting

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.

Esempio di XSS
Esempio di XSS

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.

Altro esempio di XSS
Altro esempio di XSS

Conclusioni

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.