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

More documents

Recommendations

Info

CAPITOLO VI - Gli attacchi e il progetto OWASP Il meccanismo di autenticazione e la gestione delle sessioni sono elementi importanti per assicurare dei requisiti minimi di sicurezza nelle applicazioni web. L’utilizzo di password considerate "deboli", ovvero composte da pochi caratteri (solamente alfabetici), che compongono parole d’uso comune nella lingua considerata, è una pratica sconsigliata in quanto rende possibile un attacco a forza bruta basato su dizionari. Un sistema di autenticazione dovrebbe imporre una lunghezza minima e dei criteri di complessità per le password scelte dagli utenti, questo rende più complesso il trovare una password tirando ad indovinare Tutte le password devono essere conservate sotto forma di hash oppure cifrate in qualsiasi modo esse vengano conservate ed è la soluzione adoperata nella nostra applicazione. E’ preferibile l’utilizzo di una funzione di hash, in quanto non reversibile. E’ importante non mantenere nei log informazioni come username e password, i log potrebbero essere in uno spazio insicuro. Tra le altre cose dovrebbe essere configurato un numero prefissato di tentativi di login per unità di tempo. I tentativi falliti dovrebbero essere loggati. Per le stesse ragioni è consigliabile inoltre adottare delle policy di cambio password che non permettano l’inserimento di parole chiave già utilizzate in passato; ad un cambio di password all’utente dovrebbe essere sempre richiesto l’inserimento della vecchia e della nuova password, analogamente dovrebbe essere richiesta un’ulteriore conferma per il cambio di mail, altrimenti qualcuno potrebbe inserire il proprio indirizzo e poi richiedere la password "dimenticata" . Bisogna proteggere le credenziali in transito, e l’unica tecnica efficiente è quella di proteggere tutta la fase di login utilizzando protocolli come SSL. La semplice trasformazione in hash della password, prima della trasmissione della medesima, fornisce una scarsa protezione. La transazione potrebbe essere intercettata e ritrasmessa anche se l’attuale password non è nota. I sistemi dovrebbero essere progettati in modo da evitare l’accesso alla lista dei nomi degli account presenti sul sito. Se queste liste devono essere mostrate, si raccomanda di usare degli pseudonimi che mappano i nomi veri degli account. In questo modo, lo pseudonimo non può essere utilizzato per un tentativo di login o per altri metodi di attacco su di un account utente. Altro elemento da tener presente è la cache del browser: i dati di autenticazione e di sessione non dovrebbero mai essere trasmessi come parte della GET; al contrario dovrebbero essere utilizzate sempre delle POST. Le pagine di autenticazione dovrebbero essere marcate con il tag 134
CAPITOLO VI - Gli attacchi e il progetto OWASP “no cache”; in questo modo si può prevenire la possibilità di usare il tasto “back” per tornare alla schermata di login e reinviare le credenziali utilizzate precedentemente. 6.5 Cross Site Scripting Il cross site scripting è una tipologia di attacco che può essere portato a compimento anche se solo uno dei tre attori principali della società informatica, cioè utenti, sviluppatori e amministratori di sistema, è incauto. Si tratta di una vulnerabilità che consente ad eventuali aggressori di inserire del codice arbitrario all’interno delle applicazioni web, così da modificarne il comportamento per perseguire i propri fini illeciti. Il codice inviato, spesso sotto forma di script (JavaScript, VBScript e così via), verrà eseguito senza alcun controllo dal browser dell’utente poiché inoltrato da una sorgente ritenuta sicura: il server web da cui proviene la pagina. Figura 68 XSS con un sito vulnerabile 1. l’hacker crea uno script nato per girare nel browser del client 2. l’hacker inietta in qualche modo lo script nel web server 3. il web server consegna lo script a uno o più client 135
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:
Page 79 and 80:
Page 81 and 82:
Page 83 and 84:
Page 85 and 86: 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 135: 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?