Considerazioni aggiuntive sulla sicurezza in Windows Form
Le impostazioni di sicurezza di .NET Framework possono far sì che si verifichino delle differenze tra l'esecuzione dell'applicazione in un ambiente parzialmente attendibile e quella sul computer locale. .NET Framework impedisce l'accesso ad alcune risorse locali critiche, ad esempio file system, rete e API non gestite. Le impostazioni di sicurezza influiscono sulla possibilità di chiamare l'API Win32 Microsoft o altre API che non possono essere verificate dal sistema di sicurezza. La sicurezza influisce anche su altri aspetti dell'applicazione, inclusi l'accesso ai file e ai dati nonché le operazioni di stampa. Per ulteriori informazioni sull'accesso ai file e ai dati in un ambiente parzialmente attendibile, vedere File e accesso ai dati più protetti in Windows Form. Per ulteriori informazioni sulla stampa in un ambiente parzialmente attendibile, vedere Stampa più protetta in Windows Form.
Nelle sezioni riportate di seguito viene illustrato come utilizzare gli Appunti, modificare le finestre e chiamare l'API Win32 da applicazioni in esecuzione in un ambiente parzialmente attendibile.
Accesso agli Appunti
La classe UIPermission consente di controllare l'accesso agli Appunti, mentre il valore di enumerazione UIPermissionClipboard associato indica il livello di accesso. Nella tabella che segue sono riportati i possibili livelli di autorizzazione.
Valore UIPermissionClipboard |
Descrizione |
|---|---|
È possibile utilizzare gli Appunti senza limitazioni. |
|
È possibile utilizzare gli Appunti con alcune limitazioni. Per la possibilità di inserire dati negli Appunti (tramite le operazioni dei comandi Copia o Taglia) non esiste alcuna limitazione. I controlli intrinseci che accettano l'operazione Incolla, ad esempio una casella di testo, possono accettare i dati degli Appunti, ma i controlli utente non possono leggere a livello di codice dagli Appunti. |
|
Non è possibile utilizzare gli Appunti. |
Per impostazione predefinita, all'area Intranet locale viene concesso il diritto di accesso AllClipboard e all'area Internet il diritto di accesso OwnClipboard. L'applicazione è quindi in grado di copiare i dati negli Appunti, ma non può incollare o leggere dagli Appunti a livello di codice. Queste limitazioni impediscono ai programmi non full trust di leggere il contenuto copiato negli Appunti da un'altra applicazione. Se l'applicazione richiede un accesso completo agli Appunti ma non si dispone delle autorizzazioni richieste, sarà necessario aumentare le autorizzazioni dell'applicazione. Per ulteriori informazioni sull'aumento delle autorizzazioni, vedere Amministrazione generale dei criteri di sicurezza.
Modifica delle finestre
La classe UIPermission consente inoltre di controllare le autorizzazioni per la modifica delle finestre e l'esecuzione di altre azioni correlate all'interfaccia utente, mentre il valore di enumerazione UIPermissionWindow associato indica il livello di accesso. Nella tabella che segue sono riportati i possibili livelli di autorizzazione.
Per impostazione predefinita, all'area Intranet locale viene concesso il diritto di accesso AllWindows e all'area Internet il diritto di accesso SafeTopLevelWindows. Nell'area Internet, quindi, l'applicazione può eseguire la maggior parte delle azioni relative alle finestre e all'interfaccia utente, ma l'aspetto della finestra verrà modificato. La finestra modificata visualizza una notifica alla prima esecuzione, contiene testo modificato della barra del titolo e richiede un pulsante di chiusura sulla barra del titolo. Il suggerimento e la barra del titolo indicano all'utente che l'applicazione è in esecuzione con attendibilità parziale.
Valore UIPermissionWindow |
Descrizione |
|---|---|
Gli utenti possono utilizzare tutte le finestre e gli eventi di input utente senza restrizioni. |
|
Gli utenti possono utilizzare per il disegno soltanto le finestre protette di primo livello e le sottofinestre sicure e possono utilizzare soltanto gli eventi di input dell'interfaccia utente all'interno di tali finestre e sottofinestre. Le finestre sicure sono chiaramente contrassegnate e prevedono alcune limitazioni sulle dimensioni minima e massima. Tali limitazioni impediscono attacchi di spoofing potenzialmente dannosi, ad esempio l'imitazione delle schermate di accesso del sistema o del desktop, nonché l'accesso a livello di codice alle finestre padre, la chiamate alle API relative allo stato attivo e l'utilizzo del controllo ToolTip. |
|
Gli utenti possono utilizzare per il disegno soltanto le sottofinestre sicure e possono utilizzare soltanto gli eventi di input dell'interfaccia utente all'interno di tali sottofinestre. Un esempio di sottofinestra sicura è costituito da un controllo all'interno di un browser. |
|
Gli utenti non possono utilizzare alcuna finestra o evento di interfaccia. Non è possibile utilizzare alcuna interfaccia utente. |
Ciascun livello di autorizzazione identificato dall'enumerazione UIPermissionWindow consente meno azioni rispetto al livello superiore. Nelle tabelle riportate di seguito sono indicate le azioni limitate dai valori SafeTopLevelWindows e SafeSubWindows. Per conoscere esattamente le autorizzazioni richieste per ciascun membro, fare riferimento all'argomento relativo a tale membro nella documentazione sulla libreria di classi di .NET Framework.
Nella tabella seguente sono elencate le azioni impedite dall'autorizzazione SafeTopLevelWindows.
Componente |
Azioni limitate |
|---|---|
|
|
|
|
|
|
|
|
|
Il valore SafeSubWindows limita le azioni elencate nella tabella riportata di seguito, oltre alle limitazioni definite dal valore SafeTopLevelWindows.
Componente |
Azioni limitate |
|---|---|
|
|
|
|
|
|
|
Hosting di controlli di terze parti
Un altro tipo di manipolazione delle finestre può verificarsi se i form ospitano controlli di terze parti. Per controllo di terze parti si intende qualsiasi controllo UserControl personalizzato non sviluppato né compilato personalmente. Sebbene lo scenario di hosting sia difficile da sfruttare, in teoria è possibile che la superficie di rendering di un controllo di terze parti si espanda per coprire l'intera area del form. Questo controllo potrebbe quindi riprodurre una finestra di dialogo critica e richiedere agli utenti informazioni quali le combinazioni di nome utente/password o i numeri di conto corrente.
Per limitare questo rischio potenziale, utilizzare controlli di terze parti solo di fornitori attendibili. Se si utilizzano controlli di terze parti scaricati da una fonte non verificabile, si consiglia di esaminare il codice sorgente per rilevare potenziali attacchi alla sicurezza. Dopo aver verificato che il codice sorgente non è dannoso, è necessario compilare personalmente l'assembly per assicurarsi che il codice sorgente corrisponda all'assembly.
Chiamate all'API Win32
Se il progetto dell'applicazione richiede la chiamata a una funzione dell'API Win32, si accede al codice non gestito. In questo caso, non è possibile determinare le azioni del codice relative alla finestra o al sistema operativo quando si utilizzano valori o chiamate all'API Win32. La classe SecurityPermission e il valore UnmanagedCode dell'enumerazione SecurityPermissionFlag consentono di controllare l'accesso al codice non gestito. Un'applicazione può accedere al codice non gestito solo se dispone dell'autorizzazione UnmanagedCode. Per impostazione predefinita, soltanto le applicazioni eseguite localmente possono effettuare chiamate al codice non gestito.
Alcuni membri di Windows Form forniscono un tipo di accesso non gestito che richiede l'autorizzazione UnmanagedCode. Nella tabella riportata di seguito sono elencati i membri nello spazio dei nomi System.Windows.Forms che richiedono tale autorizzazione. Per ulteriori informazioni sulle autorizzazioni richieste per un membro, fare riferimento alla documentazione sulla libreria di classi di .NET Framework.
Componente |
Membro |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Se non dispone dell'autorizzazione per effettuare chiamate al codice non gestito, l'applicazione deve richiedere l'autorizzazione UnmanagedCode. In caso contrario, è necessario prendere in considerazione modi alternativi di implementazione delle funzionalità. In molti casi, Windows Form fornisce un'alternativa gestita alle funzioni dell'API Win32. Se non esistono alternative e l'applicazione richiede l'accesso al codice non gestito, sarà necessario aumentare le autorizzazioni dell'applicazione.
L'autorizzazione a chiamare il codice non gestito consente di eseguire praticamente qualsiasi operazione nell'applicazione. Per questo motivo, questo tipo di autorizzazione deve essere concesso solo alle applicazioni che provengono da un'origine attendibile. In alternativa, a seconda dell'applicazione, la parte di funzionalità dell'applicazione che effettua la chiamata al codice non gestito potrebbe essere resa facoltativa oppure attivata soltanto nell'ambiente con attendibilità totale. Per ulteriori informazioni sulle autorizzazioni pericolose, vedere Autorizzazioni pericolose e amministrazione dei criteri. Per ulteriori informazioni sull'elevazione delle autorizzazioni, vedere Amministrazione generale dei criteri di sicurezza.
Vedere anche
Concetti
File e accesso ai dati più protetti in Windows Form
Stampa più protetta in Windows Form
Cenni preliminari sulla sicurezza in Windows Form
Protezione di applicazioni ClickOnce