OWASP Top 10 2013 – A4 Riferimento diretto ad un oggetto non sicuro
Tempo di lettura: 6 minutiData pubblicazione: November 1, 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.
Dopo aver introdotto e spiegato alcune tipologie di Injection, l’Enumerazione e il bruteforce e il Cross Site Scripting (XSS), in questo articolo spiegherò come un’applicazione può essere vulnerabile a riferimenti di accesso diretti non sicuri ad oggetti e/o file non protetti.
A4 - Riferimento diretto ad un oggetto non sicuro
Per sapere se un’applicazione è vulnerabile a questo tipo di attacco bisogna controllare che tutti i riferimenti agli oggetti siano protetti e non raggiungibili da un utente esterno. Le possibilità di controllo sono due:
- Per i riferimenti diretti, devono esserci restrizioni. Ad esempio, verificare l’identità dell’utente tramite un semplice login;
- Per i riferimenti indiretti, basta limitare l’accesso a determinati file e non dare la possibilità all’attaccante di accedervi.
Esempio pratico di riferimenti indiretti con HackBar
Con il plugin WebDeveloper vado a visualizzare la richiesta POST che effettua il mio browser alla pagina http://127.0.0.1/index.php?page=text-file-viewer.php
Provo quindi a verificarne la vulnerabilità con il plugin Hackbar. Per chi non fosse a conoscenza dell’esistenza di questo plugin, consiglio di leggere anche il terzo livello di Kioptrix.
Il plugin è composto da due righe: nella prima viene visualizzato l’URL target, nel nostro caso la pagina di Mutillidae; nella seconda riga vengono inseriti i parametri POST, che, sempre in questo caso, sono textfile= e text-file-viewer-php-submit-button_=_.
Andando ad eseguire la richiesta (cliccando su Execute) sono riuscito a visualizzare la versione del sistema direttamente dall’applicazione. Ovviamente ora si vede il mio sistema operativo, visto che Mutillidae è installato in locale. Ma se fosse su un server, potrei navigare nel server all’insaputa dell’amministratore. Per evitare ciò basterebbe proteggere i file con permessi speciali o non permettere di richiedere pagine al di fuori della cartella di installazione dell’applicazione web.
Esempio con BurpSuite
Per chi non avesse conoscenza del software, consiglio la guida di BurpSuite. Dopo aver avviato Mutillidae, mi connetto alla pagina http://127.0.0.1/index.php?page=text-file-viewer.php e avvio Burp con le solite opzioni
In questa stringa, possiamo notare che viene richiesta la pagina http://www.textfiles.com e visualizzata all’interno del browser. Se questa richiesta non fosse protetta, potremmo visualizzare i file presenti nel server.
Provo ora a richiedere un’altra pagina (index.php) con BurpSuite
In questo caso voglio vedere se il file index.php è visualizzabile da chiunque. Per eseguirla, basta cliccare su Forward in BurpSuite e tornare sul browser per vedere la richiesta ha avuto effetto e la pagina effettivamente esiste.
Infatti viene visualizzato il codice sorgente del file index.php. Questo file non contiene nulla di importante, ma se ci fosse un file contenente le password degli utenti, potrei tranquillamente vederlo.
Con BurpSuite è possibile automatizzare il processo, richiedendo più file senza doverlo fare a mano. Per farlo basta inviare la richiesta all’Intruder (tasto destro->Send to Intruder), nelle opzioni bisogna selezionare una lista di stringhe da inviare (io ho utilizzato questa) e far partire l’attacco.
Ecco visualizzato il file delle password.
Conclusioni
Questa vulnerabilità è parecchio rilevante per chi possiede un’applicazione web e permette la visualizzazione di pagina tramite richieste, come nel nostro caso. Per prevenire ciò basterebbe effettuare un controllo dell’accesso ed evitare attacchi di questo tipo. Per chi volesse approfondire questo tipo di attacco consiglio Path Trasversal di OWASP.