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

More documents

Recommendations

Info

CAPITOLO IV - La sicurezza nelle web applications gestione degli utenti. Il meccanismo delle Membership API è costituito da due componenti fondamentali: • le API, richiamate direttamente dallo sviluppatore ed implementate attraverso la classe statica Membership; • i provider, che forniscono le funzionalità specifiche in base allo storage e che derivano dalla classe base astratta MembershipProvider. In un modello del genere, i metodi della classe Membership richiamano il corrispondente metodo definito all’interno del provider, usando un’istanza dello stesso, creata a partire dalle impostazioni specificate nel web.config. Lo schema a blocchi del Membership Provider Model è sostanzialmente il seguente: Figura 36 Membership API In pratica abbiamo nello strato più basso il Membership Store, che è sostanzialmente il livello fisico, il database come SQLServer o MySQL, oppure Active Directory o altri ottenuti scrivendo dei Provider. Al livello superiore ci sono i Membership Providers, che servono a salvare o comunque a mantenere le informazioni, su di un supporto per immagazzinare i dati. Il ruolo del Membership Provider è quindi quello di fare da ponte tra le Membership API e i 80
CAPITOLO IV - La sicurezza nelle web applications supporti d’immagazzinamento dei dati, in modo che lo sviluppatore non debba scrivere codice a basso livello. Se lo sviluppatore vuole immagazzinare i suoi dati in un formato diverso, ad esempio in un documento XML, può scrivere un proprio Membership Provider ad hoc. Salendo troviamo le Membership API che possono essere direttamente utilizzate dalle applicazioni; in questo modo è possibile controllare lo stato della Membership oppure dell’utente con una serie di metodi e proprietà, le quali andranno a leggere dal file web.config qual è il provider installato nello specifico ed utilizzarlo. Quindi esse non sono legate alla presenza di un particolare provider. Alla fine abbiamo i controlli che usano le Membership API e che permettono di gestire le classiche operazioni di Login. La classe Membership provvede metodi statici per eseguire le azioni più frequenti, tra i quali: - CreateUser: aggiunge un utente allo store della Membership - DeleteUser: rimuove un utente dallo store della Membership - GeneratePassword: genera una password random della lunghezza specificata - GetAllUsers: carica una collection di oggetti MembershipUser - GetNumberOfUsersOnline: restituisce il numero di utenti collegati - GetUser: carica un singolo oggetto MembershipUser che rappresenta un utente - UpdateUser: aggiorna le informazioni per uno specifico utente - ValidateUser: valida il login sulla base di username e password verificando che siano corrette La classe MembershipUser invece si occupa della gestione delle informazioni utente come la password, oppure delle domande per recuperare password smarrite. 2. ROLES API Con lo stesso spirito di Membership API, vale a dire quello di favorire la semplicità d’implementazione di funzionalità ripetitive, Roles API fornisce l’infrastruttura necessaria ad aggiungere anche il supporto per i ruoli applicativi all’utente. Il Role Manager ci abilita alla gestione in automatico della sicurezza a ruoli basato sulla logica a provider, con 3 provider di default: 1. AuthorizationStoreRoleProvider (per l’editabilità, cioè la gestione dei ruoli) 81
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: CAPITOLO II - Talete: Autenticazion
Page 35 and 36: 2.4.5 Diagramma delle classi CAPITO
Page 43 and 44: CAPITOLO III - Progettare un’appl
Page 45 and 46: 3.2 Il significato dei design patte
Page 55 and 56: 4.1 Introduzione CAPITOLO IV - La s
Page 57 and 58: CAPITOLO IV - La sicurezza nelle we
Page 81: 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 133 and 134:
CAPITOLO VI - Gli attacchi e il pro
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
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 157 and 158:
Page 159 and 160:
Page 161 and 162:
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?