Da alcuni mesi ho deciso di approfondire l'aspetto sicurezza nel mondo dello sviluppo di applicazioni .NET.
La categoria Security sarà da considerarsi come il mio diario di viaggio verso questo mondo che, per mancanza di tempo, mi sono deciso solo ora ad affrontare.
La prima pagina (come d'obbligo) inizia con alcuni fondamenti relativi alla sicurezza. Niente di pratico.. solo raccomandazioni.
- Utilizzare account con permessi Limitati
Processi che eseguono script o eseguono cidice dovrebbero girare sotto account (least) per limitare potenziali danni che possono essere eseguiti se il codice è corrotto.
L'account ASPNET viene considerato un modello di (least account).
Questa decisione è stata presa dal team ASPNET nelle prime release del .NET Framework. Si può ricordare che durante il beta testing l'account ASPNET girava come SYSTEM (!).
- Chiudiamo i cancelli (come utilizzare i GateKeepers)
E' da considerare la possibilità d'inserire dei cancelli tra i diversi layers dell'applicazione.
Ogni blocco deve poter garantire al blocco successivo che l'utente è trusted e che può quindi entrare in esecuzione. Il primo blocco di esecuzione deve quindi poter contare due cancelli. (1 Entrata, 2 Accesso al successivo blocco).. tutti gli altri avranno un unico blocco per l'accesso al blocco successivo.
- Non fidarsi dei dati inseriti in input
Tutti i dati input devono essere verificati dal codice prima di eseguire operazioni. Tecniche di validazione dovrebbero includere sistemi di filtraggio caratteri speciali. Questo tecnica può proteggere l'applicazione contro attacchi (accidentali e non).
Alcuni esempi come : Sql Injection, Script Injection e Buffer OverFlow possono farci riflettere sul reale utilizzo di questa tecnica.
- Mai abbassare la guardia
Una pratica abbastanza diffusa tra i sviluppatori è quella di ridurre i parametri di sicurezza semplicemente per far "girare" un applicazione. Se l'applicazione in sviluppo richiede di forzare i livelli di sicurezza o di cambiarli, testane gli effetti! e cerca di capire perchè ciò è necessario prima di cambiare i parametri.
- Giocare a nascondino non serve a niente
Cercare di nascondere valori dentro variabili dal nome tipo "cicciopasticcio" o nascondere informazioni nel registro di sistema non significa assolutamente mettere in sicurezza l'applicazione. Utiliziamo strumenti nativi messi a disposizione dalla tecnologia .net per proteggere i dati.
- Rilasciare i PASS per far vedere cosa vogliamo noi
Se non vogliamo utilizzare la tecnica dei cancelli, rilasciamo all'utente un PASS per accedere alle risorse che la sua profilatura permettono e neghiamo l'accesso a tutte l'altre. Questo discorso è da considerare nel caso in cui lo sviluppatore sia capace di ideare e sviluppare un solido sistema di autentificazione "al cancello principale".
- Consideriamo tutti i sistemi esterni INSICURI
E' bene sempre ricordare che tutti i sistemi che possono accedere all'applicazione possono essere dei potenziali nemici.
- Mostriamo solo ciò che serve
Non esporre più informazioni di quante necessarie durante il ritorno di un messaggio di errore all'utente finale. Scriviamo maggiori informazioni relative all'eccezione nel Windows Event Log.
Non facendo questo, si aprono potenziali porte che possono essere utilizzate per scovare vulnerabilità nel sistema.
- Se non lo usi disabilitalo
Si possono ridurre potenziali punti di attacco disabilitando moduli o componenti di cui la nostra applicazione non ha realmente bisogno. Per esempio: se la nostra applicazione non necessità di Output Caching perchè dovremmo lasciarla abilitata? Se viene rilevato un bug in questo modulo la tua applicazione diventa automaticamente vulnerabile.