4 pagine in totale: <<Indietro 1 [2] 3 4 Avanti >>
Protezione del database
La maggior parte delle applicazioni ASP.NET è di tipo "data centric", ovvero incentrata principalmente sull'accesso a dati immagazzinati in una sorgente, tipicamente un database relazionale come SQL Server.
In questi scenari i dati costituiscono il cuore dell'applicazione, per cui è necessario preservarne l'integrità con particolare cura ed attenzione, impedendo l'accesso ad utenti non autorizzati.
Per proteggere la propria base di dati è opportuno seguire alcuni accorgimenti, elencati schematicamente di seguito.
- Evitare l'accesso diretto al file dei dati, non esponendo SQL Server direttamente sul Web e inserendo i file dei dati (sorgente dati XML o testuale, file .mdb di MS Access, file .mdf e .ldf di SQL Server Express Edition, ecc.) nella cartella App_Data (protetta in modo nativo).
- Se il server database è esposto sul Web, applicare tutte le limitazioni possibili quali consentire l'accesso solo da un determinato gruppo di indirizzi IP, non utilizzare le porte predefinite, ecc.
- Rendere sicura la stringa di connessione al database, evitando di dichiararla all'interno delle pagine e salvandola in modo cifrato nel file di configurazione (vedi "Come utilizzare la configurazione protetta").
- Eseguire in IIS il mapping dei file con estensioni corrispondenti a sorgenti dati (.xml, .mdf, .mdb, ecc.) ad ASP.NET, specificando per ciascuna estensione il gestore HttpForbiddenHandler, in modo analogo a quanto riportato nell'esempio seguente:
<httpHandlers>
<add
verb="*"
path="*.mdf"
type="System.Web.HttpForbiddenHandler" />
</httpHandlers>
- Evitare di salvare dati riservati nell'oggetto Cache se l'attributo impersonate dell'elemento identity nel web.config è impostato a true e l'identificazione anonima è disattivata in IIS, in quanto le informazioni relative ad un singolo utente potrebbero essere visualizzate da altri utenti.
- Validare sempre l'input dell'utente (vedi anche il paragrafo relativa a XSS nella prima parte dell'articolo e la parte riguardante SQL Injection).
- Non costruire istruzioni SQL concatenando stringhe, ma utilizzando query parametriche o stored procedure e impostando i valori tramite la collection Parameters (vedi il paragrafo "Protezione da SQL Injection").
- Assegnare i privilegi minimi all'utente utilizzato per la connessione al database (vedi anche il paragrafo "Applicare i privilegi minimi necessari").
- Limitare le operazioni SQL definite per i controlli data-bound a quanto strettamente necessario all'applicazione o alla singola pagina. Se ad esempio un controllo è preposto esclusivamente alla visualizzazione dei dati, non specificare le query di inserimento, modifica e eliminazione disattivando le operazioni non necessarie nel controllo.
- Se si utilizza il controllo GridView, quando possibile impostare la proprietà HtmlEncode dell'oggetto BoundField al valore true, così da codificare l'input dell'utente in fase di modifica.
- Se si utilizzano altri controlli che supportano la modifica (DetailsView, FormView, ecc.), utilizzare template che contengano anche controlli di validazione dell'input fornito dall'utente e codificare (HtmlEncode) il valore estratto dal controllo prima di utilizzarlo nella query sul database.
- Qualora lo stato della pagina dovesse contenere informazioni sensibili per gestire la visualizzazione dei dati (per esempio, le chiavi primarie di una tabella) è opportuno abilitare la crittazione impostando ViewStateEncryptionMode al valore true.
Come scegliere la modalità di accesso a SQL Server
Come è noto, esistono diverse modalità di accesso a SQL Server, ognuna delle quali presenta vantaggi e svantaggi:
- utilizzando la protezione integrata di Windows: ovvero le credenziali dell'utente vengono passate direttamente a SQL Server; questa modalità è disponibile solo se SQL Server e IIS sono in esecuzione sulla stessa macchina;
- eseguendo il mapping dell'identità di ASP.NET in un utente di dominio, quindi accedendo a SQL Server con le credenziali di tale utente; questa soluzione è ottimale per accessi anonimi se SQL Server e IIS risiedono in macchine diverse;
- accedendo con l'identità locale di ASP.NET (ASPNET su Windows 2000 e NETWORK SERVICE su Windows 2003); questa soluzione è adatta per l'accesso anonimo;
- passando esplicitamente le credenziali (username e password) in una stringa di connessione. Questa è l'opzione meno sicura; in questo caso è opportuno utilizzare la configurazione protetta per cifrare la stringa di connessione (vedi paragrafo successivo), evitare l'uso di utenti con elevati privilegi (ad esempio "sa"), impostare sempre una password complessa e utilizzare i gruppi per assegnare diritti specifici a tabelle, colonne e stored procedure (vedi paragrafo "Applicare i privilegi minimi necessari").
Come utilizzare la configurazione protetta
La configurazione protetta permette di migliorare la protezione di un'applicazione tramite la crittografia delle informazioni riservate memorizzate in un file Web.config. Come detto precedentemente, è opportuno utilizzare questa opzione ad esempio per cifrare la stringa di connessione al database.
Supponiamo di avere un'applicazione Web con nome (alias) "MyWebSite" con il seguente file di configurazione:
<?xml version="1.0"?>
<configuration>
<connectionStrings>
<clear />
<add
name="SqlServer"
connectionString="Data Source=localhost;Initial Catalog=MyDB;Integrated Security=True"
providerName="System.Data.SqlClient" />
</connectionStrings>
</configuration>
Abbiamo a disposizione due modalità per proteggere la sezione "connectionStrings":
- in modo programmatico, utilizzando le API relative alla configurazione;
- da riga di comando, sfruttando l'utility aspnet_regiis.exe.
Utilizzo della configurazione protetta via codice
La pagina d'esempio allegata all'articolo (file ProtezioneConnectionStringDemo.aspx con il Web.config relativo) mostra nel dettaglio come proteggere e sproteggere una sezione di configurazione. Di seguito riportiamo la parte di codice più significativa per la crittazione.
// Apro il file di configurazione (Web.config)
Configuration config = WebConfigurationManager.OpenWebConfiguration("~");
// Recupero la sezione <connectionStrings>
ConnectionStringsSection section = config.GetSection("connectionStrings") as ConnectionStringsSection;
// Se non è criptata, la cripto
if (!section.SectionInformation.IsProtected)
section.SectionInformation.ProtectSection("DataProtectionConfigurationProvider");
// Salvo il file di configurazione
config.Save();
4 pagine in totale: <<Indietro 1 [2] 3 4 Avanti >>
Attenzione: Questo articolo contiene un allegato
Contenuti dell'articolo
- Pagina 1
- Pagina 2
- Pagina 3
- Pagina 4
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Utilità
Stampa 
Download
