EN flag
Listino Supporto Partner Contatti 800 13.40.41

KNOWLEDGE BASE

Knowledge Base

Vai al Video

Web App Penetration Test con Burp

In un mondo sempre più tecnologico, la sicurezza informatica assume un ruolo fondamentale, così come l’esperto capace di rendere le applicazioni sicure. L’ethical hacker, spesso chiamato white hat hacker, ha il compito di emulare il comportamento di un hacker al fine di trovare

vulnerabilità presenti nelle applicazioni e proporre un piano di difesa finalizzato a rimuoverle. L’ethical hacker deve avere una conoscenza ampia sul mondo della cyber security ed avere almeno una conoscenza base dei linguaggi di programmazione maggiormente utilizza. In effetti l’ethical hacker è un vero e proprio hacker prestato al mondo del bene, con la missione di scovare vulnerabilità per evitare danni futuri all’applicazione in esame.

Una delle metodiche per rilevare la resistenza delle infrastrutture IT, delle reti informatiche, nonché delle macchine che ne fannno parte e dei rispettivi sistemi operativi e applicazioni, è il cosiddetto Penatration Test (Pen Test), che sostanzialmente fornisce indicazioni sulla capacità che un hacker può avere di entrare nel sistema, accedere ai dati o prenderne il controllo, dall’esterno tramite, appunto, una connessione di rete cablata o wireless. Una tecnologia di Cyber Security analoga permette di estendere l’ambito del Penetration Test alle web application (o applicazioni web, che dir si voglia) che oggi sono molto diffuse in virtù della massiccia presenza di siti e servizi web.

In questo tutorial spiegheremo che cos’è il Penetration Test applicato alle Web App e andremo ad eseguirne uno dimostrativo utilizzando un tool specifico chiamato Burp. Dopo l’esempio pratico proporremo alcune soluzioni per rimediare alle vulnerabilità trovate e mostreremo il report correttamente compilato da rilasciare all’ipotetico cliente che ha richiesto l’analisi.

Introduzione al WAPT e configurazione di Burp

Quello che andremo ad affrontare in questo tutorial è dunque il Web Application Penetration Test (WAPT) che si riferisce a tutte le attività che mirano a testare la sicurezza di applicazioni web; resta inteso che il WAPT deve essere autorizzato dal proprietario (l’owner) del servizio che deciderà anche quali sono i limiti del test, intendendo per limiti anche la possibilità di effettuare una procedura più o meno approfondita in modo da non creare danni al servizio.

Quindi si segue una procedura standard che prevede l’accordo tra il proprietario del servizio e il soggetto (chiamato in gergo pentester) che andrà ad effettuare il Penetration Test dove c’è la definizione delle regole generali da rispettare.

Il test può essere effettuato in produzione o in collaudo; quest’ultima modalità è preferibile perché si può andare più a fondo nell'analisi, mentre in produzione bisogna stare attenti altrimenti si rischia di far collassare un servizio. Una cosa fondamentale da produrre al termine del test è la comunicazione delle vulnerabilità che vengono evidenziate e delle possibili e correlate soluzioni, dette anche remediation.

Per eseguire un test, un pentester può seguire diverse tipologie di guide e soluzioni, tra cui quella OWASP. Solitamente ci sono dei passi base da seguire:

  • pianificazione dell’attacco;
  • reconnaissance;
  • enumerazione;
  • analisi delle vulnerabilità;
  • exploitation;
  • report.

Per questo tutorial ci focalizzeremo su Burp, che è uno strumento molto utilizzato per il penetration test, disponibile sia nella versione community sia nella versione a pagamento (costa circa 300 euro all’anno). La versione community consente di sfruttare quasi tutte le potenzialità dello strumento con qualche limitazione in termini di velocità.

Burp intercetta tutte le richieste che vengono inviate verso il web (l’immagine seguente propone la finestra di lavoro) il che premette di studiare il pacchetto alla ricerca di eventuali vulnerabilità.

Il pacchetto contiene tutti i dati che verranno inviati al server. Il pentester si preoccuperà di

verificare che, alterando i dati presenti nel pacchetto, il Server risponda in modo adeguato.

Vediamo ora le modalità di analisi supportate da Burp, che sono varie: c’è la modalità proposta nell’immagine seguente, che quindi prevede di intercettare semplicemente un pacchetto.

 

