Le web application, per come le conosciamo, spesso necessitano di nascondere alcuni dati che possono essere classificati come segreti.

Nel caso in cui essi esistano, è necessario metterli in sicurezza da (li lascio in inglese perchè fa + figo) :

  • rogue administrators
  • web malicious users

Le Spie. I Rogue Administrators
Questi ed altri utenti privi di scrupoli possono avere la possibilità di leggere segreti.
Per esempio, un amministratore WebServer non dovrebbe essere in grado di leggere le credenziali di accesso al Server SQL della rete aziendale.

Le mura sono cadute ma posso difendermi ancora.
Immaginando FileAuthorizaionModule come una reale protezione alle problematiche relative all'accesso ai files.
Nel caso in cui un attacco faccia breccia nelle mura dell'applicazione, i dati segreti devono comunque rimanere tali.. o meglio dovrebbero provarci. Nel caso in cui l'attacco raggiunga i file di configurazioni, questi non dovrebbero mai contenere le informazioni segrete in testo leggibile.

Identificare i segreti
Tipici esempi di segreti possono essere:

  • SqlConnectionStrings - Un classico; Di solito queste informazioni di accesso sono in formato plain text, La raccomandazione primaria è quella di utilizzare sempre il meccanismo di autentificazione Windows invece di quello Sql Server. Nel caso questo non sia possibile è possibile applicare altre tecniche che descriverò nei prossimi post.
  • Credenziali di Sql Server usate per gli application roles - Gli application roles devono essere sempre attivati da una stored procedure che richiede il nome del role e la password associata.
  • Fixed Identities - Come descritto nel post precedente, le fixed identities possono essere decisamente utili, ma queste vanno messe in sicurezza. Ho già parlato di aspnet_setreg.exe e non mi stancherò mai di dire di utilizzarlo ogni volta che si utilizzano le FI.
  • Process Identity - Come per le Fixed Identity, Process Identity (nel machine.config) deve essere criptato utilizzando aspnet_setreg.exe.
  • Chiavi utilizzate per mettere in sicurezza dati - E' impossibile pensare di nascondere informazioni all'interno del software. Ma è comunque possibile effettuare delle operazioni che possono attenuare il rischio. Per esempio è possibile creare dei custom handler di configurazione che possono criptare in modo asimmetrico valori session. Così sarà possibile archiviare la la session in un altro configuration file.
  • SQL Server session state - Utilizzare le session state basate su Sql Server, sempre ricordando che aspnet_setreg.exe fornisce supporto anche per stateConnectionString e sqlConnectionString localizzati nell'elemento sessionState.
  • Password per le Forms Authentication - Se la nostra applicazione valida le credenziali degli utenti confrontandole con quelle presenti in un database, non teniamo in chiaro queste password. Usiamo almeno un algoritmo di hashing per metterle in sicurezza.

I nostri strumenti
Fortunatamente .NET dispone diversi tools per nascondere i nostri "segreti". Questi sono:

  • Le classi .NET Cryptography - Ricordiamo che il Framework contiene classi atte ad effettuare operazioni di criptaggio e decriptaggio.
  • Data Protection API (DPAPI) - DPAPI è un set di api per win32 che cripta e decripta dati utilizzando una chiave derivata dalla password dell'utente loggato. Quando si usa DPAPI, non si ha bisogno di lavorare con set di chiavi. Questa operazione è gestita direttamente dal sistema operativo.
  • CAPICOM - Questo è un oggetto COM di Microsoft, che mette a disposizione un accesso COM-BASED alle Crypto API.
  • Crpyto API - Sono delle api Win32 di basso livello che effettuano operazioni di criptaggio e decriptaggio.

Tip : Hai bucato l'applicazione ma non hai trovato niente.
E' sempre da considerare la possibilità di installare le WebApplications in volumi logici separati dal sistema operativo. Questo significa che il machine.config ed altri files, (es: i file UDL) che possono contenere segreti, sono in altri volumi logici, che risultano essere irragiungibili dai famigerati Path Bugs.

In questo caso suggerisco di allegare sempre un file dal nome suck.lamer  per i nostri possibili ospiti