Protezione di pagine Web part

Articolo
10/22/2014

Aggiornamento: novembre 2007

Web part è la nuova funzionalità di ASP.NET che offre agli utenti finali la possibilità di modificare o personalizzare le pagine Web. Sebbene la disponibilità di pagine Web personalizzate risulti molto utile e vantaggiosa per gli utenti delle applicazioni Web, comporta implicazioni in termini di protezione di cui gli sviluppatori devono essere a conoscenza.

Problemi relativi alla protezione di Web part

Poiché Web part è una funzionalità di ASP.NET e i controlli Web part vengono estesi ai controlli server ASP.NET, le pagine Web part presentano gli stessi rischi delle pagine ASP.NET. Un'applicazione Web con pagine che utilizzano controlli Web part è in realtà un tipo particolare di applicazione ASP.NET; pertanto, un'applicazione che utilizza Web part può essere eseguita agli stessi livelli di attendibilità di una normale applicazione ASP.NET. Per informazioni generali sulla protezione di siti Web ASP.NET, vedere Sicurezza dei siti Web ASP.NET. La funzionalità Web part presenta tuttavia alcuni problemi di protezione aggiuntivi rispetto alle comuni pagine ASP.NET, che vengono descritti nelle seguenti sezioni.

Importazione di dati di controlli

La funzione di importazione di Web part è quella che presenta i maggiori rischi relativi alla protezione, in quanto consente agli utenti di importare un file di descrizione XML contenente dati relativi a stato e proprietà di un controllo server (il file assembly del controllo deve essere già disponibile sul server Web). Sebbene l'importazione di dati per i controlli consenta agli utenti di condividere i dati e configurare facilmente controlli complessi, esiste il rischio intrinseco che il file di descrizione contenga dati dannosi. Ad esempio, se come valore di una proprietà di tipo stringa nel file di descrizione è stato specificato codice di script potenzialmente dannoso, tale script potrebbe essere eseguito quando un utente importa il file di descrizione e aggiunge il controllo server a cui si fa riferimento a una pagina Web. Per limitare il più possibile il rischio di importare file di descrizione contenenti dati dannosi, è necessario codificare sempre i dati delle proprietà per i controlli server con proprietà di tipo stringa. Un altro rischio è costituito dall'importazione di tipi mediante file di descrizione (vedere File di descrizione del controllo Web part). Un utente malintenzionato potrebbe inoltrare delle richieste per caricare una grande numero di assembly in AppDomain, con conseguente consumo eccessivo di memoria. Per evitare i rischi associati all'importazione, è possibile disattivare la funzione semplicemente non utilizzando il controllo server che la implementa oppure è possibile limitare gli utenti che hanno accesso al controllo. Ad esempio, è possibile utilizzare la gestione dei ruoli e inserire nella pagina l'oggetto ImportCatalogPart a livello di codice solo per gli utenti che dispongono di un ruolo amministratore. Per ulteriori informazioni sul controllo, vedere l'argomento di riferimento per la classe ImportCatalogPart.

Esportazione di dati di controlli

La funzione di esportazione presenta quasi lo stesso potenziale in termini di rischio rispetto all'importazione, poiché potrebbe causare la compromissione di dati sensibili. L'esportazione consente agli utenti di salvare i dati relativi a proprietà e stato per un determinato controllo in un file di descrizione XML, ossia lo stesso file che può essere importato utilizzando la funzione di importazione. In questo caso il rischio principale consiste nel fatto che gli utenti potrebbero esportare dati sensibili dall'applicazione nel file di descrizione, che è un semplice file di testo leggibile da chiunque disponga delle autorizzazioni adeguate. L'esportazione è disattivata per impostazione predefinita in ASP.NET, quindi se questa funzione non è necessaria, può essere ignorata. Questa è indubbiamente la scelta più sicura.

Se si desidera attivare l'esportazione, è opportuno conoscere le opzioni disponibili per determinare quali proprietà è possibile esportare. Quando si crea un controllo WebPart o server che verrà utilizzato in un'area WebPartZone, per ciascuna proprietà pubblica che si desidera rendere esportabile, è possibile aggiungere l'attributo di metadati Personalizable. In questo modo, se si attiva l'esportazione, è possibile esportare la proprietà e verrà visualizzato un messaggio che segnala all'utente che i dati verranno esportati. Uno dei parametri dell'attributo Personalizable è IsSensitive. Questo parametro booleano è utile se si desidera rendere esportabile una proprietà solo in determinate situazioni. Per ulteriori informazioni e un esempio, vedere l'argomento di riferimento per la proprietà ExportMode.

Cenni preliminari sulla personalizzazione

La personalizzazione di Web part consente agli utenti di modificare le pagine Web per adattarle alle proprie esigenze e salvarne le impostazioni in un sistema di archiviazione a lungo termine, in modo che le impostazioni delle pagine personalizzate vengano mantenute tra una sessione del browser e un'altra. Poiché la maggior parte delle funzionalità Web part richiedono la personalizzazione, questa funzione è attivata per impostazione predefinita nei siti Web ASP.NET, benché venga utilizzata solo per le pagine che contengono controlli Web part. La personalizzazione è una funzione molto potente e comporta perciò anche dei rischi. Gli utenti possono infatti modificare il layout, l'aspetto e persino il contenuto e i controlli di una pagina Web. Poiché i dati di personalizzazione vengono memorizzati in un database e utilizzati per la visualizzazione delle pagine, gli utenti hanno la possibilità di danneggiare in vario modo i dati relativi al contenuto di un sito. Gli utenti con accesso all'ambito di personalizzazione condiviso possono persino modificare il modo in cui le pagine vengono visualizzate per tutti gli utenti.

