Cenni preliminari sulla generazione di codice protetto
In questa sezione sono forniti cenni preliminari sulle diverse modalità di interazione del codice con il sistema di protezione.
Codice indipendente dalla protezione
Il codice indipendente dalla protezione non ha elementi espliciti in comune con il sistema di protezione e viene eseguito a prescindere dalle autorizzazioni ricevute. Anche se le applicazioni che non riescono a intercettare eccezioni associate alle operazioni protette, come l'utilizzo di file o le operazioni in rete, possono avere come effetto eccezioni non gestite, il codice indipendente dalla protezione è comunque in grado di sfruttare le tecnologie di protezione di .NET Framework.
Una libreria indipendente dalla protezione dispone di caratteristiche speciali che è necessario comprendere. Si supponga che nella libreria siano forniti elementi API che consentano di utilizzare file o chiamare codice non gestito; se al codice non è associata l'autorizzazione corrispondente, questo non verrà eseguito nel modo descritto. Tuttavia, anche al codice viene concessa l'autorizzazione, il codice delle applicazioni da cui tale codice viene chiamato deve disporre della stessa autorizzazione per funzionare. Se il codice chiamante non dispone dell'autorizzazione appropriata, sarà generata una SecurityException a seguito dell'analisi dello stack ai fini della protezione dall'accesso di codice.
Codice di applicazioni non riutilizzabile
Se il codice fa parte di un'applicazione che non verrà richiamata da altro codice, la protezione è semplice e potrebbe non essere necessario scrivere codice speciale. Ricordare ad ogni modo che il codice può essere chiamato da codice dannoso. Anche se la protezione dall'accesso di codice può impedire a codice dannoso di accedere alle risorse, con questo codice è comunque possibile leggere i valori contenuti nei campi o nelle proprietà che possono rappresentare informazioni sensibili.
Se inoltre il codice accetta input da Internet o da altre fonti inaffidabili, è opportuno evitare input dannosi.
Wrapper gestiti nell'implementazione di codice nativo
In genere, in uno scenario di questo tipo, viene implementata una funzionalità utile nel codice nativo da rendere disponibile per il codice gestito. I wrapper gestiti possono essere scritti in modo semplice utilizzando il richiamo piattaforma o l'interoperabilità COM. Per la riuscita di questa operazione è tuttavia necessario che i chiamanti dei wrapper dispongano di diritti per il codice non gestito. In base ai criteri predefiniti, il codice scaricato da una rete Intranet o da Internet non funzionerà con i wrapper.
Invece di assegnare a tutte le applicazioni che impiegano i wrapper diritti di codice non gestito, è preferibile fornire questi diritti solo al codice wrapper. Se la funzionalità sottostante non espone alcuna risorsa e l'implementazione rimane "sicura", per il wrapper è sufficiente l'asserzione dei diritti, che attiva la chiamata tramite codice. Quando sono coinvolte le risorse, il codice della protezione deve essere analogo a quello di libreria descritto nella sezione successiva. Poiché il wrapper può esporre i chiamanti a queste risorse, la verifica attenta della protezione del codice nativo è necessaria e costituisce uno dei compiti del wrapper.
Codice di libreria che espone risorse protette
Si tratta dell'approccio più efficace e potenzialmente pericoloso, se eseguito in modo non corretto, della codifica della protezione: la libreria funge da interfaccia per l'accesso tramite codice ad alcune risorse non altrimenti disponibili, così come le classi di .NET Framework impongono le autorizzazioni relative alle risorse che utilizzano. Se si espone una risorsa, è necessario per prima cosa esigere tramite codice l'autorizzazione adeguata alla risorsa (in altre parole, eseguire un controllo di protezione) e quindi eseguire un'asserzione dei relativi diritti per eseguire l'operazione vera e propria.