Quello che vediamo nella tab Raw è un pacchetto e tutti gli elementi che notiamo al suo interno sono tutti gli elementi che un client invierà poi al server; quindi come possiamo vedere in questo caso, notando in basso username e password, si tratta di un form di Login.

La seconda modalità che vediamo è quella basata sull’Intruder (tab omonima nell’immagine seguente) che permette di selezionare gli elementi di interesse ed effettuare un attacco automatizzato sull’elemento selezionato.

La terza modalità invece è il Repeater, che è molto interessante quando si vuole analizzare la risposta un server, modificando quindi gli elementi della richiesta effettuata dal client e vedendo che cosa accade (l’immagine seguente propone la relativa schermata).

Infine viene la generazione del report, nel quale è importante e soprattutto fondamentale tenere a mente che un report deve garantire che per ogni vulnerabilità venga specificata la CWE, la POC e la remediation. In aggiunta può essere specificato lo strumento (o gli strumenti) utilizzati per effettuare il test. Per rendere ancora più professionale il report, si può dettagliare gli strumenti utilizzati perché perché ovviamente chi deve andare alla fine a valutare il servizio deve riuscire a ricostruire ciò che ha fatto il pentester.

Approfondiremo il discorso sulla stesura e presentazione del report in fondo a questo tutorial, ma ora vediamo cos’è e come si usa Burp.

Burp: avvio, installazione certificato e configurazione browser

Prima di iniziare con la pratica precisiamo che Burp è uno strumento disponibile sia per Linux che Windows e Mac quindi è un tool multipiattaforma. Come accennato, non è completamente free ma ha una versione Community e una versione a pagamento; la versione Community permette di effettuare quasi tutte le operazioni ma con qualche limitazione: per esempio non si può salvare il progetto, le analisi sono molto più lente e per questo motivo nel caso di utilizzo professionale conviene utilizzare la versione completa a pagamento. Ma per esercitarsi va più che bene la versione Community.

Partiamo con la demo andando innanzitutto ad avviare Burp, il quale è già disponibile in ambienti come Parrot o KaliLinux e una volta avviato si presenta sostanzialmente come proposto nell’immagine seguente, dove vediamo tante tab, la principale delle quali è la Dashboard. Notare che alcune tab aprono una finestra con delle ulteriori tab.

La tab target contiene i target di tutti i siti navigati e Proxy che riporta l’interfaccia che l’utente andrà ad utilizzare; poi nelle altre tab ci sono strumenti avanzati, quindi User Option e altri che servono nel caso in cui si utilizzino dei proxy, dato che Burp è un proxy e se nell’ambiente dove andiamo ad eseguire il test ci sono altri proxy server c'è bisogno di impostare correttamente le rotte.

Andiamo dunque alla configurazione di Burp e di Firefox; questo perché lo strumento funge da proxy e per questo deve essere configurato con il browser che si andrà a utilizzare nei test, che nello specifico è Firefox, giacché si tratta del browser consigliato. La configurazione è semplice e si basa su due passi fondamentali:

  1. Abilitare il proxy nel browser;
  2. Installare il certificato di Burp nel browser.

La prima cosa da fare per utilizzare Burp è quindi andare alla tab Proxy, quindi nella finestra che questa apre cliccare sulla Option e verificare che la voce Proxylist Net 127.0.0.1:8080 nel riquadro Proxy Listeners sia abilitata; questo che significa che Burp, essendo un proxy, si metterà in mezzo fra noi e il servizio e tutte le richieste passeranno per esso. Questo permette a Burp di intercettare i pacchetti e modificarli all’occorrenza, perché è appunto un proxy.

Quindi bisogna cliccare sul pulsante Import/Export CA certificates e nella finestra di dialogo che si apre, cliccare sull’opzione Certificate in DER Format (immagine seguente) e poi cliccare su Next per procedere con l’installazione del certificato.

Questo perché dobbiamo fare in modo che il nostro browser si fidi di Burp, ossia lo ritenga attendibile e quindi dobbiamo installare il certificato.

