Protezione di controlli server personalizzati

Articolo
10/22/2014

Aggiornamento: novembre 2007

I controlli server personalizzati sono un modo di estendere la funzionalità dei controlli server Web ASP.NET. Le linee guida di sicurezza di base seguenti sono fornite per gli utenti e gli sviluppatori di controlli server personalizzati. Per ulteriori informazioni sulla creazione di controlli server personalizzati, vedere Sviluppo di controlli server ASP.NET personalizzati.

Un IDE quale Microsoft Visual Studio 2005 semplifica l'utilizzo e lo sviluppo di controlli personalizzati. Tuttavia, le linee guida di sicurezza elencate di seguito sono applicabili indipendentemente dal tipo di IDE utilizzato.

Per informazioni generali sulla sicurezza di applicazioni Web ASP.NET, vedere Protezione delle applicazioni Web ASP.NET.

Linee guida per gli utenti di controlli server personalizzati

Ci sono diversi modi di numerosi per utilizzare controlli server personalizzati in un'applicazione Web. È ad esempio possibile includere i file del codice sorgente direttamente nella cartella App_Code, utilizzare i controlli da una Global Assembly Cache oppure utilizzare componenti di comunità installati tramite un programma di installazione automatizzato ad esempio Visual Studio Content Installer. In tutti i casi, è necessario prendere le misure adeguate per evitare di importare codice dannoso o codice che ha un impatto indesiderato, seppur involontario, sull'IDE e sul server in cui si trovano i componenti.

Di seguito sono riportate alcune linee guida di sicurezza da prendere in considerazione come utente di controlli server personalizzati. Non si tratta di un elenco completo, ma è comunque un punto di partenza per l'analisi:

Non utilizzare codice con cui non si ha familiarità o di cui non si comprendono le implicazioni relative alla sicurezza. Per i componenti di comunità, è consigliabile leggere le informazioni disponibili dell'autore e determinare se i componenti sono firmati.
Non considerare solo la sicurezza in fase di esecuzione del controllo ma anche la sicurezza in fase di progettazione. Per ulteriori informazioni, vedere Protezione dei componenti della finestra di progettazione dei controlli personalizzati.
Se possibile, utilizzare controlli personalizzati in assembly con nome sicuro ed editori attendibili. Per ulteriori informazioni, vedere Procedura: determinare il nome completo di un assembly.
Eseguire le applicazioni Web ASP.NET che includono i controlli importati in un account con privilegi minimi. Per ulteriori informazioni sull'esecuzione di processi ASP.NET con un'identità con autorizzazioni minime, vedere Configurazione dell'identità dei processi ASP.NET. In un IDE come Visual Studio 2005 o Visual Web Developer Express eseguire le applicazioni come utente normale e non in qualità di amministratore, a meno che non sia necessario eseguire attività amministrative.
Analizzare la protezione del sistema operativo e degli elenchi di controllo di accesso Windows nel server in cui si trovano i controlli server personalizzati. È ad esempio necessario assicurarsi che il processo ASP.NET venga eseguito con un'identità con le autorizzazioni minime per eseguire l'applicazione. In questo modo, un'eventuale violazione della sicurezza da parte di un controllo server personalizzato avrà un impatto minimo sulle altre applicazioni host. Per ulteriori informazioni, vedere Configurazione dell'identità dei processi ASP.NET. Inoltre, analizzare le autorizzazioni dei controlli server personalizzati ed assicurarsi che siano conformi alle autorizzazioni per file e cartelle che deve possedere l'identità dell'applicazione Web ASP.NET per funzionare correttamente. Per ulteriori informazioni, vedere Elenchi di controllo di accesso (ACL, Access Control List) ASP.NET necessari.
Utilizzare la sicurezza dall'accesso di codice per limitare le risorse a cui l'applicazione Web, tramite i controlli server personalizzati, può accedere e le operazioni privilegiate che tale applicazione può eseguire. Per ulteriori informazioni, vedere Protezione dall'accesso di codice ASP.NET.
Utilizzare lo strumento .NET Framework Configuration (Mscorcfg.msc) per gestire e configurare assembly nella Global Assembly Cache e regolare i criteri di sicurezza dall'accesso di codice. Poiché Mscorcfg.msc è dedicato agli amministratori avanzati per l'esecuzione di attività relative alla configurazione di applicazioni, collaborare con l'amministratore di sistema per determinare se l'utilizzo di tale strumento è appropriato nella situazione specifica. Per ulteriori informazioni, vedere Strumento .NET Framework Configuration (Mscorcfg.msc).

