Protezione dell'accesso ai dati

Articolo
10/22/2014

Aggiornamento: novembre 2007

La maggior parte delle applicazioni Web ASP.NET implica l'accesso ai dati. Molte applicazioni raccolgono in un database o in un file i dati da memorizzare che sono spesso basati sulle informazioni provenienti dagli utenti. Poiché i dati originali possono provenire da origini non attendibili e le informazioni vengono memorizzate in un formato persistente, e poiché si deve impedire a utenti non autorizzati l'accesso diretto all'origine dati, è necessario prestare particolare attenzione ai problemi di protezione inerenti l'accesso ai dati. Le informazioni presenti in questo argomento descrivono le procedure più idonee per migliorare la protezione dell'accesso ai dati nelle applicazioni Web ASP.NET.

Sebbene l'osservazione delle procedure consigliate per la codifica e la configurazione possa migliorare la protezione dell'applicazione, è importante anche installare nel server Web gli aggiornamenti relativi alla protezione più recenti per Microsoft Windows e Internet Information Services (IIS), nonché tutti gli aggiornamenti per la protezione disponibili per Microsoft SQL Server o per altro software relativo all'origine dati.

Per informazioni più dettagliate sulle procedure più idonee per la scrittura di codice protetto e per la protezione delle applicazioni, consultare il libro "Writing Secure Code" di Michael Howard e David LeBlanc o le informazioni disponibili nel sito Web Microsoft Patterns and Practices (informazioni in lingua inglese).

Protezione dell'accesso a un'origine dati

Nelle sezioni che seguono vengono fornite informazioni sulle operazioni necessarie per proteggere diversi aspetti dell'accesso ai dati.

Stringhe di connessione

Per la connessione a un database è necessaria una stringa di connessione. Poiché le stringhe di connessione possono contenere dati sensibili, è consigliabile attenersi alle indicazioni riportate di seguito:

Non memorizzare le stringhe di connessione in una pagina. Ad esempio, evitare di impostare le stringhe di connessione come proprietà dichiarative del controllo SqlDataSource o di altri controlli origine dati. Memorizzare invece le stringhe di connessione nel file Web.config del sito. Per un esempio, vedere Procedura: proteggere le stringhe di connessione durante l'utilizzo dei controlli origine dati.
Non memorizzare le stringhe di connessione come testo normale. Per proteggere la connessione al server di database, si consiglia di crittografare le informazioni della stringa di connessione nel file di configurazione utilizzando la configurazione protetta. Per ulteriori informazioni, vedere Crittografia delle informazioni di configurazione utilizzando la configurazione protetta.

Connessione a SQL Server tramite la protezione integrata

Se è possibile, connettersi a un'istanza di SQL Server tramite la protezione integrata anziché utilizzando un nome utente e una password espliciti. In questo modo si evita la possibilità di compromettere la stringa di connessione e di esporre l'ID utente e la password.

Si consiglia di assicurarsi che l'identità del processo, ad esempio il pool di applicazioni, nel quale viene eseguito ASP.NET sia l'account predefinito del processo o un account utente limitato. Per ulteriori informazioni vedere Rappresentazione ASP.NET.

Negli scenari nei quali diversi siti Web si connettono a database SQL Server differenti, l'utilizzo della protezione integrata potrebbe rivelarsi non praticabile. Ad esempio, nei siti host Web, a ciascun cliente viene generalmente assegnato un diverso database SQL Server, ma tutti gli utenti utilizzano il server Web come utenti anonimi. In questi casi, è necessario connettersi a un'istanza di SQL Server utilizzando credenziali esplicite. Assicurarsi di memorizzare le credenziali in modo protetto, come descritto precedentemente in questo argomento nella sezione Stringhe di connessione.

Autorizzazioni del database SQL Server

È consigliabile assegnare i privilegi minimi all'ID utente utilizzato per la connessione ai database SQL Server utilizzati nell'applicazione.

Limitazione delle operazioni SQL

I controlli con associazione a dati possono supportare un'ampia gamma di operazioni sui dati tra cui la selezione, l'inserimento, l'eliminazione e l'aggiornamento di record nelle tabelle di dati. È consigliabile configurare i controlli dati in modo che possano eseguire solo le funzionalità indispensabili per la pagina o l'applicazione. Se ad esempio un controllo non deve consentire agli utenti l'eliminazione di dati, non includere una query di eliminazione con un controllo origine dati e non attivare l'eliminazione nel controllo.

SQL Server Express Edition