Dunque, cliccando su Next dobbiamo andare avanti, dare un nome al certificato e cliccare nuovamente su Next, quindi una volta che il il certificato viene creato basta andare in Firefox ed importarlo come già spiegato. Fatta questa esportazione si clicca su Next, nella successiva finestra di dialogo si inserisce la destinazione del relativo file e si clicca due volte su Next per proseguire e concludere, tornando all’interfaccia utente di Burp.

Per quanto riguarda il browser Firefox,dopo averlo avviato cliccate nel menu in alto a destra

selezionando la voce Preferenze, quindi nella barra di ricerca scrivere «proxy» e selezionare la voce Impostazioni. Nella pagina cui si accede scegliete Configurazione manuale ed impostate i valori come nell’immagine seguente.

Banner

Banner

Cliccate quindi su OK per confermare. Ora andiamo sul menu e clicchiamo su Opzioni, quindi su Privacy e sicurezza, poi su Mostra certificati e qui clicchiamo sul pulsante Importa nella sezione Autorità, selezionando il certificato salvato in precedenza da Burp. Ora dobbiamo spuntare entrambe le caselle di “trust” che appariranno con i pop-up e clicchiamo su OK per concludere la configurazione del browser.

Simulazione di attacco con Burp su form login

Ora che lo strumento è stato installato andiamo ad eseguire un attacco dimostrativo chiamato username enumeration via different responses; per spiegare di cosa si tratta poniamo il caso in cui abbiamo un’interfaccia di Login: se al suo interno utilizziamo due credenziali casuali, per esempio admin e admin, molto probabilmente dobbiamo ritentare la login perché non saranno quelle giuste. Normalmente il form restituirà il messaggio “invalid username” e questo è già una vulnerabilità, perché la pagina di login sta dicendo all'utente che cosa sta sbagliando, ossia che non viene accettato perché ha inserito uno username non corretto. Invece la login dovrebbe restituire un messaggio generico, tipo login failed o invalid username or password, così da non fornire indizi al potenziale hacker.

Adesso andiamo a vedere cosa Burp riesce a fare, copiando il messaggio invalid username restituito dal form di login, andando all’interfaccia utente di Burp, cliccando sulla tab Proxy e poi sulal Intercept che si trova nella finestra sottostante, quindi sul pulsante Intercept on, clicchiamo su login e in pochi istanti ci viene mostrato il pacchetto di dati scambiato durante il colloquio tra client e server che intercorre nel tentativo di login (immagine seguente) in una nuova tab chiamata Raw.

Ora clicchiamo con il pulsante destro del mouse all’interno della tab Raw, impartendo, dal menu contestuale che si apre, il comando Send to Intruder; sempre restando nella sezione Intruder ci spostiamo nella tab Position, puliamo con il tasto Clear tutti gli elementi selezionati e selezioniamo username. Spostiamoci alla tab Payload e nel menu a tendina accanto alla voce Payload Type andiamo a scegliere brute forcer per effettuare un bruteforce attack (quindi un attacco di tipo brute-force) che ovviamente è lunghissimo e la sua durata dipenderà dal numero di combinazioni che verranno generate (nell’esempio sotto riportato si parte da una combinazione di quattro elementi). Nel caso dell’immagine seguente sarà molto lungo, giacché le combinazioni (indicate accanto al menu a tendina con la voce request count) sono oltre 1.679.000.

 

Se vogliamo qualcosa di più veloce possiamo utilizzare la voce di menu simple list, perché consente l’esecuzione di un Dictionary Attack ovvero un attacco a dizionario che sfrutta liste esistenti di combinazioni di username e password riconosciute come le più comuni e quindi abbrevia l’effrazione per tentativi.

Quindi a un certo punto il dictionary attack, la cui condition è invalid username, restituirà il nome utente per fare login.

Va notato che qui il problema da affrontare non è solo trovare la stringa, ma anche il fatto che un dictionary attack comunque invia numerose richieste ma il sistema non fa nulla, quindi semplicemente può essere attaccato finché non viene individuato lo username; ma non tutti i sistemi sono così, perché potremmo trovarci ad aver a che fare con un sistema dove potrebbe essere inserito un un codice captcha per evitare attacchi automatici.

Torniamo un attimo indietro per vedere un’ulteriore funzione accessibile dalla solita tab Intruder>Payload: con l’attacco simple list possiamo, nella sezione Payload [Options Simple List] incollare una lista di username presi da un database o da un sito come ad esempio https://portswigger.net, semplicemente facendo copia da qui e cliccando su Paste in Burp (immagine seguente).

