Penetration test – Analisi codici errori e stack trace
Analisi di codici di errore (WSTG-ERRH-01)
I codici errore possono rivelare ulteriori informazioni sul server o sull’applicazione web, per questo è molto importante manomettere le richieste HTTP con l’ obbiettivo di far generare errori dall’applicazione.
La prima cosa veloce da fare è quella di ottenere un errore 404 Not found, aprendo una pagina inesistente, in modo da ottenere la versione del server web, la sua porta e il suo IP.
Uso del metodo PUT con telnet
Dobbiamo testare anche altri metodi, per esempio il verbo PUT. Utilizzeremo il comando telnet
telnet 192.168.0.30 80 PUT /test.txt HTTP/1.1
Gli errori possono cambiare a seconda del server web, potrebbe venire fuori un 408 Request Timeout oppure un 405 Method Not Allowed riferito al PUT.
Lo stesso tipo di test dovrebbe essere fatto per il codice di stato 400 Bad Request, lo facciamo sempre con telnet inviato una richiesta GET
telnet 192.168.0.30 80 GET / HTTP/1.1
Attendendo 21 secondi du Apache otterremo un Request Timeout.
Tentando con un verbo HTTP inesistente otterremo probabilmente un 501 Not Implemented
telnet 192.168.0.30 80 JEFF /test.txt HTTP/1.1
A seconda della configurazione del server web nessuno, alcuni o tutti i test appena effettuati potrebbero fornirci informazioni aggiuntive sul server stesso o sulla sua configurazione.
Per questo molti stati di errore, come il 404, dovrebbero essere personalizzati in fase di sviluppo in modo da non fornire informazioni. Anche alcune componenti delle applicazioni possono fornire informazioni altre informazioni sulla versione e sul tipo di tecnologia di beckend in uso.
analysis of stack traces (WSTG-ERRH-02)
Possiamo manomettere i parametri delle richieste per generare interessanti codici di errore, provando a compromettere il flusso logico dell’applicazione e trovare spunti interessanti che potrebbero informarci sulle vulnerabilità dell’applicazione.
Si può provare a fornire come valori assolutamente niente, input molto lunghi o valori non validi come ad esempio i caratteri speciali.
Entriamo in Mutillidae ed clicchiamo su login/register. Abilitiamo intercept del proxy di burp ed effettuiamo un login fasullo
Campi vuoti
Adesso eliminiamo la riga finale dell’intercept dove c’ è lo user il login e il submit e reinoltriamo la richesta coi campi vuoti premendo sul tasto forward e vediamo la risposta.
Rieffettuiamo lo stesso test cancellando oltre alla riga finale anche quella vuota sopra e tutti gli spazi e a questo punto l’applicazione si è rotta restituendo un 404
Buffer overflow
La classe string di php è in grado di contenere un certo numero di byte, se diamo al campo input un valore maggiore rispetto a quello che può contenere otterremmo un information leak che ci fornisce il percorso completo dello script php.
Su mutillidae andiamo sul menu OWASP e scegliamo Injection (others) / buffer overflow / repeater.
Nei campi string to repeat e number of times to repeat inseriamo delle cifre molto alte. Riceveremo un fatal error con il percorso esatto della cartella.
Caratteri non validi
Possiamo passare dei caratteri non validi all’applicazione e vedere come reagisce,
192.168.0.30/mutillidae/index.php?page=%%00
abbiamo inserito il carattere nefasto % e nel nostro caso riceviamo una serie di warning.
Parleremo più approfonditamente del buffer overflow e dei caratteri codificati parlando delle XSS e delle iniezioni SQL.