In questo post si parlerà di tecniche atte a mettere in sicurezza i vari tipi di stati che una normale web application può trovarsi a gestire.

Securing ViewState

Se la nostra Web Application utilizza il viewstate è bene considerare di:

Assicurarsi dell'integrità del messaggio, per far questo è bene abilitare il direttiva enableViewStateMac a true.

<% @ Page enableViewStateMac=true >

Questo comporta la generazione di un Message Authentication Code (MAC) da parte di ASP.NET, durante l'evento postback.

Configurare l'attributo validation presente nel machine.config , per specificare il tipo di criptaggio che sarà utilizzato per la validazione dei dati. (SHA1- 3DES per esempio). Ricordiamo che SHA1 (Secure Hash Algorithm 1) produce un hash di dimensioni decisamente superiori a quelle che può produrre MD5 (Message Digest 5), per questo fattore spesso viene considerato maggiormente.

Utilizzare 3 Data Encryption (3DES) per verificare eventuali cambiamenti al viewstate e anche per criptarlo durante la sua fase di transito.

Securing Cookies

Per i cookie che contengono dati di autentificazione o autorizzazione o altri dati personali, questo dovrebbero essere sicuramente messi in sicurezza tramite SSL durante la loro fase di transito. Per le Forms Authentication, il metodo FormsAuthentication.Encrypt può essere utilizzato per criptare i ticket di autorizzazione, i quali poi verranno inviato dal server al client et viceversa.

Securing SQL Session State

L in process session state Handler di ASP.NET ha sicuramente delle limitazioni. Per esempio, non può lavorare su più computers in un ambiente Web Farm. Per passare il problema, ASP.NET fornisce la possibilita di archiviare i session state in un Database di Microsoft SQL Server.
SQL Session state può, naturalmente, essere configurato sia nel Machine.Config che nel Web.Config

Lo script sql utilizzato per creare il database di default è installato nella seguente path
c:\winnt\microsoft.net\framework\<version> dove <version> sta per la versione del framework da voi installato.

Ci sono due problematiche da considerare quando si decide di utilizzare SQL Session State.

1. Mettere in sicurezza la connection string che punta al database
2. Mettere in sicurezza il session state condiviso all'interno del network.

Securing Database Connection String

Se si utilizza SQL Authentication per connettersi al server, la connection string specificata nell'attributo sqlConnectionString conterrà una username ed una password. In questo caso, come detto più volte nei post precedenti andiamo ad utilizzare aspnet_setreg.exe.

Ma è assolutamente da considerare il fatto di utilizzare la Windows Authentication per connetersi al database. Il vantaggio è negli occhi di tutti, nessuna stringa di connessione conterrà username e/o password e aspnet_setreg.exe potrà essere tralasciato.

Per migliorare ulteriormente le cose è possibile utilizzare il process identity di ASP.NET per effettuare le Windows Authentication nei confronti di un database SQL Server.
Per far questo è necessario:

Creare un duplicato dell'account (con medesima username e password) nel server database.
Creare un SQL login account
Mappare l'utente al database ASPState.
Crare un ruole all'interno del database, aggiungere l'utente al ruole.
Configurare le permissions nel database per il ruolo in cui l'utente è stato inserito.

A questo punto è possibile trasformare la connection string per passare in modalità Trusted Connection come sotto scritto

Securing Session State Across the Network

Questa è sicuramente la parte meno importante del post.
Diciamo che l'idea di proteggere SQL Session State durante il traffico all'interno del network può essere una buona idea..

E' da considerare buona l'idea di utilizzare IPSec per proteggere tutto il traffico tra WebServer e Sql Server, o alternativamente, possiamo utilizzare SSL per mettere in sicurezza i link relativi a SQL Server, applicando questa tecnica è possibile criptare la connessione utilizzata per il session state e non tutto il traffico.