Condividi tramite

Strategia di sicurezza WPF - Sicurezza della piattaforma

Mentre Windows Presentation Foundation (WPF) offre un'ampia gamma di servizi di sicurezza, sfrutta anche le funzionalità di sicurezza della piattaforma sottostante, che include il sistema operativo, CLR e Internet Explorer. Questi livelli si combinano per fornire a WPF un modello di sicurezza avanzato e di difesa avanzata che tenta di evitare un singolo punto di guasto, come illustrato nella figura seguente:

Diagramma che mostra il modello di sicurezza WPF.

Nella parte restante di questo argomento vengono illustrate le funzionalità di ognuno di questi livelli relativi a WPF in modo specifico.

Avvertimento

La sicurezza dall'accesso di codice (CAS) non è supportata da .NET moderno, è un concetto di solo .NET Framework. Tutte le funzionalità correlate a CAS vengono trattate con il presupposto di attendibilità totale. Per altre informazioni, vedere Differenze con WPF .NET - Sicurezza dall'accesso al codice.

Sicurezza del sistema operativo

Il core di Windows offre diverse funzionalità di sicurezza che costituiscono la base di sicurezza per tutte le applicazioni Windows, incluse quelle create con WPF. Questo argomento illustra l'ampiezza di queste funzionalità di sicurezza importanti per WPF, nonché il modo in cui WPF si integra con essi per fornire ulteriore difesa approfondita.

Microsoft Windows XP Service Pack 2 (SP2)

Oltre a una revisione generale e al rafforzamento di Windows, sono disponibili tre funzionalità chiave di Windows XP SP2 che verranno illustrate in questo argomento:

  • Compilazione /GS

  • Microsoft Windows Update.

Compilazione /GS

Windows XP SP2 offre protezione ricompilando molte librerie di sistema principali, incluse tutte le dipendenze WPF, ad esempio CLR, per ridurre i sovraccarichi del buffer. Ciò si ottiene usando il parametro /GS con il compilatore della riga di comando C/C++. Anche se i sovraccarichi del buffer devono essere evitati in modo esplicito, la compilazione /GS fornisce un esempio di difesa approfondita contro potenziali vulnerabilità create accidentalmente o dannose da essi.

Storicamente, i sovraccarichi del buffer sono stati la causa di molti exploit di sicurezza ad alto impatto. Un sovraccarico del buffer si verifica quando un utente malintenzionato sfrutta una vulnerabilità del codice che consente l'inserimento di codice dannoso che scrive oltre i limiti di un buffer. In questo modo un attaccante può dirottare il processo in cui il codice viene eseguito, sovrascrivendo l'indirizzo di ritorno di una funzione per causare l'esecuzione del codice dell'attaccante. Il risultato è un codice dannoso che esegue codice arbitrario con gli stessi privilegi del processo di hijacked.

A livello generale, il flag del compilatore -GS protegge da alcuni potenziali sovraccarichi del buffer inserendo un cookie di sicurezza speciale per proteggere l'indirizzo restituito di una funzione con buffer di stringa locali. Dopo la restituzione di una funzione, il cookie di sicurezza viene confrontato con il valore precedente. Se il valore è stato modificato, è possibile che si sia verificato un sovraccarico del buffer e che il processo venga arrestato con una condizione di errore. L'arresto del processo impedisce l'esecuzione di codice potenzialmente dannoso. Vedere -GS (Controllo di Sicurezza del Buffer) per ulteriori dettagli.

WPF viene compilato con il flag /GS per aggiungere un altro livello di difesa alle applicazioni WPF.

Windows Vista

Gli utenti WPF in Windows Vista trarranno vantaggio dai miglioramenti di sicurezza aggiuntivi del sistema operativo, tra cui " accesso utenteLeast-Privilege", controlli di integrità del codice e isolamento dei privilegi.

Controllo dell'account utente