Altra possibilità è andare nella tab Option, dove andiamo a inserire nella casella accanto ad Add che si trova nel riquadro Grep Match quella “invalid username” che abbiamo ottenuto all’inizio facendo login con dati casuali.

L’attacco si avvia, per tutti i tipi selezionabili dalla tab Payload, cliccando sul pulsante Start Attack.

Banner

Ad attacco completato Burp restituirà una finestra riepilogativa (immagine seguente) dove tutte le voci riportare nella lista avranno invalid username con il segno di spunta accanto; ciò significa che tutte queste voci (come si può vedere anche dal menu sottostante nella tab Response) hanno in comune una risposta di tipo invalid username.

Banner

Però in cima alla lista in Results troviamo una voce che ha una risposta differente: arcsight non ha la spunta e se andiamo ad approfondire nel riquadro della tab Response>Raw che mostra il codice, vediamo che scatena la risposta incorrect password. In realtà non solo è differente il messaggio, ma anche la lunghezza della risposta e quindi anche tramite la lunghezza riusciamo a capire quale può essere un possibile username; questa condizione ci è d’aiuto perché non è detto che il messaggio invalid username oggetto della ricerca venga correttamente identificato dal nostro strumento, in quanto a volte è scritto in modo diverso, seppur di poco. Invece con la lunghezza (colonna Length) possiamo vedere che la risposta è diversa, perché come vedete nel riquadro dell’immagine precedente abbiamo ottenuto uno stato 200 (significa OK) uguale alle altre voci ma la lunghezza è diversa.

Da qui abbiamo ricavato lo username, ossia arcsight e questo perché ha restituito una risposta differente: se ricordate all’inizio, combinazioni casuali restituivano incorrect username, indicando che di quanto Burp introduceva nel form di login era non corretto lo username. Se otteniamo incorrect password, significa che in  corrispondenza di uno username inserito per tentativi, quello va bene ma manca la password; altrimenti avremmo continuato a ottenere incorrect username o altro 

Ora lo username trovato essere aggiunto nel riquadro della tab Intruder>Positions come vedete nell’immagine seguente, al posto dello username nell’ultima riga del codice.

Adesso ci manca la password, che andremo a trovare per tentativi esattamente come fatto con lo username, ossia si ripete la procedura dell’attacco simple list, quindi andando alla solita tab Intruder>Payload e, nella sezione Payload [Options Simple List], incollando una lista di password presi da un database o da un sito come il solito https://portswigger.net, semplicemente facendo copia da qui e cliccando su Paste in Burp. Fatto ciò, si deve andare nella tab Option, inserendo nella casella accanto ad Add che si trova nel riquadro Grep Match “invalid password” e dunque avviando l’attacco cliccando sul pulsante Start Attack.

Il risultato sarà mostrato nella tab Results della finestra di dialogo Intruder attack, dove stavolta troveremo la lista di password con la spunta su quelle che combaciano con la stringa di risposta incorrect password che abbiamo introdotto per fare la ricerca; troviamo anche molte possibili password senza la spunta, quindi probabili vere. Notiamo anche sotto Status un codice differente, ossia 400 che in HTTP corrisponde a bad request, perché qui il messaggio di errore non è incorrect password ma è invalid CSRF token. Troviamo anche il messaggio che è 302, il quale  si interpreta considerando che di solito i messaggi 300 sono quelli moved, quindi quelli prodotti quando avviene uno spostamento; siccome zcvbnm è l’unica voce della lista con una lunghezza diversa (207),  questa probabilmente è la password.

Quindi abbiamo visto come è possibile sfruttare questa tipologia di attacco utilizzando quindi Burp; dopo vedremo come gestirla anche nel riporto.

Simulazione attacco sfruttando vulnerabilità  Reflected Cross-site Scripting

Passiamo a un altro attacco simulato, stavolta sfruttando la vulnerabilità reflected cross-site scripting; questo consiste nella possibilità di eseguire codice lato server, quindi questo significa che il cross-site scripting può essere o reflected o stored.

