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

More documents

Recommendations

Info

CAPITOLO VI - Gli attacchi e il progetto OWASP Figura 66 Proprietà “Organizzazioni” della classe Concessionario 6.2.6 Tentativi di SQL Injection in Talete Per verificare l’effettiva sicurezza e protezione della piattaforma Talete da attacchi di tipo SQL Injection ho effettuato una serie di tentativi di violazione del database, eseguiti tramite i vari form d’inserimento di cui il sito web della piattaforma dispone. Inizio con il valutare i vari tipi di risposta che posso ricevere dall’esecuzione della pagina; oltre al caso ovvio e non interessante di inserimento corretto e valido dell’input, generalmente dovrebbero essere forniti messaggi d’avviso da parte della pagina web stessa nel caso di inserimenti sintatticamente validi ma che non trovano riscontro nelle tabelle utenti contenute nel database (il classico caso dell’errore di digitazione) ed i messaggi d’errore forniti dal web server in caso di non corretta esecuzione della query SQL (ovvero quelli causati da inserimenti “malevoli”). Provo ad introdurre valori casuali nei form e ad avviarne l’esecuzione; anziché essere mostrati messaggi d’avviso il browser mi visualizza la pagina di partenza richiedendo le credenziali. Provo inoltre ad inserire semplici caratteri che si suppone possano causare un 126
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
Page 1 and 2:
UNIVERSITÀ POLITECNICA DELLE MARCH
Page 3 and 4:
INDICE INDICE .....................
Page 5 and 6:
ELENCO DELLE FIGURE Figura 1 Home p
Page 7 and 8:
CAPITOLO I - Introduzione 5
Page 9 and 10:
CAPITOLO I - Introduzione tecniche
Page 11 and 12:
CAPITOLO I - Introduzione 2 Gestion
Page 13 and 14:
CAPITOLO II - Talete: Autenticazion
Page 15 and 16:
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24:
• Ampliamento della superficie di
Page 25 and 26:
Page 27 and 28:
Page 29 and 30:
Page 31 and 32:
Page 33 and 34:
Page 35 and 36:
2.4.5 Diagramma delle classi CAPITO
Page 37 and 38:
Page 39 and 40:
Page 41 and 42:
Page 43 and 44:
CAPITOLO III - Progettare un’appl
Page 45 and 46:
3.2 Il significato dei design patte
Page 47 and 48:
Page 49 and 50:
Page 51 and 52:
Page 53 and 54:
Page 55 and 56:
4.1 Introduzione CAPITOLO IV - La s
Page 57 and 58:
CAPITOLO IV - La sicurezza nelle we
Page 59 and 60:
Page 61 and 62:
Page 63 and 64:
Page 65 and 66:
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73 and 74:
Page 75 and 76:
Page 77 and 78: CAPITOLO IV - La sicurezza nelle we
Page 87 and 88: Mentre con AnomynousTemplate si ha:
Page 95 and 96: CAPITOLO V - La sicurezza nell’ar
Page 105 and 106: 1 porsi dalla prospettiva dell’at
Page 113 and 114: CAPITOLO VI - Gli attacchi e il pro
Page 115 and 116: 6.1 Progetto OWASP CAPITOLO VI - Gl
Page 125 and 126: 6.2.5 I vantaggi nascosti CAPITOLO
Page 127: CAPITOLO VI - Gli attacchi e il pro
Page 149 and 150: 6.10 Denial of Service CAPITOLO VI
Page 151 and 152: 6.11 Insecure Configuration Managem
Page 153 and 154: CAPITOLO VII - Test per valutare la
Page 155 and 156: 7.1.1 Analisi del codice sorgente C
Page 163 and 164: vulnerabilità critiche di applicaz
Page 165 and 166: • Aggiungere la tecnologia SSL e
Page 167 and 168: Durante questi anni universitari so
Page 169 and 170: M. Fowler, D. Rice, M. Foemmel, E.
show all

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

Create successful ePaper yourself

Delete template?

Save as template?