Codice non gestito
Aggiornamento: novembre 2007
Il codice di alcune librerie deve eseguire chiamate in codice non gestito, come le API di codice nativo, ad esempio Win32. Poiché questo comporta l'uscita dai limiti della protezione per il codice gestito, è necessaria particolare attenzione. Se il codice è indipendente dalla sicurezza, sia tale codice sia il codice da cui viene chiamato devono disporre dell'autorizzazione SecurityPermission per codice non gestito con il flag UnmanagedCode specificato.
È spesso sconsigliabile fornire al chiamante autorizzazioni di questo tipo. In questi casi, il codice attendibile può rappresentare un problema per la protezione, come il wrapper gestito o il codice di libreria descritto in Protezione del codice wrapper. Se la funzionalità del codice non gestito sottostante è totalmente sicura, può essere esposta direttamente; in caso contrario, è necessario eseguire prima un controllo di autorizzazioni adeguato, ovvero una pretesa.
Quando il codice chiama codice non gestito e non si desidera che i chiamanti dispongano dell'autorizzazione ad accedere a codice non gestito, è necessario eseguire l'asserzione di questo diritto. Una asserzione blocca il percorso stack all'interno del frame; evitare di creare una vulnerabilità della protezione in questo processo. Di solito, è necessario esigere un'autorizzazione adatta per i chiamanti e quindi utilizzare codice non gestito per eseguire solo le operazioni consentite dall'autorizzazione e non altre. In alcuni casi, come la funzione per l'ottenimento dell'ora del giorno, il codice non gestito può essere esposto direttamente ai chiamanti senza che siano eseguiti controlli di protezione. Il codice in cui viene eseguita l'asserzione deve consentire in ogni caso la gestione della protezione.
Poiché il codice gestito in cui viene fornito un percorso di codice all'interno del codice nativo rappresenta un obiettivo potenziale del codice dannoso, è necessaria estrema attenzione per determinare quale parte di codice non gestito può essere utilizzata con sicurezza e come utilizzarla. In genere, il codice non gestito non deve essere mai esposto direttamente a chiamanti parzialmente attendibili. Nella valutazione della sicurezza del codice non gestito nelle librerie che è possibile chiamare da codice parzialmente gestito, sono necessarie due considerazioni principali:
Funzionalità. Considerare se nel codice API non gestito sia fornita una funzionalità che non consenta ai chiamanti di eseguire operazioni potenzialmente dannose. La protezione dall'accesso di codice impiega le autorizzazioni per applicare l'accesso alle risorse; considerare quindi se l'API consente di utilizzare file, un'interfaccia utente o il threading oppure di esporre informazioni protette. In questo caso, dal codice gestito che funge da wrapper devono essere pretese le autorizzazioni necessarie prima di consentirne l'accesso. Inoltre, quando non è protetta da un'autorizzazione, è necessario che l'accesso alla memoria sia limitato alla rigida indipendenza dei tipi.
Controllo dei parametri. In un attacco di tipo comune vengono passati parametri imprevisti a metodi API di codice non gestito esposto nel tentativo di determinarne il funzionamento al di fuori delle specifiche. I sovraccarichi del buffer tramite indici non compresi nell'intervallo o valori di offset costituiscono un esempio comune di questo tipo di attacco, allo stesso modo di altri parametri che possono sfruttare errori nel code-behind. Di conseguenza, anche se l'API del codice non gestito è protetta dal punto di vista funzionale, implementando cioè le esigenze di autorizzazioni che si reputano necessarie, per i chiamanti parzialmente attendibili deve essere eseguito anche il controllo completo della validità dei parametri, per evitare l'esecuzione di chiamate impreviste da parte di codice dannoso tramite il livello del wrapper del codice gestito.