Stored significa che è possibile salvare uno script all’interno del database: ad esempio se abbiamo la possibilità di commentare una foto, se riusciamo ad iniettare uno script ogni qualvolta viene aperta quella foto viene eseguito un codice; il caso più classico e quello dei forum, dove tutte le volte che qualcuno riesce a fare un post con dentro uno script, chiunque apre poi la relativa pagina del forum si “prende” anche lo script, con le conseguenze del caso laddove si tratti di uno script malevolo. In breve, nel computer che apre la pagina va in esecuzione lo script.

Per fare una dimostrazione di questo attacco andiamo nuovamente al sito https://portswigger.net, che utilizziamo come “laboratorio” e cerchiamo questo tipo di attacco (reflected cross-site scripting o stored cross-site scripting) quindi nella casella della relativa pagina (ipotizziamo di iniziare con l’attacco stored) inseriamo uno script banale e innocuo, il quale non fa null’altro che cosa mostrare un pop-up di benvenuto al sito (<script>alert(“benvenuto al sito”)</script>).

Questo significa che il sito, ovvero l’applicazione web, è vulnerabile al cross-site scripting perché se inseriamo in https://portswigger.net una voce dovrebbe semplicemente dare “0 risultati per questa voce” ma non dovrebbe eseguire lo script; se lo fa, questa è un’altra vulnerabilità presente sul sito che prende, appunto, il nome di cross-site scripting e fondamentalmente funziona in questo modo. Quindi basta inserire uno script e se un utente malintenzionato riesce a inserire quindi un form di login o riesce a reinderizzare l'utente su un altro sito: tutto è possibile perché potendo inserire lo script è possibile anche inserire qualsiasi tipo di codice.

Simulazione attacco sfruttando vulnerabilità XML Injection

Passiamo all’ultima dimostrazione di attacco che è l’XML injection e consiste nella possibilità di inettare un codice XML. Per descriverlo ci appoggiamo sempre al sito laboratorio  https://portswigger.net dove andiamo a cercarlo.

L’attacco XML injection sostanzialmente è un esploit (una vulnerabilità) che consente di alterare le funzionalità del server modificando il codice XML.

Per consentirci di fare e spiegare una prova pratica, il nostro sito https://portswigger.net

alla pagina dedicata a questo attacco ci consente di generare delle richieste intercettabili con Burp e nello specifico riporta delle immagini relative ad alcune città; scegliamo Milano e inviamo la richiesta di visualizzazione, mentre contemporaneamente proviamo ad intercettare la richiesta con Burp. Facciamo quindi un proxy intercept e questa volta la richiesta la inviamo al Repeater, perché il Repeater ci offre la possibilità di utilizzare la funzione (correlata all’omonimo pulsante) Send e vedere come risponde il sito; nell’immagine seguente vediamo, dopo il clic su Send, che nel riquadro Raw a sinistra il product id corrispondente all’immagine richiesta è 70, come appare nell’ultima riga del riquadro di destra.

Andiamo quindi a modificare nel riquadro della tab Raw di sinistra il product id, mettendo al suo posto 881; vediamo che a seconda di quello che scriviamo otteniamo delle risposte dal server, infatti a destra troveremo 881 nell’ultima riga. La risposta del server può anche essere esplicitata cliccando sulla tab Render nella sezione di destra.

Per vedere come si comporta un XML injection inseriamo in penultima riga (posizione 14) una riga come quella mostrata nell’immagine seguente e nell’ultima riga andiamo a scrivere al posto del product id &xxe; questo significa che stiamo utilizzando una risorsa Entity, ossia un’entità esterna che chiameremo xxe.

Questa entità esterna va a prendere il file etc/passwd cioè dice di andare a prendere il file passwd che è un file presente nelle macchine Linux e contiene la lista degli utenti con le relative password; quindi clicchiamo su Send e come potete vedere nell’immagine seguente, nel riquadro a destra otteniamo dal server un messaggio invalid product ID (perché abbiamo alterato il product id scrivendone uno che il server non riconosce) ma intanto otteniamo anche la lista degli utenti con le relative password.

