Sicurezza dall'accesso di codice per applicazioni ASP.NET 4
La sicurezza dall'accesso di codice è il meccanismo di sicurezza di .NET Framework ("sandbox") utilizzato da ASP.NET per imporre vincoli alla possibilità di eseguire codice. La sicurezza dall'accesso di codice è stata implementata in ASP.NET a partire dalla versione 1.1, attraverso il concetto dei livelli di attendibilità.
In questo argomento viene descritto il funzionamento della sicurezza dall'accesso di codice in ASP.NET 4, con particolare attenzione alle modifiche rispetto alle versioni precedenti. Se non si conosce ASP.NET, è probabile che le modifiche non siano di interesse. Tuttavia, in questo argomento vengono fornite informazioni sul funzionamento della sicurezza dall'accesso di codice nella versione corrente di ASP.NET che possono interessare la progettazione di nuove applicazioni.
In questo argomento vengono illustrati i seguenti concetti:
Motivi per cui i livelli dei criteri di sicurezza dall'accesso di codice non vengono più utilizzati e come ciò influisce sugli scenari tipici, ad esempio l'abilitazione dell'esecuzione di applicazioni ASP.NET parzialmente attendibili da condivisioni UNC.
Modalità di personalizzazione del comportamento della sicurezza dall'accesso di codice in ASP.NET 4.
Problemi di compatibilità nell'abilitazione di codice attendibile per l'utilizzo con la sicurezza dall'accesso di codice in ASP.NET 4.
Questo argomento presuppone la comprensione della sicurezza dall'accesso di codice di .NET Framework e dei livelli di attendibilità ASP.NET. Per informazioni su questi argomenti, vedere i documenti seguenti:
Serie di blog sui criteri di sicurezza dall'accesso di codice e CLR, di Shawn Farkas
Di seguito sono riportate le informazioni contenute nel presente argomento:
Cenni preliminari sul modello di sicurezza dall'accesso di codice di ASP.NET 4
Domini dell'applicazione omogenei
APTCA condizionale
Trasparenza per la sicurezza e relativo funzionamento in ASP.NET 4
Cenni preliminari sul modello di sicurezza dall'accesso di codice di ASP.NET 4
In ASP.NET 4 sono state apportate diverse modifiche fondamentali alla sicurezza dall'accesso di codice rispetto ad ASP.NET 3.5 e alle versioni precedenti, incluse le seguenti:
Per impostazione predefinita, i domini dell'applicazione parzialmente attendibili di ASP.NET 4 sono omogenei. Ciò comporta un set limitato di set di autorizzazioni possibili per il codice in esecuzione in un dominio dell'applicazione parzialmente attendibile. Ne consegue inoltre che il limite di attendibilità del dominio dell'applicazione è esso stesso associato a un set di concessioni di attendibilità parziale. Nei domini dell'applicazione omogenei i criteri di sicurezza non si intersecano con i criteri di sicurezza dall'accesso di codice a livello di computer, utente o azienda.
Nota
Il nuovo modello di dominio dell'applicazione omogeneo richiede un set di file dei criteri di attendibilità ASP.NET dichiarativi leggermente diverso rispetto ai file di criteri utilizzati nelle versioni precedenti di ASP.NET.Di conseguenza, una volta installato ASP.NET 4, nel computer saranno presenti due set di file di criteri parzialmente attendibili ASP.NET.Un set è utilizzato dal nuovo modello di sicurezza dall'accesso di codice, e l'altro viene utilizzato quando si configurano le applicazioni per l'utilizzo del modello di sicurezza dall'accesso di codice precedente a ASP.NET 4.
Nelle versioni precedenti di ASP.NET l'attributo AspNetHostingPermission viene utilizzato in quasi tutte le classi pubbliche correlate a ASP.NET per evitare l'utilizzo di tipi ASP.NET in ambienti non Web parzialmente attendibili. Ad esempio, la presenza dell'attributo AspNetHostingPermission impedisce l'utilizzo della maggior parte delle classi ASP.NET in un'applicazione ClickOnce parzialmente attendibile. Per ulteriori informazioni sulla sicurezza dall'accesso di codice nelle applicazioni ClickOnce, vedere Sicurezza dall'accesso di codice per applicazioni ClickOnce. Anziché basarsi sull'attributo AspNetHostingPermission, in ASP.NET 4 viene utilizzata una tecnologia di sicurezza dall'accesso di codice diversa denominata APTCA condizionale (in base al tipo AllowPartiallyTrustedCallersAttribute) per ottenere lo stesso risultato. Di conseguenza, l'attributo AspNetHostingPermission è stato rimosso dalla maggior parte dei membri e dei tipi ASP.NET.
In ASP.NET 4 molti assembly di sistema sono stati aggiornati per l'utilizzo del modello di trasparenza per la sicurezza CLR. Il modello di trasparenza in ASP.NET 4 è molto simile a quello utilizzato in Silverlight. Per ulteriori informazioni sulla trasparenza del codice, vedere Codice SecurityTransparent.
Gli effetti di queste modifiche sono evidenti se si utilizzavano criteri di sicurezza dall'accesso di codice CLR personalizzati creati tramite strumenti come caspol.exe. Le modifiche influiranno anche su applicazioni Web parzialmente attendibili basate sugli assembly distribuiti in GAC per l'esecuzione di operazioni privilegiate, quando era attivo solo il codice .NET Framework o ASP.NET in uno stack di chiamate. Nelle sezioni seguenti vengono descritte le modifiche della sicurezza dall'accesso di codice.
Domini dell'applicazione omogenei
In questa sezione vengono descritti i domini dell'applicazione omogenei. Vengono illustrate le modifiche apportate al comportamento dalla versione 2.0 di ASP.NET che hanno avuto come risultato i domini dell'applicazione omogenei. Vengono inoltre illustrate le opzioni di compatibilità che è possibile impostare e le modifiche che è possibile apportare al codice per l'esecuzione in domini dell'applicazione omogenei.
Numero ridotto di set di autorizzazioni possibili
I domini dell'applicazione omogenei sono domini dell'applicazione parzialmente attendibili che definiscono un set di autorizzazioni condiviso per l'esecuzione di codice. In un dominio dell'applicazione omogeneo ospitato in ASP.NET 4 il codice che è possibile caricare è associato a uno di due set di autorizzazioni. Il codice viene eseguito con attendibilità totale (il codice della GAC viene eseguito sempre in attendibilità totale) o con il set di autorizzazioni di attendibilità parziale definito dall'impostazione trustLevel corrente. Per ulteriori informazioni, vedere Elemento trustLevel per securityPolicy (schema delle impostazioni ASP.NET).
Nota
L'attendibilità totale è l'impostazione predefinita per i domini dell'applicazione di ASP.NET.Il comportamento omogeneo in ASP.NET 4 viene applicato solo dopo l'impostazione dell'attributo name dell'elemento trustLevel su un valore diverso da Full.
Questo comportamento è diverso dalle applicazioni parzialmente attendibili nelle versioni precedenti di ASP.NET. Nelle versioni precedenti è possibile creare più set di autorizzazioni, ognuno con concessioni diverse e condizioni di appartenenza diverse. I domini dell'applicazione omogenei sono stati introdotti in .NET Framework 4 a causa della difficoltà nella gestione di scenari di autorizzazioni misti come questi. È difficile creare più set di autorizzazioni, ciascuno con livelli diversi di autorizzazioni, quindi provare che i diversi livelli di autorizzazioni vengono effettivamente applicati, dopo avere preso in considerazione tutte le condizioni in cui può essere eseguito il codice. Ad esempio, un codice può essere eseguito nella reflection, un codice ad attendibilità totale può eseguire altro codice ad attendibilità totale per conto di un chiamante parzialmente attendibile e così via. È necessario che il set di autorizzazioni tenga conto di tutte queste condizioni. I domini dell'applicazione omogenei semplificano notevolmente le decisioni di sicurezza dall'accesso di codice riducendo i risultati possibili. Il codice ha attendibilità totale oppure un solo set di autorizzazioni di attendibilità parziale ben definito. Per ASP.NET, il set di autorizzazioni di attendibilità parziale ben definito viene applicato a un livello di attendibilità ASP.NET specificato.
Esiste un terzo stato possibile per il codice che tenta il caricamento in un dominio dell'applicazione omogeneo che non è considerato un set di autorizzazioni separato da CLR. Si tratta del set di autorizzazioni vuoto, definito come set di autorizzazioni Nothing in tutti i file di configurazione di attendibilità parziale di ASP.NET. Il codice che restituisce il set di autorizzazioni Nothing viene considerato non caricabile. Di conseguenza, qualsiasi tentativo di caricare assembly con set di autorizzazioni Nothing impostato su un dominio dell'applicazione omogeneo restituisce un'eccezione SecurityException.
Solo per i criteri ASP.NET parzialmente attendibili
Il set di autorizzazioni di attendibilità parziale di un dominio dell'applicazione omogeneo viene stabilito solo dall'host responsabile della creazione del dominio dell'applicazione. In ASP.NET 4 ciò significa che il set di autorizzazioni di attendibilità parziale viene definito solo dal contenuto di un file di configurazione di attendibilità parziale presente nella sottodirectory CONFIG dell'installazione di .NET Framework. Per impostazione predefinita, le informazioni sui criteri ASP.NET per i domini dell'applicazione parzialmente attendibili di ASP.NET 4 non si sovrappongono più alle impostazioni dei criteri di sicurezza dall'accesso di codice dell'utente, del computer o dell'azienda.
Le informazioni sui criteri di sicurezza dall'accesso di codice, gestiti precedentemente dagli sviluppatori mediante strumenti come caspol.exe o lo strumento di configurazione MMC Mscorcfg.msc, non hanno più alcuna influenza sui domini dell'applicazione omogenei di ASP.NET 4. È possibile configurare ASP.NET per l'utilizzo del modello di sicurezza dall'accesso di codice precedente in cui le impostazioni ASP.NET si intersecano con i criteri dell'azienda, del computer e dell'utente. Questo comportamento legacy verrà spiegato in una sezione successiva.
La modifica più ovvia riguarda le applicazioni ASP.NET 4 parzialmente attendibili ospitate da UNC. Nelle versioni precedenti è necessario utilizzare caspol.exe per elevare le condivisioni UNC ad attendibilità totale per rendere effettivi i criteri ASP.NET parzialmente attendibili. Nelle versioni precedenti di ASP.NET, infatti, i criteri predefiniti di sicurezza dall'accesso di codice CLR a livello di computer vengono applicati per primi. Di conseguenza, le applicazioni ospitate da UNC dispongono di un set di autorizzazioni limitato associato all'area Intranet. Poiché i domini dell'applicazione parzialmente attendibili di ASP.NET 4 stabiliscono criteri solo dai file di criteri ASP.NET, il percorso fisico di un'applicazione Web non ha più alcuna influenza sul set di autorizzazioni associato a un'applicazione parzialmente attendibile.
Un effetto collaterale di questa modifica è illustrato dallo scenario in cui un amministratore desidera bloccare un server Web per negare le autorizzazioni di esecuzione a tutto il codice gestito per impostazione predefinita, quindi concedere i diritti di esecuzione per alcune applicazioni ASP.NET selezionate. Nelle versioni precedenti di ASP.NET questo scenario richiede una soluzione alternativa poco nota come documentato nell'articolo della Knowledge Base relativo alla correzione del messaggio di errore visualizzato quando si tenta di eseguire un'applicazione Web ASP.NET 2.0 senza associare il gruppo di codice My_Computer_Zone al set di autorizzazioni di attendibilità totale, ovvero "Applicazione server non disponibile". In ASP.NET 4 un amministratore può bloccare un server Web per negare o concedere autorizzazioni di esecuzione attenendosi ai passaggi seguenti:
Creare un livello di attendibilità ASP.NET personalizzato il cui file di criteri esegue il mapping di tutto il codice al set di autorizzazioni Nothing (set di autorizzazioni vuoto), quindi configurare tutte le applicazioni ASP.NET per l'utilizzo di tale livello di attendibilità per impostazione predefinita. Questa operazione viene eseguita nel file Web.config radice.
Associare in modo selettivo le singole applicazioni ASP.NET ai livelli di attendibilità predefiniti o personalizzati che concedono autorizzazioni di esecuzione ed eventuali altre autorizzazioni necessarie al codice gestito. Per l'imposizione a livello di computer, è possibile assegnare in modo selettivo i livelli di attendibilità mediante gli elementi location nel file Web.config radice.
Convenzioni di denominazione e percorso per i file di criteri di attendibilità
La convenzione di denominazione e percorso dei file di criteri di sicurezza dall'accesso di codice è la stessa delle versioni precedenti di ASP.NET. I livelli di attendibilità predefiniti sono Full, High, Medium, Low e Minimal. I file di criteri che definiscono i set di autorizzazioni di attendibilità parziale da High a Minimal si trovano tutti nella sottodirectory CONFIG della directory di installazione di .NET Framework.
I file di criteri vengono denominati utilizzando il modello seguente:
web_[trustlevelname]trust.config
Ad esempio, il set di autorizzazioni di attendibilità parziale per l'attendibilità Medium si trova nel file denominato web_mediumtrust.config.
Modifiche nei file di criteri di attendibilità per ASP.NET 4
La maggior parte delle informazioni nei file di criteri di sicurezza dall'accesso di codice di ASP.NET 4 corrisponde alle informazioni presenti nei file di criteri delle versioni precedenti. Tuttavia, sono state introdotte aggiunte secondarie per entrambe le funzionalità .NET Framework 3.5 e .NET Framework 4. Il nome del set di autorizzazioni di attendibilità parziale associato a un dominio dell'applicazione omogeneo è ASP.Net. Per impostazione predefinita, inoltre, a tutto il codice presente in una struttura di directory dell'applicazione Web o nella struttura di directory di generazione del codice vengono concesse le autorizzazioni del set di autorizzazioni denominato ASP.Net.
Sono state apportate due modifiche rispetto alle versioni precedenti dei file di criteri parzialmente attendibili:
Alla fine di ciascun file di criteri di sicurezza dall'accesso di codice di ASP.NET 4, non è più presente un elemento CodeGroup che esegue il mapping dell'attendibilità totale a una chiave di firma Microsoft e alla chiave di firma ECMA. Queste voci sono state rimosse in ASP.NET 4 perché erano voci legacy di versioni precedenti in cui GAC non presupponeva sempre l'attendibilità totale in modo implicito.
La parte Assertion dell'attributo SecurityPermission è stata rimossa da tutti i file di criteri di sicurezza dall'accesso di codice di ASP.NET 4. Una modifica fondamentale apportata da CLR in .NET Framework 4 è il fatto che il codice parzialmente attendibile non può asserire autorizzazioni. Ciò significa che anche il tentativo da parte del codice parzialmente attendibile di asserire autorizzazioni di cui dispone già avrà esito negativo.
Ambito di attendibilità parziale
I domini dell'applicazione omogenei implicano che i limiti del dominio dell'applicazione di ASP.NET 4 sono parzialmente attendibili. Quando un'applicazione viene eseguita con attendibilità parziale, le richieste di sicurezza generano un percorso stack. Tutto il codice nello stack viene valutato rispetto alle autorizzazioni richieste. Nei domini dell'applicazione per ASP.NET 3.5 e versioni precedenti accade comunemente che i percorsi di codice generino un percorso stack fino al limite del dominio dell'applicazione. Poiché i limiti del dominio dell'applicazione nelle versioni precedenti di ASP.NET 4 sono implicitamente ad attendibilità totale, i percorsi stack per alcuni percorsi di codice avrebbero esito positivo. Nei domini dell'applicazione omogenei di ASP.NET 4, qualsiasi percorso stack che raggiunga il limite del dominio dell'applicazione verrà valutato rispetto al set di autorizzazioni di attendibilità parziale attualmente valido per il dominio dell'applicazione.
Il fatto che il limite del dominio dell'applicazione stesso sia ora parzialmente attendibile è la modifica della sicurezza dall'accesso di codice più comune che di solito richiede la modifica del codice ad attendibilità totale affinché funzioni in ASP.NET 4. Ad esempio, era necessario che il team di sviluppo ASP.NET aggiungesse asserzioni di sicurezza di destinazione nei numerosi percorsi di codice interni per eliminare le richieste di sicurezza e impedire che queste ultime eseguissero il bubbling fino al limite del dominio dell'applicazione. In caso contrario, le attività di base come la compilazione della pagina avrebbero avuto esito negativo perché le richieste di sicurezza per tali operazioni (ad esempio le autorizzazioni I/O di file per la compilazione) avrebbero avuto esito negativo se confrontate al set di autorizzazioni di attendibilità parziale per livelli di attendibilità come Medium.
In ASP.NET sono presenti punti di estendibilità che possono comportare il caricamento e l'esecuzione di codice completamente attendibile quando solo il codice ASP.NET si trova sullo stack. In questi scenari, solo il codice ASP.NET si trova inizialmente sullo stack quando ASP.NET chiama un tipo personalizzato che implementa alcuni tipi di punti di estendibilità. Se il tipo personalizzato è completamente attendibile (ciò dovrebbe verificarsi solo se il tipo viene distribuito in GAC) ne risulta che l'intero stack di chiamate è costituito da codice completamente attendibile. In un dominio dell'applicazione omogeneo se qualsiasi codice in un tipo di estendibilità completamente attendibile attiva una richiesta di sicurezza, tale richiesta raggiunge infine il limite del dominio dell'applicazione. Avrà quindi esito negativo quando il controllo di sicurezza viene effettuato rispetto al set di autorizzazioni di attendibilità parziale.
Di seguito è riportato un elenco di alcuni punti di estendibilità ASP.NET in cui si verifica questa situazione:
Gestore HTTP personalizzato. Un gestore personalizzato viene richiamato durante la fase di esecuzione del gestore della pipeline.
Modulo HTTP personalizzato. Un modulo HTTP personalizzato viene richiamato durante un qualsiasi evento della pipeline per cui il modulo è stato registrato.
Provider di compilazione e generatori di espressioni personalizzati. Questi tipi vengono richiamati da ASP.NET quando viene analizzato e compilato il contenuto eseguibile, ad esempio file con estensione aspx.
Provider di gestione ruoli. Un provider personalizzato può essere richiamato durante l'evento AuthorizeRequest nella pipeline.
Provider di profili. È possibile richiamare un provider personalizzato per salvare automaticamente dati dei profili durante l'evento EndRequest.
Provider di monitoraggio dell'integrità. È possibile richiamare un provider personalizzato in orari arbitrari per archiviare i dati di monitoraggio dell'integrità accumulati.
Un semplice esempio di gestore HTTP personalizzato illustra la modifica del comportamento di sicurezza dall'accesso di codice. Nell'esempio seguente si tenta di leggere un file di testo che si trova nella radice dell'unità C:\ tramite il codice del gestore.
Public Class CustomHandler
Implements IHttpHandler
Public Sub ProcessRequest(ByVal context As HttpContext)
Dim data As String = File.ReadAllText("c:\testfile.txt")
context.Response.Write(data)
End Sub
Public Sub New()
End Sub
Public ReadOnly Property IsReusable() As Boolean
Get
Return False
End Get
End Property
End Class
public class CustomHandler : IHttpHandler
{
public void ProcessRequest(HttpContext context)
{
string data = File.ReadAllText("c:\\testfile.txt");
context.Response.Write(data);
}
public CustomHandler() { }
public bool IsReusable { get { return false; } }
}
Se il gestore è firmato, è contrassegnato dall'attributo AllowPartiallyTrustedCallersAttribute e viene distribuito in GAC, il codice avrà esito positivo quando il gestore viene utilizzato in un'applicazione con attendibilità media in ASP.NET 3.5 o nelle versioni precedenti. In questo esempio è stata scelta l'attendibilità media perché in tal caso il set di autorizzazioni di attendibilità parziale consente l'I/O di file di lettura/scrittura solo alla struttura di directory dell'applicazione. Il codice completamente attendibile, ad esempio il gestore di esempio, è in grado di accedere ad altri percorsi di file in ASP.NET 3.5 e nelle versioni precedenti. Ciò è dovuto al fatto che quando viene eseguito il gestore, solo il codice completamente attendibile si trova sullo stack e lo stesso limite del dominio dell'applicazione è completamente attendibile. Di conseguenza, la richiesta di I/O di file dalla chiamata a ReadAllText viene soddisfatta in modo implicito dal limite del dominio dell'applicazione, essendo ad attendibilità totale.
Tuttavia, se lo stesso codice del gestore viene utilizzato in un'applicazione ASP.NET 4 ad attendibilità media, avrà esito negativo perché la chiamata a ReadAllText comporta una richiesta di I/O di file per l'accesso in lettura al file di testo. La richiesta di I/O di file restituisce un percorso stack che raggiunge infine il limite del dominio dell'applicazione. In ASP.NET 4 il limite del dominio dell'applicazione è associato al set di autorizzazioni di attendibilità media che non concede l'accesso alla radice dell'unità C:\. Pertanto, la richiesta di I/O di file avrà esito negativo.
Per ASP.NET 4, è necessario eliminare il percorso stack. A tale scopo, utilizzare l'attributo SecurityAction.Assert dell'attributo FileIOPermission nel metodo ProcessRequest. Nell'esempio riportato di seguito viene illustrato come utilizzare un attributo FileIOPermission a tale scopo.
[Visual Basic]
Public Class CustomHandler
Implements IHttpHandler
<FileIOPermission(SecurityAction.Assert, Read = "c:\testfile.txt")> _
Public Sub ProcessRequest(ByVal context As HttpContext)
Dim data As String = File.ReadAllText("c:\testfile.txt")
context.Response.Write(data)
End Sub
Public Sub New()
End Sub
Public ReadOnly Property IsReusable() As Boolean
Get
Return False
End Get
End Property
End Class
[C#]
public class CustomHandler : IHttpHandler
{
[FileIOPermission(SecurityAction.Assert, Read = "c:\\testfile.txt")]
public void ProcessRequest(HttpContext context)
{
string data = File.ReadAllText("c:\\testfile.txt");
context.Response.Write(data);
}
public CustomHandler() { }
public bool IsReusable { get { return false; } }
}
È possibile utilizzare asserzioni dichiarative, come illustrato nell'esempio, o a livello di codice. La procedura consigliata prevede di asserire in modo dichiarativo le autorizzazioni minime richieste per ottenere il funzionamento di un blocco di codice. Anche se l'aggiunta di asserzioni di sicurezza senza restrizioni ovunque possa sembrare una soluzione semplice, non è consigliabile utilizzare tale approccio. Gli errori di sicurezza causati dal nuovo comportamento dei domini dell'applicazione omogenei sono stati progettati per richiedere di analizzare il codice ad attendibilità totale e capire quali operazioni privilegiate sono necessarie per tale codice. È quindi possibile asserire in modo selettivo il set minimo di autorizzazioni necessarie per abilitare nuovamente il codice ad attendibilità totale.
Configurazione delle applicazioni ASP.NET 4 per l'utilizzo del modello di sicurezza dall'accesso di codice di ASP.NET 2.0
È possibile configurare le applicazioni ASP.NET 4 per l'utilizzo dei comportamenti di sicurezza dall'accesso di codice di ASP.NET 1.0 e ASP.NET 2.0. In ASP.NET 4 l'elemento trust fornisce un nuovo attributo legacyCasModel impostato su false per impostazione predefinita. L'impostazione di questo attributo su true consente di configurare un'applicazione ASP.NET 4 per l'utilizzo di gran parte del comportamento di sicurezza dall'accesso di codice di ASP.NET delle versioni precedenti.
Quando l'attributo LegacyCasModel è impostato su true, si ottengono i comportamenti seguenti:
I limiti del dominio dell'applicazione parzialmente attendibile utilizzano l'attendibilità totale. Ciò significa che in scenari in cui il codice ad attendibilità totale viene eseguito solo con codice ad attendibilità totale sullo stack, non è necessario utilizzare asserzioni per eliminare le richieste di sicurezza.
Le impostazioni per criteri di sicurezza dall'accesso di codice dell'azienda, del computer e dell'utente definite per .NET Framework 4 si intersecano con i criteri di sicurezza dall'accesso di codice di ASP.NET. Ciò significa che verrà applicata qualsiasi autorizzazione personalizzata creata tramite gli strumenti Mscorcfg.msc o caspol.exe di .NET Framework 4.
Nota
Poiché i file di criteri di sicurezza di base e lo strumento caspol.exe per .NET Framework 4 si trovano in una directory diversa rispetto a quelli per .NET Framework 2.0, è necessario creare nuovamente per .NET Framework 4 qualsiasi criterio di sicurezza personalizzato creato per .NET Framework 2.0 utilizzando la versione di caspol.exe di .NET Framework 4.
È possibile specificare più set di autorizzazioni personalizzati che si applicano ad assembly diversi.
I comportamenti correlati alla sicurezza dall'accesso di codice indicati di seguito non cambiano neppure nella modalità di sicurezza dall'accesso di codice legacy:
Gli assembly ASP.NET 4 sono ancora contrassegnati come APTCA condizionale. L'attributo APTACA condizionale è descritto più avanti in questo argomento. Non è possibile ripristinare la modalità legacy di APTCA condizionale perché comporterebbe la rimozione dell'attributo AspNetHostingPermission dalla maggior parte delle API ASP.NET 4 pubbliche. Non vi è alcun modo efficace per applicare tale autorizzazione alle API ASP.NET pubbliche quando vengono eseguite in modalità di sicurezza dall'accesso di codice legacy, ma non quando gli assembly vengono eseguiti nel nuovo modello di sicurezza dall'accesso di codice.
Al codice parzialmente attendibile non è più consentito asserire alcuna autorizzazione. Il codice a cui veniva precedentemente concessa l'attendibilità parziale potrebbe chiamare il metodo Assert e asserire correttamente qualsiasi autorizzazione precedentemente già concessa a tale codice parzialmente attendibile. In .NET Framework 4, indipendentemente dal modello di sicurezza per l'accesso di codice attivo per un'applicazione ASP.NET, tramite il codice parzialmente attendibile non è più possibile eseguire asserzioni di sicurezza.
Per distinguere i set di autorizzazioni applicabili nel modello di sicurezza dall'accesso di codice legacy dal set di autorizzazioni singolo applicabile nel nuovo modello di sicurezza dall'accesso di codice, quando l'attributo LegacyCasModel dell'elemento trust viene impostato su true, in ASP.NET 4 vengono letti i criteri di sicurezza dall'accesso di codice da un set diverso di file di configurazione di attendibilità parziale. Per ogni file di criteri di attendibilità esistente per i livelli di attendibilità ASP.NET predefiniti, esistono due versioni. In ASP.NET viene letta una versione per il nuovo modello di sicurezza dall'accesso di codice e l'altra versione per il modello di sicurezza dall'accesso di codice legacy. Ad esempio, quando ASP.NET 4 viene eseguito in modalità legacy, per l'attendibilità media viene letto il file di criteri denominato legacy.web_mediumtrust.config. Si noti che il nome del file inizia con "legacy". ASP.NET 4 utilizza la stessa convenzione di denominazione per tutti i file di criteri di sicurezza dall'accesso di codice e per i livelli di attendibilità ASP.NET predefiniti. La differenza principale tra i file di criteri di sicurezza dall'accesso di codice legacy e non legacy consiste nel fatto che i primi includono la definizione CodeGroup che fa riferimento alle chiavi di firma Microsoft ed ECMA.
Poiché è possibile configurare un'applicazione per l'utilizzo del modello di sicurezza dall'accesso di codice precedente, per le applicazioni esistenti è necessario impostare LegacyCasModel su true ed evitare pertanto di apportare modifiche. È tuttavia importante capire che l'opzione legacy esiste principalmente per facilitare la transizione delle applicazioni esistenti al modello di sicurezza dall'accesso di codice ASP.NET 4. In futuro, entrambi i team CLR e ASP.NET si concentreranno sulla progettazione e la codifica con il nuovo modello di sicurezza dall'accesso di codice.
Silverlight 2 è stata la prima area di funzionalità di .NET Framework a passare al nuovo modello. L'obiettivo per .NET Framework è portare tutti gli scenari desktop e server ad attendibilità parziale all'esecuzione nel nuovo modello di sicurezza dall'accesso di codice. Di conseguenza, è consigliabile provvedere a riabilitare le applicazioni per l'utilizzo nel modello di sicurezza dall'accesso di codice. Analogamente, è opportuno che gli amministratori che in precedenza utilizzavano gli strumenti caspol.exe e Mscorcfg.msc utilizzino ora la personalizzazione delle assegnazioni delle autorizzazioni e dei file di criteri ASP.NET parzialmente attendibili.
Personalizzazione dell'assegnazione dei set di autorizzazioni nel modello di sicurezza dall'accesso di codice ASP.NET 4
Sebbene i domini dell'applicazione omogenei di ASP.NET 4 vincolino il codice all'attendibilità totale o al set di autorizzazioni di attendibilità parziale ASP.NET denominato, gli sviluppatori e gli amministratori possono influire sul processo con cui un set di autorizzazioni è associato a un assembly. Gli approcci indicati di seguito consentono di personalizzare il processo di associazione di un set di autorizzazioni a una parte di codice in esecuzione:
È possibile personalizzare il file di criteri parzialmente attendibili per un singolo livello di attendibilità, approccio possibile nelle versioni precedenti di ASP.NET.
È possibile configurare in modo statico gli assembly ASP.NET 4 ad attendibilità totale.
È possibile utilizzare li tipo HostSecurityPolicyResolver di ASP.NET 4 per accedere alla funzionalità della classe HostSecurityManager CLR in modo limitato.
I primi due approcci consentono di effettuare personalizzazioni in modo dichiarativo, mentre la terza opzione consente di effettuare personalizzazioni nel codice.
Personalizzazione di file di criteri per un livello di attendibilità
Il primo approccio alla modifica di file di criteri parzialmente attendibili ASP.NET è lo stesso delle versioni precedenti di ASP.NET: è possibile modificare il set di autorizzazioni nel set di autorizzazioni ASP.NET denominato. È inoltre possibile aggiungere più definizioni CodeGroup con condizioni di appartenenza personalizzate. Come accennato in precedenza, le nuove personalizzazioni di sicurezza dall'accesso di codice devono essere effettuate in file di criteri parzialmente attendibili come web_mediumtrust.config. I file il cui nome inizia con "legacy" vengono analizzati e utilizzati quando l'attributo LegacyCasModel dell'elemento trust è impostato su true.
Per ASP.NET 4, tutte le definizioni CodeGroup personalizzate devono eseguire il mapping a uno di tre possibili set di autorizzazioni: FullTrust, , ovvero il set di autorizzazioni di attendibilità parziale, o Nothing. Poiché i domini dell'applicazione parzialmente attendibili ASP.NET 4 sono omogenei per impostazione predefinita, le voci dei criteri personalizzate devono restituire un set limitato di set di autorizzazioni. Sebbene possa sembrare possibile definire set di autorizzazioni denominati diversi quando si utilizza il modello di sicurezza dall'accesso di codice ASP.NET 4, qualsiasi codice valutato rispetto a un set di autorizzazioni diverso da FullTrust, ASP.Net o Nothing restituisce un'eccezione SecurityException in fase di esecuzione. Viene indicato che il set di autorizzazioni valutato non è stato riconosciuto da CLR.
Il set di autorizzazioni FullTrust indica che il codice viene eseguito con attendibilità totale. Il set di autorizzazioni ASP.Net è il set di autorizzazioni di attendibilità parziale denominato che viene in genere utilizzato per i domini dell'applicazione parzialmente attendibili. Come descritto in precedenza, Nothing non è un set di autorizzazioni effettivo riconosciuto da CLR, ma è il set di autorizzazioni vuoto. Se in CLR viene determinato che un assembly è associato a un set di autorizzazioni vuoto, viene generata un'eccezione SecurityException e l'assembly non viene caricato.
Inoltre, ASP.NET 4 consente di modificare il nome del set di autorizzazioni ASP.Net mediante l'attributo PermissionSetName dell'elemento trust. È possibile impostare un nome diverso per l'attributo PermissionSetName. In fase di esecuzione ASP.NET 4 cercherà un elemento PermissionSet con lo stesso nome nel file di criteri parzialmente attendibili. Tale set di autorizzazioni denominato verrà quindi utilizzato come set di autorizzazioni di attendibilità parziale per un dominio dell'applicazione omogeneo. È improbabile che occorra eseguire tale operazione. Tuttavia, la possibilità di modificare il nome del set di autorizzazioni di attendibilità parziale con un nome diverso da ASP.Net è stata aggiunta per soddisfare gli ambienti di hosting come SharePoint, in cui viene definito un set di autorizzazioni denominato personalizzato come entità distinta dal set di autorizzazioni ASP.NET predefinito. Si tenga presente che nel nuovo modello di sicurezza dall'accesso di codice non è più possibile disporre di più set di autorizzazioni denominati che definiscono autorizzazioni parzialmente attendibili. Anche se è possibile assegnare al set di autorizzazioni di attendibilità parziale un nome diverso da ASP.Net, è comunque possibile disporre di un solo set di autorizzazioni di attendibilità parziale attivo per un'applicazione.
Specifica di assembly a cui verrà concessa l'attendibilità totale
La seconda personalizzazione dichiarativa dei criteri è una novità di ASP.NET 4 e consente di stabilire in modo esplicito un elenco di identità assembly a cui verrà sempre concessa l'attendibilità totale. La configurazione securityPolicy contiene una nuova sezione di configurazione fullTrustAssemblies figlio. La sezione FullTrustAssembliesSection è un insieme standard che supporta operazioni di aggiunta, rimozione e cancellazione, in cui è possibile specificare una o più identità assembly a cui verrà concessa l'attendibilità totale in fase di esecuzione. Nell'esempio riportato di seguito viene illustrata una sezione di configurazione fullTrustAssemblies.
<system.web>
<securityPolicy>
<fullTrustAssemblies>
<add assemblyName="MyCustomAssembly"
version="1.0.0.0"
publicKey="a 320 hex character representation
of the public key blob used with a
signed assembly"
/>
</fullTrustAssemblies>
</securityPolicy>
</system.web>
Ciascuna voce dell'elemento fullTrustAssemblies identifica un assembly in base al nome e alla versione e in base a una stringa di 320 caratteri che è la rappresentazione in caratteri esadecimali della metà pubblica della chiave di firma.
Nota
In futuro i nuovi assembly .NET Framework potrebbero utilizzare chiavi di firma a 2048 bit.Se vengono rilasciati nuovi assembly che utilizzano chiavi di firma a 2048 bit, si avranno stringhe esadecimali di 576 caratteri.
Nella definizione non è specificato alcun percorso dell'assembly. Spetta al singolo ambiente di hosting (ad esempio ASP.NET 4) trovare e caricare gli assembly. Se un assembly caricato corrisponde alle informazioni contenute in uno degli elementi add di fullTrustAssemblies, all'assembly viene concessa l'attendibilità totale.
È necessario utilizzare fullTrustAssemblies per gli assembly non distribuiti in GAC, ma destinati a essere sempre eseguiti in attendibilità totale. Poiché gli assembly elencati in fullTrustAssemblies possono essere personalizzati in qualsiasi punto della gerarchia di configurazione (dal file Web.config radice ai singoli file Web.config a livello di applicazione), l'utilizzo di questa impostazione è più semplice e flessibile per la concessione dell'attendibilità totale rispetto all'utilizzo di una condizione di appartenenza e un gruppo di codice in un file di criteri parzialmente attendibili. È possibile personalizzare gli elenchi fullTrustAssemblies per le singole applicazioni specificando informazioni diverse per le diverse applicazioni. Questa operazione può essere eseguita nei file Web.config a livello di applicazione o nel file Web.config radice tramite gli elementi location.
Il set di assembly ad attendibilità totale viene stabilito immediatamente al momento della creazione di un dominio dell'applicazione parzialmente attendibile. Di conseguenza, se un file di criteri parzialmente attendibili include informazioni che restituiscono concessioni diverse per un assembly elencato nell'elemento fullTrustAssemblies, le informazioni vengono ignorate e all'assembly viene concessa attendibilità totale.
Personalizzazione di autorizzazioni a livello di codice
È inoltre possibile modificare a livello di codice l'associazione di un set di autorizzazioni a un assembly creando un'implementazione personalizzata del tipo HostSecurityPolicyResolver ASP.NET 4. In fase di esecuzione ASP.NET 4 utilizza la propria implementazione del tipo HostSecurityManager CLR. Un oggetto HostSecurityManager viene chiamato da CLR ogni volta che viene caricato un assembly. Una delle funzioni della proprietà HostSecurityManager consiste nel restituire un oggetto PermissionSet che deve essere associato a un assembly specificato e per un set di evidenze. ASP.NET 4 consente di personalizzare questo processo chiamando un oggetto HostSecurityPolicyResolver personalizzato a ogni richiesta da parte di CLR di una decisione relativa al set di autorizzazioni.
È possibile configurare un oggetto HostSecurityPolicyResolver personalizzato mediante l'attributo HostSecurityPolicyResolverType dell'elemento trust. Se in ASP.NET 4 viene determinato che un oggetto HostSecurityPolicyResolver personalizzato viene configurato per un'applicazione, viene chiamato il metodo ResolvePolicy del resolver personalizzato a ogni richiesta da parte di CLR di una decisione relativa al set di autorizzazioni. Tuttavia, a differenza di un oggetto HostSecurityManager, un oggetto HostSecurityPolicyResolver può restituire solo un set limitato di possibili decisioni ad ASP.NET 4. Il valore restituito del metodo ResolvePolicy deve essere uno dei valori seguenti dell'enumerazione HostSecurityPolicyResults:
DefaultPolicy. Viene specificato che ASP.NET 4 deve utilizzare la propria logica per la determinazione del set di autorizzazioni appropriato per l'assembly. È necessario restituire DefaultPolicy per gli assembly per cui non si desidera che l'oggetto HostSecurityPolicyResolver prenda una decisione relativa al set di autorizzazioni. La restituzione di DefaultPolicy fa in modo che ASP.NET determini il set di concessioni di un assembly in base alle condizioni di appartenenza e ai gruppi di codice dichiarativi definiti nel file di criteri parzialmente attendibili per il livello di attendibilità ASP.NET corrente.
FullTrust. All'assembly deve essere concessa l'attendibilità totale.
AppDomainTrust. All'assembly deve essere concesso il set di autorizzazioni di attendibilità parziale associato al dominio dell'applicazione. In genere ciò significa che all'assembly verranno concesse le autorizzazioni definite nel set di autorizzazioni ASP.Net denominato.
None. Il set di autorizzazioni per l'assembly verrà impostato sul set di autorizzazioni Nothing.
Poiché la classe HostSecurityPolicyResolver di base dispone di una richiesta di ereditarietà per l'autorizzazione di sicurezza senza restrizioni e un oggetto HostSecurityPolicyResolver personalizzato deve essere caricabile senza richiedere un altro oggetto HostSecurityPolicyResolver per stabilire l'attendibilità totale, le implementazioni concrete di una classe HostSecurityPolicyResolver devono essere sempre firmate e distribuite in GAC.
Nell'esempio seguente viene illustrato un oggetto HostSecurityPolicyResolver personalizzato che concede l'attendibilità totale a tutti gli assembly caricati da una directory specifica. Può trattarsi di uno scenario per organizzazioni che aggiungono assembly compilati a un percorso specifico su disco (non GAC) e che desiderano che tutti i file di tale percorso vengano eseguiti automaticamente con attendibilità totale. Per consentire alle applicazioni ASP.NET di caricare assembly dall'esterno della struttura di directory di un'applicazione Web, è necessario aggiungere reindirizzamenti espliciti dell'associazione di assembly che associno le identità assembly ad altri percorsi su dischi fisici.
[Visual Basic]
Public Class MyCustomResolver
Inherits HostSecurityPolicyResolver
Public Overloads Overrides Function ResolvePolicy(ByVal evidence _
As Evidence) As HostSecurityPolicyResults
Dim urlEvidence As Url = evidence.GetHostEvidence(Of Url)()
If (urlEvidence IsNot Nothing) AndAlso _
(urlEvidence.Value.StartsWith("file:///C:/FullTrustExample_HSPR.dll")) Then
Return HostSecurityPolicyResults.FullTrust
End If
' Specify that ASP.NET should perform its own logic.
Return HostSecurityPolicyResults.DefaultPolicy
End Function
End Class
public class MyCustomResolver : HostSecurityPolicyResolver
{
public override HostSecurityPolicyResults
ResolvePolicy(Evidence evidence)
{
Url urlEvidence = evidence.GetHostEvidence<Url>();
if ( (urlEvidence != null) &&
(urlEvidence.Value.StartsWith("file:///C:/FullTrustExample_HSPR.dll"))
)
return HostSecurityPolicyResults.FullTrust;
// Specify that ASP.NET should perform its own logic.
return HostSecurityPolicyResults.DefaultPolicy;
}
}
APTCA condizionale
Nelle versioni di .NET Framework precedenti alla 4 molti assembly completamente attendibili (inclusi gli assembly ASP.NET) sono contrassegnati dall'attributo AllowPartiallyTrustedCallersAttribute (APTCA). Questo attributo concede ai chiamanti parzialmente attendibili l'accesso ai membri e ai tipi pubblici definiti negli assembly contrassegnati in questo modo. In .NET Framework 4 nel CLR è inclusa una variazione dell'attributo APTCA definita APTCA condizionale. La notazione abbreviata per l'attributo APTCA condizionale è C-APTCA. Con l'attributo APTCA condizionale, gli assembly contrassegnati con l'attributo APTCA mantengono le caratteristiche di tale attributo solo in determinati ambienti ospitati. Di conseguenza, con l'attributo APTCA condizionale è più semplice per ASP.NET 4 controllare con esattezza in quali ambienti host parzialmente attendibili i chiamanti parzialmente attendibili potranno chiamare le API ASP.NET 4 pubbliche con esito positivo.
Funzionamento dell'attributo APTCA condizionale
Sia gli ambienti host parzialmente attendibili che gli assembly completamente attendibili hanno un ruolo nel funzionamento dell'attributo APTCA condizionale. Gli ambienti host parzialmente attendibili in cui i set di autorizzazioni sono importanti possono fornire a CLR un elenco di assembly per i quali occorre sempre rispettare l'impostazione APTCA. Negli assembly completamente attendibili per i quali le caratteristiche dell'attributo APTCA devono essere abilitate solo in determinati ambienti host tale condizione viene indicata con la variazione seguente dell'attributo APTCA a livello di assembly:
[assembly: AllowPartiallyTrustedCallers(PartialTrustVisibilityLevel=NotVisibleByDefault)]
In fase di esecuzione, alla richiesta di caricare un assembly contrassegnato come APTCA condizionale, in CLR verrà controllato l'elenco degli assembly APTCA condizionali validi forniti dall'ambiente host. Se l'assembly si trova nell'elenco, in CLR tutto il codice esposto pubblicamente nell'assembly verrà considerato come se l'assembly fosse stato contrassegnato con l'attributo APTCA nelle versioni precedenti di .NET Framework.
Se un assembly APTCA condizionale non si trova nell'elenco di assembly dell'ambiente host da considerare APTCA, l'assembly viene caricato, ma senza le caratteristiche dell'attributo APTCA. La disponibilità effettiva delle API pubbliche per il codice utente parzialmente attendibile in tale assembly varia a seconda del fatto che l'assembly sia o meno trasparente per la sicurezza al 100%, ovvero a seconda che l'assembly sia contrassegnato con un attributo SecurityTransparentAttribute a livello di assembly. La trasparenza per la sicurezza in ASP.NET 4 viene descritta in una sezione successiva di questo argomento.
In breve, le API pubbliche in ASP.NET 4 possono avere uno dei due comportamenti seguenti:
Per la maggior parte degli assembly ASP.NET, tutte le API pubbliche diventano non disponibili per i chiamanti parzialmente attendibili. In effetti, ciò impedisce l'utilizzo della maggior parte delle API pubbliche in ASP.NET 4 in qualsiasi ambiente parzialmente attendibile diverso dalle applicazioni Web.
Alcuni assembly ASP.NET contrassegnati come trasparenti per la sicurezza al 100% possono ancora essere chiamati dai chiamanti parzialmente attendibili. Tuttavia, se i percorsi di codice in tali assembly raggiungono il resto del codebase ASP.NET, le chiamate hanno esito negativo. Ne risulta lo stesso comportamento delle versioni precedenti di ASP.NET, con la leggera differenza che le chiamate alle API negli assembly ASP.NET 4 avanzeranno ulteriormente prima che si verifichi un errore.
Si notino le considerazioni seguenti sugli assembly contrassegnati come trasparenti per la sicurezza:
Vi sono solo due assembly ASP.NET contrassegnati come trasparenti per la sicurezza a livello di assembly: System.Web.DynamicData.dll e System.Web.RegularExpressions.dll.
System.Web.Routing.dll non viene considerato trasparente per la sicurezza al 100% in ASP.NET 4 perché tutti i tipi definiti in tale assembly nelle versioni precedenti di ASP.NET sono stati spostati in System.Web.dll. In effetti, in ASP.NET 4 System.Web.Routing.dll è un assembly di soli metadati.
In ASP.NET 4 la variazione dell'attributo APTCA condizionale si trova negli assembly seguenti:
System.Web.dll
System.Web.Extensions.dll
System.Web.DynamicData.dll
System.Web.DataVisualization.dll
System.ComponentModel.DataAnnotations.dll
System.Web.ApplicationServices.dll. Questo assembly è nuovo in ASP.NET 4.
System.Web.Abstractions.dll. I tipi in questo assembly sono stati spostati in System.Web.dll per ASP.NET 4.
System.Web.Routing.dll. I tipi in questo assembly sono stati spostati in System.Web.dll per ASP.NET 4.
Attributo APTCA condizionale e attributi di autorizzazione hosting ASP.NET
L'attributo APTCA condizionale ha reso fattibile la rimozione dell'attributo AspNetHostingPermission dal 99% delle API pubbliche in ASP.NET 4. L'attributo AspNetHostingPermission viene ancora utilizzato in alcune posizioni in ASP.NET 4, ma solo nei casi in cui lo scopo dell'autorizzazione è realmente significativo. In tutte le altre posizioni, i due utilizzi dell'attributo AspNetHostingPermission riportati di seguito sono stati rimossi:
<AspNetHostingPermission(SecurityAction.LinkDemand,
Level=AspNetHostingPermissionLevel.Minimal)>
<AspNetHostingPermission(SecurityAction.InheritanceDemand,
Level=AspNetHostingPermissionLevel.Minimal)>
[AspNetHostingPermission(SecurityAction.LinkDemand,
Level=AspNetHostingPermissionLevel.Minimal)]
[AspNetHostingPermission(SecurityAction.InheritanceDemand,
Level=AspNetHostingPermissionLevel.Minimal)]
Queste definizioni di autorizzazioni sono utilizzate nelle versioni precedenti di ASP.NET per evitare il caricamento degli assembly ASP.NET in ambienti parzialmente attendibili non Web. Il problema principale è dato dal caricamento di controlli gestiti parzialmente attendibili e applicazioni gestite in browser come Microsoft Internet Explorer e Mozilla Firefox. Tramite l'attributo APTCA condizionale, le stesse protezioni vengono applicate efficacemente perché le applicazioni ClickOnce e i controlli gestiti basati su browser non definiscono alcun assembly APTCA condizionale da trattare come APTCA completo.
Personalizzazione dell'elenco di assembly APTCA condizionali ASP.NET 4
Come indicato in precedenza, i singoli ambienti host possono fornire a CLR un elenco di assembly APTCA condizionali le cui caratteristiche APTCA devono essere rispettate. In ASP.NET 4 un elenco hardcoded che contiene tutti gli assembly ASP.NET 4 viene fornito a CLR. Se ciò non accadesse, le applicazioni Web avrebbero immediatamente esito negativo al tentativo di esecuzione della prima riga del codice interno ASP.NET in un dominio dell'applicazione parzialmente attendibile.
In .NET Framework 4 l'attributo APTCA condizionale è un nuovo concetto di sicurezza dall'accesso di codice non ancora implementato in altre parti di .NET Framework. Pertanto, è probabile che le versioni future di .NET Framework includeranno più assembly APTCA condizionali. Inoltre, con l'aumentare della consapevolezza dell'attributo APTCA condizionale e il relativo utilizzo per gli assembly con attendibilità totale personalizzati, il set di assembly APTCA condizionali si amplierà. Poiché è impossibile per ASP.NET 4 conoscere in anticipo tutti i possibili assembly APTCA condizionali, in ASP.NET 4 è presente una sezione di configurazione in cui è possibile aggiungere assembly APTCA condizionali.
Nella sezione securityPolicy esistente è presente una sezione di configurazione figlio denominata partialTrustVisibleAssemblies. Si tratta di un insieme standard che supporta operazioni di aggiunta, rimozione e cancellazione, in cui è possibile specificare una o più identità assembly che devono essere trattate come APTCA (se sono anche contrassegnate per l'attributo APTCA condizionale). Nell'esempio riportato di seguito viene illustrata una sezione partialTrustVisibleAssemblies.
<system.web>
<securityPolicy>
<partialTrustVisibleAssemblies>
<add assemblyName="MyCustomAssembly"
publicKey="a 320 hex character representation
of the public key blob used with a
signed assembly"
/>
</partialTrustVisibleAssemblies>
</securityPolicy>
</system.web>
Ogni voce nella sezione partialTrustVisibleAssemblies identifica un assembly in base al nome. Ogni voce viene inoltre identificata da una stringa di 320 caratteri (ad esempio 0x03FA4D...) che è la rappresentazione in caratteri esadecimali della metà pubblica della chiave di firma utilizzata nell'assembly con attributi APTCA condizionali. Non è necessario specificare un attributo di versione. In CLR sono necessari solo il nome dell'assembly e il token di chiave pubblica.
Un'importante implicazione per le prestazioni legata all'abilitazione di un assembly APTCA condizionale è la necessità di abilitare anche la chiusura transitiva degli assembly APTCA condizionali. Ad esempio, se l'assembly ATPCA condizionale A dipende dall'assembly APTCA B e l'assembly APTCA B dipende a sua volta dall'assembly ATPCA condizionale C, quando si abilita l'attributo ATPCA condizionale per A è necessario abilitarlo anche per C. In caso contrario, le prestazioni dell'applicazione possono risultare compromesse. Ad esempio, la condivisione di codice e le immagini NGen verranno disabilitate se non si abilita la chiusura completa degli attributi ATPCA condizionali.
Implicazioni dell'attributo APTCA condizionale sulle applicazioni parzialmente attendibili non Web
Nelle versioni di ASP.NET precedenti ad ASP.NET 4 alcuni tipi e spazi dei nomi non sono contrassegnati con l'attributo AspNetHostingPermission. Ciò consente la chiamata di tali tipi da ambienti parzialmente attendibili non ASP.NET, ad esempio le applicazioni ClickOnce. I tipi e gli spazi dei nomi che potevano essere chiamati in questo modo sono i seguenti:
Tipi nello spazio dei nomi System.Web.ClientServices.
Tipi nello spazio dei nomi System.Web.ClientServices.Providers.
Il tipo HttpUtility.
I tipi System.Web.ClientServices non sono utilizzabili negli ambienti parzialmente attendibili .NET Framework 4, ad esempio ClickOnce. Poiché l'assembly contenitore (System.Web.Extensions.dll) è un assembly ASP.NET 4 contrassegnato per l'attributo APTCA condizionale e poiché ClickOnce non consente l'attributo APTCA per qualsiasi assembly APTCA condizionale, nessuno dei tipi di servizi client può essere chiamato da applicazioni ClickOnce parzialmente attendibili.
Questo comportamento può essere determinato da diversi motivi. Innanzitutto, .NET Framework 4 è stato suddiviso in un client e in una SKU estesa e si presuppone che molte applicazioni ClickOnce abbiano come destinazione la SKU client. Sarebbe necessario uno sforzo sostanziale per effettuare il refactoring dei tipi di servizi client ASP.NET nella SKU client.
Inoltre, è complicato determinare come effettuare il refactoring dei tipi client nei limiti dell'attributo APTCA condizionale richiesti. Pertanto, in .NET Framework 4 i tipi di servizi client sono disponibili solo per gli ambienti di attendibilità totale non ASP.NET, incluse le applicazioni ClickOnce configurate per l'esecuzione in attendibilità totale mediante le SKU .NET Framework 4 estese.
Per il tipo HttpUtility, l'effetto dell'attributo APTCA condizionale dipende dai metodi utilizzati, come illustrato negli scenari seguenti:
Il codice parzialmente attendibile chiama il metodo HtmlEncode o HtmlDecode della classe WebUtility. Il tipo WebUtility contiene la codifica HTML ASP.NET e le implementazioni di decodifica, ma queste sono state sottoposte a refactoring e spostate nello spazio dei nomi System.Net contenuto in System.dll. Poiché System.dll è disponibile in tutti gli ambienti host parzialmente attendibili, non vi sono problemi con i metodi del tipo WebUtility che accedono ad applicazioni parzialmente attendibili non ASP.NET.
Il codice parzialmente attendibile chiama uno degli altri metodi della classe WebUtility. In tal caso, si verifica lo stesso problema descritto precedentemente per i tipi di servizi client. Ciò significa che WebUtility è disponibile solo per i chiamanti con attendibilità totale non ASP.NET in .NET Framework 4.
Trasparenza per la sicurezza in ASP.NET 4
Con la trasparenza per la sicurezza è possibile indicare a CLR se un blocco di codice eseguirà mai un'operazione sensibile per la sicurezza. Il codice Transparent non può mai asserire autorizzazioni, soddisfare una richiesta di collegamento, contenere codice non verificabile o chiamare codice critico per la sicurezza. Ciò vale indipendentemente dal fatto che il codice Transparent sia completamente attendibile (ad esempio nella GAC) o parzialmente attendibile.
La trasparenza per la sicurezza è una funzionalità alquanto efficace per le funzionalità di .NET Framework come ASP.NET. Consente ad ASP.NET di indicare a CLR quali parti di codice ASP.NET non asseriranno mai autorizzazioni e quale codice non implementerà mai o non eseguirà mai operazioni sensibili per la sicurezza, ad esempio chiamate PInvoke nel codice nativo. Viene così abilitato il codice .NET Framework per la riduzione sostanziale dell'esposizione a rischi legati alla sicurezza di un gran numero di API pubbliche e interne anche se il codice .NET Framework si trova nella GAC completamente attendibile.
La trasparenza per la sicurezza si può applicare a un intero assembly o solo a un subset del codice nell'assembly. Sebbene contrassegnare un intero assembly per la trasparenza per la sicurezza sia la soluzione ideale, parti di codice .NET Framework hanno un requisito legittimo per l'esecuzione di attività sensibili per la sicurezza. Gli assembly che contengono codice trasparente per la sicurezza al 100% sono contrassegnati mediante un attributo SecurityTransparentAttribute a livello di assembly.
Gli assembly che contengono una combinazione di codice trasparente e non trasparente non dispongono di un attributo di trasparenza a livello di assembly. Viceversa, le singole classi nell'assembly possono essere contrassegnate tramite l'attributo SecuritySafeCriticalAttributel o SecurityCriticalAttribute.
Il comportamento delle classi senza attributi è complesso. Tuttavia, in pratica, i tipi senza attributi negli assembly ASP.NET 4 che hanno adottato il nuovo modello di trasparenza vengono considerati trasparenti per la sicurezza. I tipi negli assembly ASP.NET 4 senza attributi che non hanno adottato il nuovo modello di trasparenza vengono considerati critici per la sicurezza.
Trasparenza per la sicurezza nella pratica e set di regole per la sicurezza
Dal momento che una parte consistente della codebase ASP.NET 4 si trova in System.Web.dll, non era agevole convertire tutto il codice ASP.NET 4 nel nuovo modello di trasparenza. Invece, il codice ASP.NET 4 può essere partizionato nelle categorie seguenti:
Codice che non ha adottato il nuovo modello di trasparenza, incluso il codice negli assembly seguenti:
System.Web.dll
System.Web.ApplicationServices.dll
System.Web.Mobile.dll. I tipi in questo assembly sono stati contrassegnati come obsoleti in ASP.NET 4. Anche se l'assembly esiste ancora, si prevede che l'utilizzo dei tipi in questo assembly verrà interrotto nel corso del tempo.
Codice che utilizza il nuovo modello di trasparenza, incluso il codice negli assembly seguenti:
System.Web.Extensions.dll
System.Web.DynamicData.dll (trasparente per la sicurezza al 100%)
System.Web.RegularExpressions.dll (trasparente per la sicurezza al 100%)
System.ComponentModel.DataAnnotations.dll
System.Web.DataVisualization.dll
Assembly composti solo da metadati e i cui tipi sono stati spostati in un assembly ASP.NET diverso, inclusi i seguenti:
System.Web.Abstractions.dll. I tipi contenuti in questo assembly nelle versioni precedenti di ASP.NET sono stati spostati in System.Web.dll. Di conseguenza, Sytem.Web.Abstractions.dll è un assembly di soli metadati in ASP.NET 4.
System.Web.Routing.dll. I tipi contenuti in questo assembly nelle versioni precedenti di ASP.NET sono stati spostati in System.Web.dll. Di conseguenza, System.Web.Routing.dll è un assembly di soli metadati in ASP.NET 4.
In .NET Framework 4 in CLR è stato introdotto un nuovo concetto definito set di regole di sicurezza. Esistono due livelli di configurazioni SecurityRuleSet, livello uno e livello due. La configurazione SecurityRuleSet per tutti i tipi viene specificata tramite l'attributo a livello di assembly SecurityRulesAttribute. Gli assembly ASP.NET 4 che hanno adottato il nuovo modello di trasparenza sono contrassegnati mediante l'attributo a livello di assembly seguente:
System.Security.SecurityRules(RuleSet=System.Security.SecurityRuleSet.Level2)
Gli assembly ASP.NET 4 che utilizzano il modello di trasparenza di .NET Framework 2.0, che per ASP.NET indica di fatto nessuna trasparenza, perché nelle versioni di ASP.NET precedenti ASP.NET 4 non sono mai stati utilizzati concetti relativi alla trasparenza, sono contrassegnati mediante l'attributo a livello di assembly seguente:
System.Security.SecurityRules(RuleSet=System.Security.SecurityRuleSet.Level1)
Per gli assembly ASP.NET che hanno adottato il nuovo modello di trasparenza, e i tipi pubblici presenti negli assembly, la maggior parte del codice è considerato trasparente per la sicurezza. Una piccola quantità di codice in questi assembly esegue operazioni sensibili per la sicurezza e tale codice è contrassegnato come critico per la sicurezza o critico.
Per gli assembly ASP.NET che non hanno adottato il nuovo modello di trasparenza, esclusi gli assembly obsoleti o reindirizzati da tipo, tutte le API pubbliche possono essere chiamate dal codice utente parzialmente attendibile ed eseguire internamente operazioni sensibili per la sicurezza. La combinazione tra accesso aperto ai chiamanti parzialmente attendibili e il potenziale di operazioni sensibili per la sicurezza fa sì che il codice di ASP.NET 4 meno recente richieda un grado maggiore di analisi. Tuttavia, poiché la maggior parte delle nuove funzionalità di ASP.NET viene implementata in assembly più nuovi come System.Web.Extensions.dll e System.Web.DynamicData.dll o in versioni separate come MVC ASP.NET, la maggior parte del nuovo codice ASP.NET è trasparente per la sicurezza e pertanto, per impostazione predefinita, più sicuro rispetto al codice precedente.
Per impostazione predefinita, CLR tratta le API pubbliche di tutti gli assembly ASP.NET 4 contrassegnati come SecurityRuleSet.Level1 come critiche per la sicurezza, ovvero come se fossero contrassegnate con l'attributo SecuritySafeCriticalAttribute, a condizione che l'ambiente di hosting rispetti l'attributo APTCA. Se non viene rispettato l'attributo APTCA, CLR attiva una richiesta di collegamento per l'attendibilità totale che non avrà esito positivo quando è presente codice utente parzialmente attendibile sullo stack. In altre parole, quando l'attributo APTCA non è rispettato per un assembly ASP.NET contrassegnato come SecurityRuleSet.Level1, si ha lo stesso comportamento delle versioni precedenti di .NET Framework quando il codice parzialmente attendibile tenta di chiamare un assembly di attendibilità totale non contrassegnato con l'attributo APTCA.
Per impostazione predefinita, CLR tratta l'API pubblica di tutti gli assembly ASP.NET 4 contrassegnati come SecurityRuleSet.Level2 come trasparente per la sicurezza, ovvero come se fosse contrassegnata con l'attributo SecurityTransparentAttribute, a condizione che l'ambiente di hosting rispetti l'attributo APTCA. In caso contrario, viene definito il comportamento seguente:
Se l'attributo APTCA non viene rispettato e un assembly contrassegnato come Level2 non è trasparente per la sicurezza al 100%, CLR tratta la superficie di attacco pubblica come critica per la sicurezza. Di conseguenza, il tentativo da parte di qualsiasi chiamante parzialmente attendibile di utilizzare la superficie di attacco pubblica avrà probabilmente esito negativo con un'eccezione MethodAccessException, TypeAccessException o FieldAccessException.
Se l'attributo APTCA non viene rispettato e un assembly contrassegnato come Level2 è trasparente per la sicurezza al 100%, i chiamanti parzialmente attendibili saranno in grado di chiamare correttamente qualsiasi API pubblica in tale assembly. In pratica, ciò significa che si verifica un'eccezione SecurityException in un secondo momento nel percorso di chiamata quando il codice nell'assembly trasparente per la sicurezza al 100% chiama un assembly ASP.NET di livello 1 o 2 non trasparente per la sicurezza al 100%.
Trasparenza e compilazione in ASP.NET
Anche l'output creato dal sistema di compilazione ASP.NET è interessato dall'adozione in ASP.NET 4 del nuovo modello di sicurezza dall'accesso di codice e del nuovo modello di trasparenza per la sicurezza. Sono inclusi elementi come assembly di pagina, assembly precompilati e i risultati compilati della directory App_Code. Il comportamento del sistema di compilazione varia in base all'impostazione dell'attributo LegacyCasModel dell'elemento trust.
Nella tabella seguente viene descritto in che modo sono contrassegnati gli oggetti compilati in modo dinamico sia nel modello di sicurezza dall'accesso di codice legacy che in quello più recente.
Impostazione dell'attributo legacyCasModel |
Livello di attendibilità del sito Web |
Attributi applicati agli assembly compilati |
|---|---|---|
False (nuovo modello di sicurezza dall'accesso di codice) |
Attendibilità totale |
SecurityRules(SecurityRuleSet.Level2) |
Attendibilità elevata o impostazione inferiore |
SecurityRules(SecurityRuleSet.Level2) |
|
SecurityRules(SecurityRuleSet.Level2) |
||
True (modello di sicurezza dall'accesso di codice precedente) |
Attendibilità totale |
SecurityRules(SecurityRuleSet.Level1) |
Attendibilità elevata o impostazione inferiore |
SecurityRules(SecurityRuleSet.Level1) |
Poiché il comportamento del sistema di compilazione di ASP.NET 4 varia in base alle impostazioni dell'attributo LegacyCasModel dell'elemento trust, possono essere presenti restrizioni sulla condivisione di codice compilato tra le diverse applicazioni ASP.NET 4 parzialmente attendibili. In generale, non si dovrebbe riscontrare alcuna modifica nel comportamento dell'applicazione. Tuttavia, in alcuni scenari gli elementi compilati creati da un'applicazione parzialmente attendibile con l'attributo LegacyCasModel impostato su false, ovvero che utilizza il nuovo modello di sicurezza dall'accesso di codice, non funzionano come previsto quando vengono utilizzati con altre applicazioni. Di conseguenza, per alcuni scenari (ad esempio una libreria condivisa di controlli ascx compilati firmati, con attributi ATPCA e distribuita nella GAC) potrebbe essere necessario applicare in modo esplicito gli attributi critici e critici per la sicurezza a un codice quando la libreria viene contrassegnata mediante Level2.