Per connettersi a un database di SQL Server Express Edition (file con estensione mdf), un processo deve disporre di autorizzazioni amministrative. In generale, i database SQL Server Express Edition non sono idonei alla realizzazione di siti Web di produzione, perché il processo ASP.NET non viene (e non dovrebbe essere) eseguito con privilegi amministrativi. Pertanto, utilizzare i database SQL Server Express Edition solo nei casi riportati di seguito:

Come database di verifica durante lo sviluppo dell'applicazione Web. Quando si è pronti a distribuire l'applicazione, è possibile trasferire il database da SQL Server Express Edition a un'istanza di produzione di SQL Server.
Se si esegue un sito Web in grado di utilizzare la rappresentazione ed è possibile controllare i privilegi dell'utente rappresentato. In pratica, questa strategia è attuabile solo se l'applicazione viene eseguita in una rete locale e non in un sito Web pubblico.
Memorizzare il file con estensione mdf nella cartella App_Data del sito in quanto il contenuto della cartella non verrà restituito a richieste HTTP dirette. È necessario inoltre eseguire il mapping dell'estensione mdf ad ASP.NET in IIS e al gestore HttpForbiddenHandler in ASP.NET utilizzando l'elemento riportato di seguito nel file Web.config del sito.
```
<httpHandlers>
  <add verb="*" path="*.mdf" type="System.Web.HttpForbiddenHandler" />
</httpHandlers>
```
Per informazioni sul mapping di un'estensione ad ASP.NET in IIS, vedere Procedura: registrare gestori HTTP.

Database Microsoft Access

I database Microsoft Access (file con estensione mdb) includono un numero minore di funzionalità di protezione rispetto ai database SQL Server. Non è consigliabile utilizzare database Access per i siti Web di produzione. Tuttavia, se è necessario utilizzare un file con estensione mdb come parte dell'applicazione Web, attenersi alle indicazioni riportate di seguito:

Memorizzare il file con estensione mdb nella cartella App_Data del sito in quanto il contenuto della cartella non verrà restituito a richieste HTTP dirette. È necessario inoltre eseguire il mapping dell'estensione mdb ad ASP.NET in IIS e al gestore HttpForbiddenHandler in ASP.NET utilizzando l'elemento riportato di seguito nel file Web.config del sito.
```
<httpHandlers>
  <add verb="*" path="*.mdb" type="System.Web.HttpForbiddenHandler" />
</httpHandlers>
```
Per informazioni sul mapping di un'estensione ad ASP.NET in IIS, vedere Procedura: registrare gestori HTTP.
Aggiungere le autorizzazioni appropriate per gli account utente autorizzati a leggere e scrivere dati nel file mdb. Se il sito Web supporta l'accesso anonimo, si tratta in genere dell'account utente ASPNET locale o dell'account NETWORK SERVICE. Poiché Access deve creare un file con estensione ldb per il supporto delle funzionalità di blocco, l'account utente deve disporre delle autorizzazioni di scrittura per la cartella contenente il file mdb.
Se il database è protetto da una password, non utilizzare il controllo AccessDataSource per stabilire la relativa connessione, perché il controllo AccessDataSource non supporta il passaggio di credenziali. Utilizzare, invece, il controllo SqlDataSource con il provider ODBC e passare le credenziali nella stringa di connessione. Assicurarsi di proteggere la stringa di connessione come descritto in questo argomento nella sezione Stringhe di connessione.

File XML

Se si memorizzano i dati in un file XML, inserire il file XML nella cartella App_Data del sito Web in quanto il contenuto della cartella non viene restituito in risposta a richieste HTTP dirette.

Protezione dagli input utente dannosi

Se l'applicazione accetta input dagli utenti, è necessario assicurarsi che l'input non contenga contenuti dannosi che possano compromettere l'applicazione. Gli input utente dannosi possono essere utilizzati per sferrare i seguenti attacchi:

Infiltrazione di script In questo tipo di attacco, lo script eseguibile viene inviato all'applicazione in modo che venga eseguito da altri utenti. In genere, in questo tipo di attacco lo script viene inviato a una pagina che lo memorizza in un database, in modo che un altro utente che visualizza i dati esegua inavvertitamente il codice.
Infiltrazione SQL In questo tipo di attacco, si tenta di compromettere il database e, potenzialmente, il computer nel quale il database è in esecuzione creando comandi SQL eseguiti in alternativa o in aggiunta ai comandi generati nell'applicazione.

Indicazioni generali

Per tutti gli input dell'utente, attenersi alle indicazioni riportate di seguito:

Quando possibile, utilizzare i controlli di convalida per limitare l'input dell'utente a valori accettabili.
Verificare sempre che il valore della proprietà IsValid sia true prima di eseguire il codice server. Un valore pari a false indica che uno o più controlli di convalida non ha superato le opportune verifiche.
Eseguire sempre una convalida sul lato server anche se il browser sta effettuando una convalida sul lato client per proteggersi dagli utenti che al contrario la ignorano. Specialmente nel caso di controlli CustomValidator; non utilizzare logica di convalida esclusivamente lato client.
Riconvalidare sempre l'input dell'utente al livello aziendale dell'applicazione. Non è consigliabile affidarsi al fatto che il processo di chiamata fornisca dati sicuri. Ad esempio, se si utilizza il controllo ObjectDataSource, aggiungere la convalida ridondante e la codifica nell'oggetto che esegue gli aggiornamenti dei dati.

Infiltrazione di script

Per evitare attacchi basati sull'infiltrazione di script, attenersi alle seguenti indicazioni:

Codificare l'input dell'utente con il metodo HtmlEncode, che trasforma l'HTML nella relativa rappresentazione testuale. Ad esempio, <b> diventa &ltb> e contribuisce a impedire che il codice venga eseguito in un browser.
Quando l'input dell'utente viene passato a una query mediante oggetti Parameter, aggiungere i gestori per gli eventi pre-query del controllo origine dati ed eseguire la codifica in tali eventi. Ad esempio, gestire l'evento Inserting del controllo SqlDataSource e, nell'evento, codificare il valore del parametro prima dell'esecuzione della query.
Se si utilizza il controllo GridView con i campi associati, impostare la proprietà HtmlEncode dell'oggetto BoundField su true. In questo modo, il controllo GridView codifica l'input dell'utente quando la riga è in modalità di modifica.
Per i controlli che possono essere utilizzati in modalità di modifica, è consigliabile utilizzare i modelli. Ad esempio, i controlli GridView, DetailsView, FormView, DataList e Login possono visualizzare caselle di testo modificabili. Tuttavia, tranne per il controllo GridView (vedere il punto precedente), i controlli non convalidano o codificano in HTML automaticamente l'input dell'utente. Pertanto, è consigliabile creare dei modelli per questi controlli, includere nel modello un controllo di convalida dell'immissione, ad esempio un controllo TextBox, e aggiungere un controllo di convalida. Inoltre, quando si estrae il valore del controllo, è opportuno codificarlo.

Infiltrazione SQL

Per evitare attacchi basati sull'infiltrazione SQL, attenersi alle seguenti indicazioni:

Non creare comandi SQL concatenando stringhe, specialmente quelle che includono l'input degli utenti. Utilizzare, invece, query con parametri o stored procedure.
Se si crea una query con parametri, utilizzare gli oggetti Parameter per stabilire i valori dei parametri. Per ulteriori informazioni, vedere Utilizzo dei parametri con il controllo SqlDataSource e Utilizzo di parametri con controlli origine dati.

Crittografia dei dati sullo stato di visualizzazione

Per i controlli con associazione a dati, come il controllo GridView, talvolta è necessaria la persistenza di informazioni considerate riservate. Ad esempio, il controllo GridView può gestire un elenco di chiavi nella proprietà DataKeys, anche se queste informazioni non vengono visualizzate. Tra i round trip, il controllo memorizza le informazioni nello stato di visualizzazione.

Le informazioni sullo stato di visualizzazione vengono codificate e memorizzate insieme al contenuto della pagina e potrebbero essere decodificate ed esposte a un'origine non desiderata. Se è necessario memorizzare informazioni riservate nello stato di visualizzazione, è possibile richiedere che nella pagina vengano crittografati i dati sullo stato di visualizzazione. Per crittografare i dati, impostare la proprietà ViewStateEncryptionMode della pagina su true.

Memorizzazione nella cache

È consigliabile evitare di memorizzare informazioni riservate nell'oggetto Cache quando la rappresentazione del client è attivata e i risultati dell'origine dati vengono recuperati in base all'identità del client. Se la memorizzazione nella cache è attivata, i dati memorizzati nella cache per un singolo utente possono essere visualizzati da tutti gli utenti ed è possibile che le informazioni riservate vengano esposte a un'origine non desiderata. La rappresentazione del client viene attivata quando l'attributo impersonate dell'elemento di configurazione identity è impostato su true e l'identificazione anonima è disattivata per l'applicazione sul server Web.

Condividi tramite