Se una determinata pagina utilizza funzioni Web part ma non richiede alcuna personalizzazione (ad esempio una delle pagine comuni di un portale), è consigliabile disattivare la personalizzazione per migliorare le prestazioni e ridurre l'esposizione del sito a eventuali rischi di protezione. Per ulteriori informazioni, vedere Procedura: disattivare la personalizzazione di Web part.

Autenticazione di utenti per la personalizzazione

La personalizzazione richiede l'autenticazione degli utenti. Non è infatti possibile attivare la personalizzazione per gli utenti anonimi. Ciò implica che per disporre di tutte le funzionalità di personalizzazione e Web part, il sito Web deve utilizzare l'autenticazione Windows o basata su form. Per informazioni sulle opzioni di autenticazione, vedere Suggerimenti di base sulla sicurezza delle applicazioni Web ASP.NET. Per impostare un sito utilizzando la nuova funzionalità di appartenenza, che utilizza l'autenticazione basata su form, vedere Gestione di utenti tramite l'appartenenza.

Concessione dell'accesso minimo alla personalizzazione condivisa

Le modifiche apportate mediante la personalizzazione di Web part interessano sempre un determinato numero o ambito di utenti. Le modifiche apportate all'interno di un ambito utente sono visibili solo all'autore, mentre le modifiche apportate in ambito condiviso sono visibili a tutti gli utenti. L'ambito di personalizzazione condiviso consente agli utenti con ruolo di responsabile o amministratore di apportare modifiche a una pagina utilizzata da tutti gli utenti di un sito. Per impostazione predefinita, l'accesso all'ambito condiviso è negato a tutti gli utenti. L'accesso deve essere concesso in modo esplicito in un file di configurazione del sito Web solo ad utenti selezionati. Per informazioni dettagliate, vedere Procedura: attivare la personalizzazione condivisa di pagine Web part.

Utilizzo dei controlli verificati e attendibili

Poiché le funzionalità Web part sono molto potenti, ad esempio consentono di aggiungere nuovi controlli server a una pagina, gli sviluppatori devono selezionare con attenzione i controlli server utilizzati in un'applicazione Web part. I controlli server, soprattutto quelli di terze parti, devono essere attentamente esaminati e verificati per garantirne l'attendibilità per l'uso in applicazioni Web part. Si supponga ad esempio che un controllo server sia stato progettato in modo inadeguato e risulti inefficiente in termini di uso della memoria. Se il controllo viene aggiunto a un catalogo Web part, gli utenti possono aggiungerlo a una pagina Web. E, poiché in una pagina si possono avere più istanze di un controllo presente in un catalogo, un utente potrebbe aggiungere più volte il controllo inefficiente e provocare di conseguenza un attacco di tipo Denial of Service quando la pagina tenta di elaborare le varie istanze del controllo. Per ulteriori informazioni sui cataloghi Web part, vedere l'argomento di riferimento per la classe CatalogPart.

Utilizzo di autorizzazioni e filtri sui controlli

È disponibile una funzione di Web part che consente di impostare e verificare il livello di autorizzazione dei controlli server utilizzati per creare l'interfaccia utente delle pagine Web part. Se un controllo viene autorizzato in base ai criteri impostati, verrà visualizzato sulla pagina, mentre se il controllo è stato autorizzato parzialmente o non è stato autorizzato affatto, sarà possibile modificarne l'aspetto di conseguenza oppure nasconderlo. Si supponga ad esempio che un utente sia designato come amministratore e che si desideri che un determinato controllo server sia visibile solo all'amministratore. Mediante le funzioni di autorizzazione e di filtro di Web part è possibile fare in modo che il controllo venga visualizzato solo per un amministratore designato e nascosto per tutti gli altri utenti. I meccanismi principali per l'utilizzo di autorizzazioni e filtri sono la proprietà AuthorizationFilter della classe WebPart e i metodi IsAuthorized e OnAuthorizeWebPart della classe WebPartManager.

Codifica delle proprietà di tipo stringa nella modifica dei controlli

Una funzione esclusiva di Web part consente agli utenti finali di impostare la modalità di modifica per una pagina e quindi di modificare il layout, l'aspetto, il comportamento e i valori delle proprietà personalizzabili di un controllo server. Questa operazione presenta alcuni rischi, poiché un utente malintenzionato potrebbe inserire dati non appropriati o tentare un attacco basato sull'infiltrazione di script modificando proprietà di tipo stringa. Per motivi di protezione, se si creano controlli EditorPart personalizzati per modificare controlli server e se una proprietà personalizzabile di un dato controllo server è di tipo stringa o utilizza la conversione delle stringhe, il controllo EditorPart deve codificare i dati di stringa prima di assegnarli alla proprietà. Per un esempio, vedere la documentazione di riferimento del metodo HtmlEncode.