Linee guida per gli sviluppatori di controlli server personalizzati

In qualità di sviluppatore di controlli personalizzati, è necessario seguire le procedure consigliate generali per la sicurezza nei controlli e nelle pagine di applicazioni ASP.NET e in .NET Framework. In molti casi, gli utenti dei controlli server personalizzati potrebbero non essere consapevoli dei dettagli dell'implementazione o delle implicazioni in materia di sicurezza. È necessario pianificare in questo senso seguendo convenzioni di sicurezza stabilite e manifestando chiaramente tutte le autorizzazioni necessarie per il funzionamento dei componenti. Per analizzare i problemi di sicurezza generali e le relative risoluzioni per le applicazioni Web, vedere Sicurezza dei siti Web ASP.NET, la Guida per gli sviluppatori di .NET Framework Concetti principali sulla protezione e gli argomenti dedicati alla sicurezza nel sito Web Patterns and Practices (informazioni in lingua inglese).

Dopo aver progettato e implementato i controlli server Web personalizzati, è necessario decidere come fornire i componenti agli utenti. Due metodi comuni sono mediante un assembly o mediante un componente di comunità. Se si forniscono i componenti mediante un assembly, è necessario firmare l'assembly, noto come assembly con nome sicuro. Attraverso la firma si conferisce all'assembly un'identità univoca che altri software possono utilizzare per identificare e farvi riferimento in modo esplicito. Ci sono anche altri vantaggi, come illustrato in dettaglio in Programmazione con gli assembly.

Se i componenti vengono forniti come componenti di comunità con una procedura di installazione automatizzata, è necessario firmare i componenti mediante la crittografia. La firma consente di verificare che i dati provengono da una determinata persona attraverso la creazione di una firma digitale univoca per tale persona. Un modo di creare componenti di comunità per l'utilizzo con Visual Studio 2005 consiste nell'utilizzare Visual Studio Content Installer e creare i file con estensione vsi che possono essere firmati.

Di seguito sono riportate alcune linee guida di sicurezza da prendere in considerazione quando si sviluppano componenti del controllo server personalizzato. Non si tratta di un elenco completo, ma è comunque un punto di partenza per l'analisi:

Insieme ai controlli server personalizzati fornire istruzioni sull'utilizzo e sulle risorse e le autorizzazioni necessarie per un funzionamento corretto dei controlli.
Applicare una firma digitale ai componenti. Se si inserisce il controllo personalizzato in un assembly, firmare l'assembly con un nome sicuro. Per ulteriori informazioni, vedere Creazione e utilizzo degli assembly con nome sicuro. Se si utilizza un programma di installazione automatizzato quale Visual Studio Content Installer, è comunque necessario firmare i componenti.
Seguire le procedure consigliate per la gestione delle eccezioni nel codice. Per ulteriori informazioni, vedere il capitolo 10 nel sito Web Patterns and Practices (informazioni in lingua inglese).
Se si desidera che gli sviluppatori della pagina possano aggiungere i controlli personalizzati alla casella degli strumenti della finestra di progettazione visiva, trascinarli sull'area di progettazione e accedere alle proprietà e agli eventi corrispondenti nel visualizzatore proprietà, è necessario prendere in considerazione la sicurezza in fase di progettazione oltre che alla sicurezza in fase di esecuzione. Per ulteriori informazioni, vedere Protezione dei componenti della finestra di progettazione dei controlli personalizzati.
Conoscere le minacce principali relative a controlli e pagine di applicazioni Web, inclusi l'inserimento di codice, la divulgazione di informazioni, l'assunzione del controllo della sessione, lo spoofing di identità, la manipolazione dei parametri e attacchi eavesdropping di rete. A questo fine, eseguire un'analisi di classificazione dei rischi dei componenti prima di distribuirli. Per ulteriori informazioni, vedere l'argomento Threat Modeling Web Applications nel sito Web Patterns and Practices (informazioni in lingua inglese).