Quindi questa è una vulnerabilità che consente di richiamare risorse remote; questo perché se andiamo a modificare la stringa di richiesta del numero di prodotto e indichiamo che non è fisso ma deve andarlo a prendere da una risorsa esterna (la &xxe dell’esempio è una variabile) al server viene chiesto di prendere il file etc/passwd (ma potrebbe essere altro che vogliamo ottenere). Quindi con l’attacco XML injection e stiamo ingannando il sistema dandogli un'istruzione che non si aspetta, ma che fa riferimento a qualcosa che interessa a noi o all’hacker di turno.

Per difendersi da questo tipo di attacco, ciò che dovrebbe essere fatto è evitare che il sistema possa richiamare risorse esterne.

Presentare al cliente il report di penetration test

Andiamo ora all’argomento “reportistica” spiegando come impostare il report sul test affinché sia utile al committente ed evidenzi, nel contempo, la professionalità del pentester.

Iniziamo con l’intestazione del report, che deve contenere il nome dell’applicativo testato e subito dopo lo scopo, esponendo qualcosa del tipo: “il presente report ha lo scopo di descrivere l’esito di delle verifiche di sicurezza effettuato per la componente dei servizi esposti su rete pubblica nel corso del mese di giugno…”.

Un dettaglio importante è fare in modo che ci siano sempre elementi nella parte alta e nella parte bassa del report: nella parte alta possiamo mettere il nome dell’applicativo testato e in quella bassa il nome del documento, che possiamo chiamare “Penetration test seguito dalla data di esecuzione”. Poi un’altra voce da riportare è il nome di chi lo ha redatto (e magari il versioning del penetration test) oltre a chi lo ha e verificato e ovviamente se ci sono delle gerarchie.

Non fate mancare la dicitura “documento confidenziale” con gli avvertimenti del caso.

Di seguito scrivete un sommario e ovviamente la descrizione dell’Assessment che inizia con il contesto in cui si è operato, quindi per garantire la sicurezza è stata effettuata una verifica su un certo servizio che consente di accedere ai servizi utente ecc. Fate quindi una sintesi dell’analisi e delle anomalie riscontrate. Un esempio è proposto nell’immagine seguente.

Dopo la sintesi vanno elencati gli strumenti utilizzati per condurre il test, quindi, ad esempio, Burp professional (con indicata la versione), poi l’estensione Wappalyze per Firefox, Nikto per fare l’analisi delle vulnerabilità e potrebbero essercene altri ancora.

Poi passiamo al dettaglio delle vulnerabilità rilevate: un esempio di vulnerabilità riscontrabile è proposto nell’immagine qui di seguito esattamente come lo avremmo dettagliato in un report per il cliente.

La vulnerabilità elencata per prima è Observable discrepancy - CWE203 e già questa informazione dà la percezione di un lavoro professionale, perché viene utilizzata una classificazione internazionale (CWE è l’acronimo di Common Weakness Enumeration) a livello di macro gruppi (di tipologie) di vulnerabilità, come definito nel sito indicato in basso. CWE è, a livello gerarchico, il raggruppamento per tipologia mentre il numero che segue è la specifica vulnerabilità, poi descritta a parole. Il numero della vulnerabilità è riferito univocamente a un’applicazione e ad un determinato periodo temporale. 

Nell’ambito di questa collocazione si trova un altro fattore, ossia il CVSS, che è lo score (punteggio) che viene dato a una certa vulnerabilità; nel nostro esempio non è stato esposto.

A livello di rischio c’è un altro elemento di valutazione che è il livello di complessità per sfruttare la vulnerabilità: ad esempio il rischio può essere molto alto perché la vulnerabilità espone il sistema che ne soffre a un problema grandissimo, ma poter sfruttare tale vulnerabilità non è così semplice, anzi è molto complicato; ad esempio su SSH c’è una vulnerabilità da poco rilevata, però chi realizza il protocollo SSH ha dichiarato che possa essere sfruttata soltanto nel momento in cui l’utente si sia già autenticato. Questo per dire che ai fini della valutazione del rischio occorre considerare non solo i livello di criticità di una certa vulnerabilità ma anche la difficoltà nel riuscire a sfruttarla.

Tale circostanza potrebbe essere un’informazione da aggiungere al report, giacché alcuni prodotti software che eseguono il Vulnerability Assessment e che fanno la scansione delle vulnerabilità  forniscono tale informazione.

