WAPT: l’approccio blackbox

WAPT: l'approccio blackbox

L'analisi di vulnerabilità di un'applicazione web in pratica:
l'analisi dell'applicazione e la ricerca delle vulnerabilità

In un articolo precedente abbiamo introdotto i principi dell'analisi
delle vulnerabilità in un'applicazione Web. In questo approfondiamo la
condotta di un penetration test di tipo Blackbox.

Durante un penetration test blackbox si riscontrano spesso problemi
concreti tipici che possono alterare la validità o impedire la corretta
esecuzione del WAPT. Ad esempio, esistono casi in cui l'ambiente di
collaudo non è una copia speculare dell'ambiente di produzione e
ambienti di collaudo dove i link delle applicazioni puntano verso l'ambiente
di produzione; a seconda delle modalità di accesso alla rete, è possibile
che i firewall ed i proxy non siano abilitati a raggiungere la zona
intranet. Altri problemi ti tipo organizzativo potrebbero portare a casi di
concorrenza nel lavoro fra i gruppi che si occupano di sviluppo e quelli che
si occupano di sicurezza.

Queste situazioni potrebbero dilatare i tempi o bloccare le attività,
rendendo necessario rivolgersi immediatamente al gruppo di sviluppo o
all'area network una volta individuato uno di questi problemi.

La fase di ricerca degli eventi rilevanti ai fini della sicurezza è
costituita da:

1. L'analisi dell'applicazione e comprensione della logica applicativa
2. La ricerca delle vulnerabilità

Analisi dell'applicazione

L'analisi dell'applicazione e la comprensione della logica applicativa
pur rappresentando la fase più importante dell'intero test, spesso è quella
meno considerata. Una comprensione corretta delle logiche applicative
permette di individuare le tecnologie e la loro implementazione all'interno
dell'applicazione, guadagnando tempo nella successiva fase di ricerca delle
vulnerabilità. Per comprendere la "business logic" è necessario studiare
l'applicazione nella sua interezza, individuando l'alberatura delle
directory eseguendo il crawling dei links e analizzando il codice sorgente,
distinguendo il codice (X)HTML dagli oggetti inclusi al suo interno (applets
Java, Flash scripts, codice Javascript, etc).

Il crawling del codice sorgente è un'operazione
tecnicamente ostica. I problemi nell'affrontare il crawling di una web
application possono essere schematizzati in alcune tipologie:

• Zone del sito navigabili unicamente in HTTPS
• Aree accessibili tramite credenziali
• Codice (X)HTML che non rispetta gli standard del consorzio W3C
• Redirect e azioni eseguite tramite codice Javascript
• Link che puntano verso l'ambiente di produzione
• Link non accessibili tramite il proxy/firewall adottato per la
  connessione per policy dell'area network
• Application server e framework di sviluppo che falsificano le
  risposte relative allo stato HTTP delle richieste al server (ad esempio
  le richieste su pagine inesistenti 404, o al quale non è permesso
  accedere 403 – la cui richiesta viene intercettata e trasformata in una
  pagina di errore il cui stato HTTP è 200)

L'integrazione della fase di crawling è costituita dall'uso di un proxy
applicativo interposto fra il browser e la rete che permetterà di filtrare
tutti i valori (quali headers http, campi hidden, id di sessione, variabili
GET/POST, valori del cookie, etc) scambiati nelle comunicazioni fra il
browser e il web server. Dall'analisi del codice sorgente sarà possibile
distinguere il codice (X)HTML, gli oggetti esterni inclusi (applets Java,
Flash scripts, codice Javascript), le forms hidden, gli oggetti DOM,
determinando quali tecnologie sono state implementate all'interno
dell'applicazione in test.

Tramite l'identificazione degli entry points (le forms,
i cookies, le variabili inviate in GET) si riuscirà a comprendere
l'architettura dell'applicazione, individuando i meccanismi di
autenticazione e l'individuazione di eventuali application server o
framework sottostanti.

Se l'identificazione o la corretta metodologia d'implementazione delle
tecnologie all'interno dell'applicazione analizzata dovessero risultare non
chiare o incomplete, il test dovrà considerarsi incompleto, quindi inutile.
La parzialità nella risoluzione delle vulnerabilità non porta a risultati
incoraggianti ai fini della sicurezza, rendendo necessaria un'operazione
metodica e sistematica nelle fasi di enumerazione delle tecnologie. Il
penetration tester non deve avere in questa fase particolari restrizioni di
tempo, rappresentando di fatto l'operazione più delicata il cui dispendio di
tempo non è determinabile a priori se non per grandi linee.

Ricerca delle vulnerabilità

La ricerca delle vulnerabilità è un'operazione metodica non strettamente
determinabile a priori in ambito blackbox. Il mondo open source e numerose
aziende offrono una serie di strumenti per coloro che intendono verificare
la sicurezza di un'applicazione web, ma questi tool, pur essendo di aiuto
per la verifica di applicazioni complesse e ricche di funzionalità, non
possono fornire un supporto adeguato ad un test professionale.

Da un punto di vista architetturale, la sicurezza di una web application
analizzata tramite metodologia blackbox non è verificabile
semplicemente al seguito dei test statici eseguiti da software che
analizza le risposte del webserver mediante l'inserimento di pattern
d'attacco sugli entry point, ma è strettamente legata alla
comprensione della logica applicativa effettuata ad arte del tester, che si
rende capace di sovvertire la funzionalità dell'applicazione, fornendo input
elaborati in base alla particolare implementazione di una determinata
tecnologia.

Ad esempio, il lettore immagini un campo GET di una web application che
usa un framework dot.NET e che riceve dati codificati in base64 vulnerabile
ad attacchi che permettono l'inclusione locale di files (local server side
inclusion). Il tool non eseguendo alcun tipo di analisi andrà inserendo
pattern d'attacco non codificati in base64 che provocheranno messaggi di
errore (lunghezza dell'input errata, caratteri non permessi, e così via) su
pagine il cui HTTP status risulta essere 200 (richiesta elaborata
correttamente), il cui contenuto è stato modificato ma solo per la stampa a
video del messaggio di errore e non per l'effettiva inclusione di un file
presente sul file system del target. Un simile scenario presenterebbe una
consistente serie di falsi positivi nei report.

Questa tipologia di software presenta delle problematiche nell'analisi
applicativa non facilmente superabile:

• non possiedono intelligenza propria quindi non sono capaci di
  comprendere la logica applicativa
• spesso trovano difficoltà a seguire pagine contenenti frame lato
  client (redirection in codice Javascript)
• molti non sono in grado di verificare applicazioni che fanno uso di
  certificati SSL
• non è possibile usarli in ambiente di produzione per verifiche in
  momenti critici a causa dei falsi positivi che si verrebbero a creare
  nei file di log dei web server.

Firefox, con le sue numerose estensioni di sviluppo, si rivela eccellente
per un test professionale.
Web
developer,

Hackbar,

SQL Inject Me,

XSS Me, ed altri plugin permettono una panoramica delle vulnerabilità
dell'applicazione lasciando però la comprensione applicativa all'operatore,
che analizzando l'output dell'applicazione dopo aver fornito del codice nocivo negli entry points della pagina, cercherà di dimostrare le vulnerabilità in analisi sovvertendo il funzionamento dell'applicazione in modo non previsto dagli sviluppatori.

Note sull’autore: Saverio Rizza lavora nel settore IT di un noto service provider occupandosi dell’analisi statica del codice di applicazioni enterprise. È docente di linguaggi web oriented. Ha svolto attività spaziando dai vulnerability assessment and mitigation alla scrittura di pattern di sviluppo sicuro.