Attualmente, gli utenti di Windows tendono ad operare con privilegi di amministratore perché molte applicazioni li richiedono per l'installazione e l'esecuzione, o entrambi. La possibilità di scrivere le impostazioni predefinite dell'applicazione nel Registro di sistema è un esempio.

L'esecuzione con privilegi di amministratore significa realmente che le applicazioni vengono eseguite dai processi a cui vengono concessi privilegi di amministratore. L'impatto sulla sicurezza è che qualsiasi codice dannoso che dirotta un processo in esecuzione con privilegi di amministratore erediterà automaticamente tali privilegi, incluso l'accesso alle risorse di sistema critiche.

Un modo per proteggersi da questa minaccia per la sicurezza consiste nell'eseguire applicazioni con il minor numero di privilegi necessari. Questo è noto come principio dei privilegi minimi ed è una funzionalità di base del sistema operativo Windows. Questa funzionalità è denominata Controllo dell'account utente (UAC) e viene usata da UAC di Windows in due modi principali:

  • Per eseguire la maggior parte delle applicazioni con privilegi di controllo dell'account utente per impostazione predefinita, anche se l'utente è un amministratore, solo le applicazioni che necessitano tali privilegi verranno eseguite con privilegi di amministratore. Per poter essere eseguite con privilegi amministrativi, le applicazioni devono essere contrassegnate esplicitamente nel manifesto dell'applicazione o incluse nei criteri di sicurezza.

  • Per fornire soluzioni di compatibilità come la virtualizzazione. Ad esempio, molte applicazioni tentano di scrivere in percorsi limitati come C:\Programmi. Per le applicazioni in esecuzione sotto UAC (Controllo dell'account utente), esiste una posizione alternativa per utente che non richiede privilegi di amministratore per scrivere. Per le applicazioni in esecuzione sotto il Controllo dell'account utente (UAC), UAC virtualizza C:\Programmi in modo che le applicazioni che credono di scrivere in essa stiano effettivamente scrivendo nella posizione alternativa per utente. Questo tipo di lavoro di compatibilità permette al sistema operativo di eseguire molte applicazioni che in precedenza non potevano funzionare con il Controllo dell'Account Utente (UAC).

Controlli di integrità del codice

Windows Vista incorpora controlli di integrità del codice più approfonditi per impedire l'inserimento di codice dannoso nei file di sistema o nel kernel in fase di caricamento/esecuzione. Questo va oltre la protezione dei file di sistema.

Processo con diritti limitati per le applicazioni Browser-Hosted

Le applicazioni WPF ospitate nel browser sono eseguite nella sandbox dell'area Internet. L'integrazione wpf con Microsoft Internet Explorer estende questa protezione con supporto aggiuntivo.

Avvertimento

Per funzionare, gli XBAP richiedono browser legacy, come Internet Explorer e versioni precedenti di Firefox. Questi browser meno recenti sono in genere non supportati in Windows 10 e Windows 11. I browser moderni non supportano più la tecnologia necessaria per le app XBAP a causa di rischi per la sicurezza. I plug-in che abilitano XBAP non sono più supportati. Per altre informazioni, vedere Domande più frequenti sulle applicazioni ospitate dal browser WPF (XBAP).

Poiché le applicazioni browser XAML (XBAP) sono in genere in modalità sandbox dal set di autorizzazioni dell'area Internet, la rimozione di questi privilegi non danneggia le applicazioni browser XAML (XBAP) dal punto di vista della compatibilità. Viene invece creato un ulteriore livello di difesa in profondità; se un'applicazione in modalità sandbox è in grado di sfruttare altri livelli e dirottare il processo, il processo avrà comunque privilegi limitati.

Consulta Uso di un account utente Least-Privileged.

La sicurezza del Common Language Runtime

Common Language Runtime (CLR) offre numerosi vantaggi principali per la sicurezza, tra cui convalida e verifica, sicurezza dall'accesso al codice e metodologia critica per la sicurezza.

Convalida e verifica

Per garantire l'isolamento e l'integrità degli assembly, CLR usa un processo di convalida. La convalida CLR garantisce che gli assembly siano isolati convalidando il formato di file PE (Portable Executable) per gli indirizzi che puntano all'esterno dell'assembly. La convalida CLR convalida anche l'integrità dei metadati incorporati all'interno di un assembly.

Per garantire la sicurezza dei tipi, prevenire problemi di sicurezza comuni (ad esempio sovraccarichi del buffer) e abilitare la sandboxing tramite l'isolamento del processo secondario, la sicurezza CLR usa il concetto di verifica.

Le applicazioni gestite vengono compilate in Microsoft Intermediate Language (MSIL). Quando vengono eseguiti metodi in un'applicazione gestita, il relativo codice MSIL viene compilato in codice nativo tramite la compilazione JUST-In-Time (JIT). La compilazione JIT include un processo di verifica che applica molte regole di sicurezza e affidabilità che assicurano che il codice non sia:

  • Violare i contratti di tipo

  • Introdurre sovraccarichi del buffer

  • Accesso selvaggio alla memoria.

Il codice gestito non conforme alle regole di verifica non può essere eseguito, a meno che non sia considerato codice attendibile.

Il vantaggio del codice verificabile è un motivo fondamentale per cui WPF si basa su .NET Framework. Nella misura in cui viene usato il codice verificabile, la possibilità di sfruttare possibili vulnerabilità è notevolmente ridotta.

Sicurezza dell'accesso al codice

Un computer client espone un'ampia gamma di risorse a cui un'applicazione gestita può accedere, tra cui il file system, il Registro di sistema, i servizi di stampa, l'interfaccia utente, la reflection e le variabili di ambiente. Prima che un'applicazione gestita possa accedere a una qualsiasi delle risorse in un computer client, deve disporre dell'autorizzazione .NET Framework per farlo. Un'autorizzazione in CAS è una sottoclasse del CodeAccessPermission; CAS implementa una sottoclasse per ogni risorsa a cui le applicazioni gestite possono accedere.

Il set di autorizzazioni che un'applicazione gestita riceve da CAS quando inizia l'esecuzione è noto come set di autorizzazioni ed è determinato dall'evidenza fornita dall'applicazione. Per le applicazioni WPF, l'evidenza fornita è la posizione o la zona da cui vengono avviate le applicazioni. CAS identifica le zone seguenti:

  • Il mio Computer. Applicazioni avviate dal computer client (Completamente attendibile).

  • Intranet locale. Applicazioni avviate dalla intranet. (in qualche modo attendibile).

  • Internet. Applicazioni avviate da Internet. (Meno affidabile)

  • Siti Attendibili. Applicazioni identificate da un utente come attendibili. (Meno affidabile)

  • siti non attendibili. Applicazioni identificate da un utente come non attendibili. (Non attendibile).

Per ciascuna di queste zone, CAS fornisce un set di autorizzazioni predefinito che corrisponde al livello di attendibilità associato a ciascuna. Questi includono:

  • FullTrust. Per le applicazioni avviate dall'area di Risorse del computer. Vengono concesse tutte le autorizzazioni possibili.

  • LocalIntranet. Per le applicazioni avviate dalla zona Intranet locale. A un subset di autorizzazioni è concesso l'accesso moderato alle risorse di un computer client, tra cui l'archiviazione isolata, l'accesso illimitato all'interfaccia grafica utente, le finestre di dialogo dei file senza restrizioni, la riflessione limitata, l'accesso limitato alle variabili di ambiente. Le autorizzazioni per le risorse critiche, ad esempio il Registro di sistema, non vengono fornite.

  • Internet. Per le applicazioni avviate dall'area di Internet o Siti Attendibili. A un subset di autorizzazioni viene concesso l'accesso limitato alle risorse di un computer client, tra cui l'archiviazione isolata, solo l'apertura di file e l'interfaccia utente limitata. In pratica, questo set di autorizzazioni isola le applicazioni dal computer client.

Alle applicazioni identificate come provenienti dalla zona Siti non attendibili non vengono concesse autorizzazioni dalla CAS. Di conseguenza, non esiste un set di autorizzazioni predefinito.

La figura seguente illustra la relazione tra zone, set di autorizzazioni, autorizzazioni e risorse:

Diagramma che mostra i set di autorizzazioni CAS.

Le restrizioni della sandbox di sicurezza dell'area Internet si applicano allo stesso modo a qualsiasi codice importato da un XBAP da una libreria di sistema, incluso WPF. In questo modo si garantisce che ogni parte del codice sia bloccata, anche WPF. Sfortunatamente, per poter essere eseguito, un XBAP deve eseguire funzionalità che richiedono più autorizzazioni rispetto a quelle abilitate dalla sandbox di sicurezza dell'area Internet.

Avvertimento

Per funzionare, gli XBAP richiedono browser legacy, come Internet Explorer e versioni precedenti di Firefox. Questi browser meno recenti sono in genere non supportati in Windows 10 e Windows 11. I browser moderni non supportano più la tecnologia necessaria per le app XBAP a causa di rischi per la sicurezza. I plug-in che abilitano XBAP non sono più supportati. Per altre informazioni, vedere Domande più frequenti sulle applicazioni ospitate dal browser WPF (XBAP).

Si consideri un'applicazione XBAP che include la pagina seguente:

FileIOPermission fp = new FileIOPermission(PermissionState.Unrestricted);
fp.Assert();

// Perform operation that uses the assert

// Revert the assert when operation is completed
CodeAccessPermission.RevertAssert();

Dim fp As New FileIOPermission(PermissionState.Unrestricted)
fp.Assert()

' Perform operation that uses the assert

' Revert the assert when operation is completed
CodeAccessPermission.RevertAssert()

Per eseguire questo XBAP, il codice WPF sottostante deve eseguire più funzionalità di quanto sia disponibile per il XBAP chiamante, tra cui:

  • Creazione di un handle di finestra (HWND) per il rendering

  • Invio di messaggi

  • Caricamento del tipo di carattere Tahoma

Dal punto di vista della sicurezza, consentire l'accesso diretto a una di queste operazioni dall'applicazione in modalità sandbox sarebbe irreversibile.

Fortunatamente, WPF soddisfa questa situazione consentendo l'esecuzione di queste operazioni con privilegi elevati per conto dell'applicazione in modalità sandbox. Anche se tutte le operazioni WPF vengono controllate in base alle autorizzazioni limitate di sicurezza dell'area Internet del dominio applicazione di XBAP, a WPF (come con altre librerie di sistema) viene concesso un set di autorizzazioni che include tutte le autorizzazioni possibili.

Ciò richiede che WPF riceva privilegi elevati impedendo al contempo che tali privilegi vengano regolati dal set di autorizzazioni dell'area Internet del dominio applicazione host.

WPF esegue questa operazione utilizzando il metodo Assert di un'autorizzazione. Nel codice seguente viene illustrato come si verifica questa operazione.

FileIOPermission fp = new FileIOPermission(PermissionState.Unrestricted);
fp.Assert();

// Perform operation that uses the assert

// Revert the assert when operation is completed
CodeAccessPermission.RevertAssert();

Dim fp As New FileIOPermission(PermissionState.Unrestricted)
fp.Assert()

' Perform operation that uses the assert

' Revert the assert when operation is completed
CodeAccessPermission.RevertAssert()

L'Assert impedisce essenzialmente che le autorizzazioni illimitate richieste da WPF vengano limitate dalle autorizzazioni dell'area Internet di XBAP.

Dal punto di vista della piattaforma, WPF è responsabile dell'uso corretto di Assert; un uso non corretto di Assert potrebbe consentire a codice dannoso di elevare privilegi. Di conseguenza, è importante chiamare Assert solo quando necessario e garantire che le restrizioni della sandbox rimangano intatte. Ad esempio, il codice in modalità sandbox non è autorizzato ad aprire file casuali, ma è consentito usare i tipi di carattere. WPF consente alle applicazioni in modalità sandbox di usare la funzionalità dei tipi di carattere chiamando Asserte per WPF di leggere i file noti per contenere tali tipi di carattere per conto dell'applicazione in modalità sandbox.

Distribuzione ClickOnce

ClickOnce è una tecnologia di distribuzione completa inclusa in .NET Framework e si integra con Visual Studio (vedere la sicurezza e la distribuzione ClickOnce per informazioni dettagliate). Le applicazioni WPF autonome possono essere distribuite tramite ClickOnce, mentre le applicazioni ospitate dal browser devono essere distribuite con ClickOnce.

Alle applicazioni distribuite tramite ClickOnce viene assegnato un livello di sicurezza aggiuntivo rispetto alla sicurezza dall'accesso di codice (CAS); essenzialmente, le applicazioni distribuite ClickOnce richiedono le autorizzazioni necessarie. Vengono concesse solo queste autorizzazioni se non superano il set di autorizzazioni per la zona da cui viene distribuita l'applicazione. Riducendo il set di autorizzazioni solo a quelle necessarie, anche se sono inferiori a quelle fornite dal set di autorizzazioni dell'area di avvio, il numero di risorse a cui l'applicazione ha accesso viene ridotto a un minimo. Di conseguenza, se l'applicazione viene dirottata, viene ridotto il rischio di danni al computer client.

Metodologia Security-Critical

Il codice WPF che utilizza le autorizzazioni per abilitare la sandbox della zona Internet per le applicazioni XBAP deve essere sottoposto al più rigoroso grado possibile di audit e controllo della sicurezza. Per facilitare questo requisito, .NET Framework offre un nuovo supporto per la gestione del codice che eleva i privilegi. In particolare, CLR consente di identificare il codice che eleva i privilegi e contrassegnarlo con il SecurityCriticalAttribute; qualsiasi codice non contrassegnato con SecurityCriticalAttribute diventa trasparente usando questa metodologia. Al contrario, al codice gestito non contrassegnato con SecurityCriticalAttribute viene impedito l'elevazione dei privilegi.

Avvertimento

Per funzionare, gli XBAP richiedono browser legacy, come Internet Explorer e versioni precedenti di Firefox. Questi browser meno recenti sono in genere non supportati in Windows 10 e Windows 11. I browser moderni non supportano più la tecnologia necessaria per le app XBAP a causa di rischi per la sicurezza. I plug-in che abilitano XBAP non sono più supportati. Per altre informazioni, vedere Domande più frequenti sulle applicazioni ospitate dal browser WPF (XBAP).

La metodologia di Security-Critical consente all'organizzazione del codice WPF che eleva i privilegi in kernel critico per la sicurezza, con il resto trasparente. Isolare il codice critico per la sicurezza consente al team di ingegneria WPF di focalizzare su un'ulteriore analisi della sicurezza e gestione del codice sorgente sul kernel critico per la sicurezza al di là delle procedure di sicurezza standard (vedere strategia di sicurezza WPF - Progettazione della sicurezza).

Si noti che .NET Framework consente a codice attendibile di estendere la sandbox dell'area Internet XBAP consentendo agli sviluppatori di scrivere assembly gestiti contrassegnati con AllowPartiallyTrustedCallersAttribute (APTCA) e distribuiti nella Global Assembly Cache (GAC) dell'utente. Contrassegnare un assembly con APTCA è un'operazione di sicurezza estremamente sensibile perché consente a qualsiasi codice di chiamare tale assembly, incluso il codice dannoso da Internet. Attenzione estrema e procedure consigliate devono essere usate quando si esegue questa operazione e gli utenti devono scegliere di considerare attendibile il software affinché venga installato.

Sicurezza di Microsoft Internet Explorer

Oltre a ridurre i problemi di sicurezza e semplificare la configurazione della sicurezza, Microsoft Internet Explorer 6 (SP2) contiene diverse funzionalità che migliorano la sicurezza per gli utenti di applicazioni browser XAML (XBAP). La spinta di queste funzionalità tenta di consentire agli utenti un maggiore controllo sull'esperienza di esplorazione.

Avvertimento

Per funzionare, gli XBAP richiedono browser legacy, come Internet Explorer e versioni precedenti di Firefox. Questi browser meno recenti sono in genere non supportati in Windows 10 e Windows 11. I browser moderni non supportano più la tecnologia necessaria per le app XBAP a causa di rischi per la sicurezza. I plug-in che abilitano XBAP non sono più supportati. Per altre informazioni, vedere Domande più frequenti sulle applicazioni ospitate dal browser WPF (XBAP).

Prima di Internet Explorer 6 SP2, gli utenti potrebbero essere soggetti a uno dei seguenti elementi:

  • Finestre popup casuali.

  • Reindirizzamento di script confuso.

  • Numerosi dialoghi di sicurezza in alcuni siti Web.

In alcuni casi, i siti Web non attendibili tentano di ingannare gli utenti tramite lo spoofing dell'interfaccia utente di installazione (UI) o la visualizzazione ripetuta di una finestra di dialogo di installazione di Microsoft ActiveX, anche se l'utente potrebbe aver annullato. Usando queste tecniche, è possibile che un numero significativo di utenti sia stato ingannato nel prendere decisioni scadenti che hanno portato all'installazione di applicazioni spyware.

Internet Explorer 6 SP2 include diverse funzionalità per attenuare questi tipi di problemi, che ruotano intorno al concetto di avvio dell'utente. Internet Explorer 6 SP2 rileva quando un utente ha fatto clic su un collegamento o un elemento della pagina come parte di un'azione, nota come avvio dell'utente, e la gestisce in modo diverso rispetto a quando un'azione simile viene invece attivata dallo script su una pagina. Ad esempio, Internet Explorer 6 SP2 incorpora un Pop-Up Blocker che rileva quando un utente fa clic su un pulsante prima che venga creato un popup. Ciò consente a Internet Explorer 6 SP2 di consentire popup più innocui, impedendo al contempo i popup che gli utenti non chiedono né vogliono. I popup bloccati vengono intrappolati nella nuova barra delle informazioni , che consente all'utente di eseguire manualmente l'override del blocco e visualizzare il popup.

La stessa logica di avvio utente viene applicata anche alle richieste di sicurezza Apri/Salva. Le finestre di dialogo di installazione ActiveX vengono sempre intrappolate nella barra delle informazioni, a meno che non rappresentino un aggiornamento da un controllo installato in precedenza. Queste misure si combinano per offrire agli utenti un'esperienza d'uso più sicura e controllata, poiché sono protetti da siti che li molestano affinché installino software indesiderato o dannoso.

Queste funzionalità proteggono anche i clienti che usano Internet Explorer 6 SP2 per passare ai siti Web che consentono loro di scaricare e installare applicazioni WPF. In particolare, ciò è dovuto al fatto che Internet Explorer 6 SP2 offre un'esperienza utente migliore che riduce la possibilità per gli utenti di installare applicazioni dannose o deviare indipendentemente dalla tecnologia usata per compilarla, incluso WPF. WPF aggiunge a queste protezioni usando ClickOnce per facilitare il download delle applicazioni tramite Internet. Poiché le applicazioni browser XAML (XBAP) vengono eseguite all'interno di una sandbox di sicurezza dell'area Internet, possono essere avviate senza problemi. D'altra parte, le applicazioni WPF autonome richiedono l'attendibilità totale per l'esecuzione. Per queste applicazioni, ClickOnce visualizzerà una finestra di dialogo di sicurezza durante il processo di avvio per notificare l'uso dei requisiti di sicurezza aggiuntivi dell'applicazione. Tuttavia, questo deve essere avviato dall'utente, sarà regolato anche dalla logica avviata dall'utente e può essere annullato.

Internet Explorer 7 incorpora ed estende le funzionalità di sicurezza di Internet Explorer 6 SP2 come parte di un impegno continuo per la sicurezza.

Vedere anche