Procedure consigliate per la protezione in WCF
Nelle sezioni seguenti vengono elencate le procedure consigliate da prendere in considerazione quando si creano applicazioni protette tramite Windows Communication Foundation (WCF). Per altre informazioni sulla sicurezza, vedere Considerazioni sulla sicurezza, Considerazioni sulla protezione per i dati e Considerazioni sulla sicurezza con metadati.
Identificare i servizi che eseguono l'autenticazione di Windows con SPN
I servizi possono essere identificati con i nomi dell'entità utente (UPN) o i nomi dell'entità servizio (SPN). I servizi in esecuzione in account di computer, come un servizio di rete, dispongono di un'identità SPN che corrisponde al computer in cui sono in esecuzione. I servizi in esecuzione in account utente dispongono di un'identità UPN che corrisponde all'utente utilizzato per l'esecuzione, sebbene sia possibile utilizzare lo strumento setspn per assegnare un SPN all'account utente. La configurazione di un servizio in modo da poterlo identificare tramite SPN e la configurazione dei client che si connettono al servizio affinché utilizzino tale SPN possono rendere più difficili alcuni attacchi. Questo materiale sussidiario si applica alle associazioni che utilizzano Kerberos o la negoziazione SSPI. I client devono comunque specificare un SPN nel caso in cui SSPI esegua il fallback a NTLM.
Verificare le identità di servizio in WSDL
WS-SecurityPolicy consente ai servizi di pubblicare informazioni sulle relative identità nei metadati. In caso di recupero tramite svcutil o altri metodi, ad esempio WsdlImporter, le informazioni sull'identità vengono traslate nelle proprietà di identità degli indirizzi endpoint del servizio WCF. I client che non verificano la correttezza e la validità di queste identità di servizio ignorano in realtà l'autenticazione del servizio. Un servizio dannoso può sfruttare tali client per eseguire l'inoltro di credenziali e altri attacchi "man in the middle" modificando l'identità attestata in WSDL.
Utilizzare certificati X509 anziché NTLM
WCF offre due meccanismi per l'autenticazione peer-to-peer: i certificati X509 (usati dal canale peer) e l'autenticazione di Windows in cui una negoziazione SSPI effettua un downgrade da Kerberos a NTLM. L'autenticazione basata sui certificati che utilizza dimensioni della chiave pari a 1024 bit o superiori è preferibile a NTLM per diversi motivi:
disponibilità di autenticazione reciproca
utilizzo di algoritmi crittografici più avanzati
maggiore difficoltà nell'utilizzo di credenziali X509 inoltrate.
Eseguire sempre il ripristino dopo la rappresentazione
Quando si utilizzano API che consentono la rappresentazione di un client, assicurarsi di ripristinare sempre l'identità originale. Quando si usano, ad esempio, WindowsIdentity e WindowsImpersonationContext, usare l'istruzione C# using o l'istruzione Visual Basic Using, come illustrato nel codice seguente. La classe WindowsImpersonationContext implementa l'interfaccia IDisposable e pertanto, il Common Language Runtime (CLR) torna automaticamente alla propria l'identità originale quando il codice lascia il blocco using.
WindowsIdentity identity = ServiceSecurityContext.Current.WindowsIdentity;
using (identity.Impersonate())
{
// Run code under the caller's identity.
}
Dim identity = ServiceSecurityContext.Current.WindowsIdentity
Using identity.Impersonate()
' Run code under the caller's identity.
End Using
Eseguire la rappresentazione solo quando necessario
Utilizzando il metodo Impersonate della classe WindowsIdentity è possibile utilizzare la rappresentazione in un ambito molto controllato. Si tratta di una procedura opposta all'utilizzo della proprietà Impersonation di OperationBehaviorAttribute che consente la rappresentazione per l'ambito dell'intera operazione. Quando possibile, controllare sempre l'ambito della rappresentazione utilizzando il metodo Impersonate più preciso.
Ottenere i metadati da fonti attendibili
Assicurarsi che l'origine dei metadati sia attendibile e che nessuno abbia manomesso i metadati. I metadati recuperati utilizzando il protocollo HTTP vengono inviati come testo non crittografato e possono essere alterati. Se il servizio utilizza le proprietà HttpsGetEnabled e HttpsGetUrl, utilizzare l'URL fornito dal creatore del servizio per scaricare i dati tramite il protocollo HTTPS.
Pubblicare i metadati tramite la protezione
Per impedire che i metadati pubblicati di un servizio vengano alterati, proteggere l'endpoint dello scambio di metadati con la sicurezza a livello di trasporto o di messaggio. Per altre informazioni, vedere Pubblicazione di endpoint dei metadati e Procedura: Pubblicare metadati per un servizio usando codice.
Assicurarsi che venga utilizzato l'emittente locale
Se per una determinata associazione vengono specificati l'indirizzo dell'emittente e l'associazione, l'emittente locale non verrà utilizzato per gli endpoint che utilizzano tale associazione. Per i client che prevedono di utilizzare sempre l'emittente locale, è necessario accertarsi di non utilizzare tale associazione o di modificare l'associazione in modo che l'indirizzo dell'emittente sia null.
Quota delle dimensioni del token SAML
Quando i token SAML (Security Assertions Markup Language) vengono serializzati nei messaggi, quando sono rilasciati da un servizio token di sicurezza (STS, Security Token Service) o quando sono presentati dai client ai servizi nell'ambito dell'autenticazione, la quota della dimensione massima del messaggio deve essere sufficientemente grande da contenere il token SAML e le altre parti del messaggio. Normalmente la quota della dimensione predefinita del messaggio è sufficiente. Nei casi in cui un token SAML sia di grandi dimensioni perché contiene centinaia di attestazioni, è necessario aumentare le quote per contenere il token serializzato. Per altre informazioni sulle quote, vedere Considerazioni sulla protezione per i dati.
Impostare SecurityBindingElement.IncludeTimestamp su True nelle associazioni personalizzate
Quando si crea un'associazione personalizzata, è necessario impostare IncludeTimestamp su true. In caso contrario, se IncludeTimestamp viene impostato su false e il client utilizza un token basato su chiave asimmetrica quale un certificato X509, il messaggio non sarà firmato.