Proteggere le informazioni di connessione
La protezione dell'accesso all'origine dati è uno dei principali obiettivi da raggiungere quando si imposta la sicurezza di un'applicazione. Una stringa di connessione presenta una potenziale vulnerabilità se non è protetta. Se le informazioni di connessione vengono archiviate in testo normale o mantenute nella memoria, si rischia di compromettere l'intero sistema. Le stringhe di connessione incorporate nel codice sorgente possono essere lette usando il Ildasm.exe (disassemblatore IL) per visualizzare common intermediate language (CIL) in un assembly compilato.
Le vulnerabilità di sicurezza che riguardano le stringhe di connessione possono presentarsi in base al tipo di autenticazione usato, alla modalità con cui le stringhe di connessione vengono mantenute nella memoria e su disco e alle tecniche usate per crearle in fase di esecuzione.
Nota
Microsoft consiglia di usare il flusso di autenticazione più sicuro disponibile. Se ci si connette ad Azure SQL, le Identità gestite per le risorse Azure sono il metodo di autenticazione consigliato.
Usa autenticazione di Windows
Per limitare l'accesso all'origine dati, è necessario proteggere le informazioni di connessione quali, ad esempio, identificatore utente, password e nome dell'origine dati. Per evitare di esporre le informazioni degli utenti, si consiglia di usare l'autenticazione di Windows (definita anche sicurezza integrata) per le origini dati in locale. (Tuttavia, quando ci si connette ad Azure SQL, è necessario usare le Identità gestite per risorse Azure). L'autenticazione di Windows è specificata in una stringa di connessione con le parole chiave Integrated Security o Trusted_Connection, eliminando la necessità di usare un ID utente e una password. Tramite l'autenticazione di Windows, gli utenti vengono autenticati da Windows e l'accesso alle risorse di server e database viene determinato concedendo autorizzazioni a utenti e gruppi di Windows.
Nei casi in cui non sia possibile usare l'autenticazione di Windows, è necessario prestare maggiore attenzione perché le credenziali utente sono esposte nella stringa di connessione. Nelle applicazioni ASP.NET è possibile configurare un account di Windows come identità fissa usata per le connessioni a database e ad altre risorse di rete. La rappresentazione viene abilitata nell'elemento identità nel file web.config e vengono specificati un nome utente e una password.
<identity impersonate="true"
userName="MyDomain\UserAccount"
password="*****" />
L'account con identità fissa deve avere privilegi limitati che includono solo le autorizzazioni necessarie nel database. È inoltre necessario crittografare il file di configurazione in modo da non esporre il nome utente e la password in testo non crittografato.
Importante
Microsoft consiglia di usare il flusso di autenticazione più sicuro disponibile. Il flusso di autenticazione descritto in questa procedura richiede un livello di attendibilità molto elevato nell'applicazione e comporta rischi che non sono presenti in altri flussi. Si consiglia di usare questo flusso solo quando altri flussi più sicuri, come le identità gestite, non sono validi.
Non usare file Universal Data Link (UDL)
Evitare di archiviare le stringhe di connessione per OleDbConnection in un file di collegamento dati universale (UDL). I file UDL vengono archiviati in testo non crittografato e non possono essere crittografati. Poiché per l'applicazione si tratta di una risorsa esterna basata su file, un file UDL non può essere protetto né crittografato tramite .NET Framework.
Evitare attacchi injection con i compilatori di stringhe di connessione
Un attacco injection alle stringhe di connessione può verificarsi quando si usa la concatenazione dinamica di stringhe per compilare stringhe di connessione basate sull'input dell'utente. Se l'input dell'utente non viene convalidato e il testo o i caratteri dannosi non vengono convertiti in caratteri di escape, un utente non autorizzato potrebbe accedere a dati sensibili o ad altre risorse del server. Per risolvere questo problema, in ADO.NET 2.0 sono state introdotte nuove classi di compilatori di stringhe di connessione per convalidare la sintassi delle stringhe e assicurarsi che non vengano inseriti parametri aggiuntivi. Per altre informazioni, vedere Compilatori di stringhe di connessione.
Utilizzare Persist Security Info=False.
Il valore predefinito per Persist Security Info è false; si consiglia di usare questo valore in tutte le stringhe di connessione. Se si imposta Persist Security Info su true o yes, è possibile che da una connessione aperta si ottengano informazioni sensibili, tra cui l'ID utente e la password. Se si imposta Persist Security Info su false o no, le informazioni di sicurezza vengono eliminate dopo essere state usate per aprire la connessione. In questo modo un'origine non attendibile non ha accesso alle informazioni sensibili per la sicurezza.
Crittografare i file di configurazione
È anche possibile archiviare le stringhe di connessione in file di configurazione, eliminando la necessità di incorporarle nel codice dell'applicazione. I file di configurazione sono file XML standard per i quali .NET Framework ha definito un set comune di elementi. Le stringhe di connessione nei file di configurazione vengono in genere archiviate all'interno dell'elemento <connectionStrings> in app.config per le applicazioni Windows o nel file web.config per le applicazioni ASP.NET. Per altre informazioni sulle nozioni di base sull'archiviazione, il recupero e la crittografia delle stringhe di connessione dai file di configurazione, vedere Stringhe di connessione e file di configurazione.