Anche Burp dà questo tipo di informazioni, anzi quando vengono navigati dei siti mostra anche sostanzialmente una remediation, come mostra la Dashboard nell’immagine seguente dove è stata rilevata una vulnerabilità del tipo web cache poisoning e dove sotto, nella tab Advisory, viene suggerita una Issue remediation (in Request e Response sono riportate le richieste fatte e le relative risposte per capire bene il problema).

Vediamo anche una vulnerabilità OS common injection e, nella tab Advisory, scorrendo in basso possiamo trovare la classificazione delle vulnerabilità (Vulnerability classification) elencate in arancione sotto forma di link (apribili per approfondire…): l’immagine seguente ci mostra i codici CWE-77, CWE-78 e CWE-116. 

Tornando alla vulnerabilità CWE-203 del nostro esempio, scaturisce dal fatto che tornando al primo test abbiamo inserito username e password ed abbiamo ottenuto l’informazione invalid username, che di fatto è rilevante e, come avete visto, può portare con un po’ di lavoro a decifrare le credenziali.

Andiamo avanti con la stesura del nostro report e inseriamo un elemento importantissimo che è la POC (Proof-Of-Concept): produrla significa indicare come siamo riusciti a evidenziare la vulnerabilità e cosa abbiamo fatto per mettere in evidenza la vulnerabilità; nell’immagine seguente vediamo una descrizione con allegati gli screenshot che la provano: nel caso specifico “è possibile enumerare username e password sfruttando le informazioni di risposta fornite dal client” (invalid username).

L’immagine propone gli screenshot del pacchetto inviato (a sinistra) e di come il server interrogato dal client ha risposto (a destra).

Quindi non solo elenchiamo al cliente le vulnerabilità riscontrate, descrivendole e codificandole secondo standard internazionali, ma diamo anche la dimostrazione che, nel caso esemplificato, è possibile enumerare username e password sfruttando e le informazioni di risposta fornite dal client.

Concludiamo il rapporto con le raccomandazioni per evitare la vulnerabilità, ossia la remediation del caso, che sono le indicazioni per mettersi al riparo dalle vulnerabilità riscontrate; nel caso dell’esempio l’esposizione della remediation all’interno del report è quello proposto nell’immagine seguente.

In sintesi, tutti i messaggi di errore da mostrare all’utente che tenta l’accesso devono essere generici e non specifici, ovvero non debbono fornire indicazioni su cosa non è stato accettato, perché già quello è di per sé un’indicazione.

La pagina di accesso è vulnerabile anche al brute Force Dictionary Attack e come remediation,  si può introdurre un blocco IP temporaneo oppure introdurre il doppio fattore di autenticazione.

Lo strumento utilizzato per il test è Burp suite Professional versione 2.1.04.

Andiamo ora a vedere la seconda vulnerabilità riscontrata e descritta nel nostro esempio, che riguarda l’XML injection, descritta dal codice CWE-611. L’immagine seguente propone la descrizione di questo XML injection, riferito a un software che elabora un documento XML che può contenere entità XML con URI che si risolvono in documenti al di fuori della sfera di controllo prevista.

Anche in questo caso c’è una Proof Of Concept che in tutti casi è fondamentale perché chi riceve il report deve essere in grado di replicare la vulnerabilità; la POC è riproposta nell’immagine seguente e consta del pacchetto inviato e della risposta che dimostra la vulnerabilità.

Nel report relativo a questa seconda vulnerabilità abbiamo anche la relativa remediation, che si riassume nel consiglio che molti parser e validatori XML possono essere configurati per disabilitare l’espansione di entità esterne.

Anche in questo caso lo strumento utilizzato per il test è Burp suite Professional versione 2.1.04.

Infine vediamo il report relativo al il cross site scripting, contraddistinto dal codice CWE-79; come riporta l’immagine seguente, l’applicazione testata non neutralizza o neutralizza impropriamente l’input controllabile dall'utente prima che venga inserito nell’output utilizzato come pagina web che viene servita. 

Anche qui è alegata una POC, che è lo script che abbiamo visto in precedenza descrivendo questo attacco e la remediation consiste nell’utilizzare librerie anti-XSS.

Anche qui abbiamo il riferimento agli strumenti utilizzati (sempre Burp professional 2.1.04).

Ripe Ncc Member
vmware
CloudLinux
Plesk
HP
Microsoft