PARTE 5 – CAPITOLO 13 – MODELLO DI SICUREZZA
Ci sono alcune linee-guida da seguire per avere sin dai primi passi una applicazione più sicura:
– Non fidarsi degli input degli utenti, vanno tutti validati nel modo più restrittivo possibile
– Non usare la concatenazione per scrivere istruzioni SQL, bisogna usare la parametrizzazione per evitare SQL injections
– Non mostrare mai sulle pagine porzioni di codice inserite da un utente senza validarle, il rischio è quello di un attacco cross-site-scripting (ad esempio inserimento di codice javascrip dannoso). Per prevenire questo tipo di attacchi basta utilizzare il metodo HttpUtility.HtmlEncode() o il suo eguale Server.HtmlEncode().
– Non memorizzare dati sensibili utilizzando i campi hidden perché sono facilmente rintracciabili e modificabili
– Non memorizzare dati sensibili nel ViewState
– Abilitare SSL quando si utilizza la Basic Authentication o ASP.NET Forms Authentication (vale anche come regola generale se l’applicazione web tratta dati particolarmente sensibili)
– Proteggere i cookie e impostare la loro data di scadenza nel modo più restrittivo possibile
La politica di programmazione a “GateKeeper” permette di avere più barriere in serie (alcune implementate a livello di linguaggio, altre a livello di CLR, altre ancora a livello di Web Server, sistema operativo o altro ancora) contro un eventuale attacco informatico prima di raggiungere il dato vero e proprio.
Nel contesto della sicurezza informatica i concetti chiave (e, quindi, alcuni dei livelli del metodo a GateKeeper) sono Authentication, Authorization, Confidentiality e Integrity.
Authentication è il processo in cui si ottiene l’identità dell’utente corrente e si testa la veridicità di tale informazione. In ASP.NET ci sono quattro possibilità di implementazione: Windows Authentication (SID di 96 bit), Forms Authentication, Passaport Authentication (non più utilizzata) e Custom Authentication.
Authorization è il processo di verificare/determinare permessi e restrizioni assegnate ad un utente autenticato.
Confidentiality è una politica che si assicura che i dati non vengano visualizzati da utenti non autorizzati mentre sono trasmessi in rete o memorizzati in un DataStore.
Integrity è una politica che si assicura che i dati non vengano modificati mentre sono trasmessi in rete o memotizzati in una DataStore.
Confidentiality e Integrity si basano sull’Encryption dei dati. Si tratta di una procedura messa in atto per rendere i dati completamente illeggibili da chi non è autorizzato (da chi non possiede la chiave di decodifica).
IIS offre un primo livello di sicurezza fornendo opzioni di autenticazione, autorizzazione (tramite Access Control Lists) e riservatezza (con SSL).
Impersonation è la politica di eseguire un task con un utente differente rispetto a quello di default (uso tipico nelle web farm per differenziare gli utenti dei vari siti web ospitati).
Dato che il tag è disponibile solo nel web.config della cartella principale, è possibile inserire un solo tipo di autenticazione per applicazione (anche se possono esserci regole diverse in ogni sottocartella).
IIS 7.0 offre anche opzioni di autorizzazione role-based e IP-based.
In genere una richiesta di accesso parte da un utente che viene considerato anonimo, il sistema non lo riconosce e gli chiede di autenticarsi. In base al tipo di autenticazione sviluppata le credenziali vengono verificate da ASP.NET o da IIS. Se non ci sono riscontri viene chiesto all’utente di re-inserire le credenziali, mentre se l’utente viene riconosciuto il sistema verifica che abbia i permessi per accedere alla destinazione richiesta. In caso positivo viene garantito l’accesso, mentre in caso negativo viene mostrato un messaggio di “Accesso Negato”.
La prima barriera che si pone tra l’utente e la risorsa protetta è IIS. Per quanto riguarda l’autenticazione, IIS supporta la Basic, la Digest, la Passport, la Windows e la certificazione. Tutte le autenticazioni portano il visitatore ad “impersonare” in un utente Windows autenticato. Dopo questo passo IIS supporta solo l’autenticazione di utenti Windows. Per quanto riguarda l’autorizzazione, IIS supporta la restrizione IP e la valutazione di Windows ACLs (Access Control Lists, il modo di Windows per proteggere risorse gestita dal sistema operativo stesso). SSL viene utilizzato per garantire la riservatezza.
Secure Sockets Layer è una tecnologia che permette di cifrare le comunicazioni basate su http. Non ci sono differenze di programmazione ma solo di porte (tipicamente la 443) e di protocollo (https). Affinché un Server supporti SSL è necessario che abbia acquistato un certificato X.509, che lo abbia installato e che abbia configurato il WebServer a dovere.
Lo standard industriale dei certificati (X.509v3) richiede come parametri il nome del proprietario, della sua organizzazione e il suo indirizzo, la chiave pubblica del proprietario, il periodo di validità del certificato e il suo numero seriale.
La cifratura asimmetrica si basa sul concetto che un messaggio cifrato con una chiave pubblica (dal client) sia decifrabile solo da chi è in possesso della chiave privata abbinata (tipicamente il server). Il principio che sta alla base della cifratura asimmetrica è che trovare la chiave privata partendo dalla chiave pubblica è computazionalmente quasi impossibile (in linea teorica è meno costoso cercare di craccare il messaggio con un attacco di forza bruta che risalire alla chiave privata).
SSL combina tecniche di cifratura simmetrica (stessa chiave) e asimmetrica: la chiave per la cifratura simmetrica (generata randomly dal client per ogni sessione) viene scambiata utilizzando la cifratura asimmetrica (il client ottiene la chiave pubblica del server dal certificato).
ASP.NET e IIS implementano la tecnica dei GateKeepers per rendere più sicuro l’accesso ad una risorsa protetta.
I metodi di autenticazione offerti da ASP.NET sono memorizzati nella sezione “authentication” del file web.config. Le modalità disponibili sono Forms (per utilizzare le maschere di login personalizzate), Windows (per usare l’autenticazione del SO) e Passport (ora deprecato a favore di LiveID). Dopo aver autenticato l’utente i suoi dati sono disponibili nella variabile HttpContext.Current.User.
I metodi di autorizzazione (sezione “authorization” del file web.config) sono UrlAuthorization (allow/deny in base al nome utente o al gruppo di appartenenza) e FileAuthorization (Windows ACLs).
A prescindere dalla tipologia di accesso, gli utenti loggati vengono forniti di “principal” e “identity”. L’oggetto “identity” rappresenta l’utente in sé, mentre l’oggetto “principal” rappresenta il contesto di sicurezza corrente (identity e informazioni sull’utente memorizzate).
