Linee guida per la generazione di codice sicuro

La sicurezza basata sull'evidenza e la sicurezza per l'accesso al codice forniscono meccanismi espliciti molto efficaci per implementare la sicurezza. Nella maggior parte dei casi, per proteggere il codice delle applicazioni è sufficiente l'infrastruttura implementata da .NET Framework; in alcuni casi è tuttavia necessaria una sicurezza aggiuntiva specifica per l'applicazione, creata mediante l'estensione del sistema di sicurezza o tramite metodi ad hoc.

L'utilizzo delle autorizzazioni applicate da .NET Framework e di altri tipi di sicurezza imposta nel codice consente di creare barriere che impediscono l'ottenimento di informazioni da parte di malware o l'esecuzione di altre operazioni non desiderate. È inoltre necessario raggiungere un compromesso tra sicurezza e possibilità di utilizzo del codice in tutti gli scenari di utilizzo di codice attendibile.

In questa panoramica vengono descritti i diversi metodi di progettazione del codice per l'utilizzo del sistema di sicurezza.

Nota
In .NET Framework versione 4 sono state apportate modifiche importanti al modello di sicurezza e alla terminologia relativa alla sicurezza di .NET Framework. Per ulteriori informazioni su tali modifiche, vedere Modifiche della sicurezza in .NET Framework 4.

Codice indipendente dalla sicurezza

Il codice indipendente dalla sicurezza non ha elementi espliciti in comune con il sistema di sicurezza 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 sicurezza è comunque in grado di sfruttare le tecnologie di sicurezza di .NET Framework.

Una libreria indipendente dalla sicurezza 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, il percorso chiamate nello stack della sicurezza per l'accesso al codice genera un oggetto SecurityException.

Codice di applicazioni non riutilizzabile

Se il codice fa parte di un'applicazione che non verrà richiamata da altro codice, la sicurezza è 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 sicurezza per l'accesso al 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 platform invoke 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 è probabilmente sicura, per il wrapper è sufficiente l'asserzione dei diritti, che consente la chiamata tramite codice. Quando sono coinvolte le risorse, il codice della sicurezza 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 sicurezza 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 sicurezza: 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 sicurezza) e quindi eseguire un'asserzione dei relativi diritti per eseguire l'operazione vera e propria.

Argomenti correlati