analisi e gestione della sicurezza di una complessa applicazione ...

CAPITOLO VI - Gli attacchi e il progetto OWASP
malfunzionamento della query inoltrata al database, come ad esempio l’apice “ ‘ ” ed i caratteri
di commento “ -- ” o “ /**/”. Anche in questo caso il browser si limita ad aggiornare la pagina
iniziale senza modificarne minimamente il contenuto; lo stesso avviene con le TextBox
all’interno come quella presente all’interno della pagina dei Concessionari che serve per la
creazione di un nuovo consulente. In essa, grazie ad un validatore e al codice scritto
correttamente, qualsiasi stringa con caratteri diversi da quelli che indicherebbero il nome di un
nuovo consulente, viene rigettata.
Questo evidenzia che il sito è stato predisposto in modo tale da nascondere un qualunque tipo
di informazione che potrebbe essere utile ad un eventuale hacker (nel caso specifico il
sottoscritto).
Dopo numerosi tentativi e varianti la pagina web sembra rigettare ogni inserimento
sintatticamente non corretto, dimostrando di essere effettivamente ben progettata contro i
pericoli di SQL injection.
E’ stata ricercata anche un’anomalia che pur non avendo a che fare con le tecniche di SQL
injection riguarda comunque la sicurezza dell’accesso alla piattaforma; in caso di login corretto
il browser web viene indirizzato ad una pagina che ad esempio chiamiamo Prova.asp, dove in
base ad un “id” specificato dalla richiesta http ci verrà fornito l’accesso al materiale desiderato.
Conoscendo già il percorso completo di tale pagina Prova.asp all’interno del sito è possibile
accedere direttamente ai contenuti di tale pagina semplicemente specificando nell’argomento
della GET un Id valido, saltando così completamente la fase di riconoscimento tramite
username e password. In Talete anche questa prova ha dato esito negativo, in quanto, senza il
login, l’accesso al sito non viene permesso.
Quindi per concludere è possibile affermare che tutti i dati forniti dall’utente sono sottoposti a
meccanismi di validazione per il raddoppio degli apici o ad altre tecnice, che nel caso di input
di tipo stringa come quelli utilizzati nel sito rendono quasi impossibile un qualunque tipo di
injection. A seguito di questo riscontro è possibile ribadire l’effettiva sicurezza del sito da parte
degli attacchi di SQL Injection; da notare la presenza fondamentale dell’opzione
runat=”server”, che specifica il fatto che le operazioni previste dal form dovranno essere
eseguite dal server e non dal client.
127