Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
La divulgazione di informazioni consente a un utente malintenzionato di ottenere informazioni preziose su un sistema. Pertanto, considerare sempre quali informazioni si stanno rivelando e se possono essere usate da un utente malintenzionato. Di seguito sono elencati i possibili attacchi di divulgazione delle informazioni e sono disponibili mitigazioni per ognuno di essi.
Sicurezza dei messaggi e HTTP
Se si usa la sicurezza a livello di messaggio su un livello di trasporto HTTP, tenere presente che la sicurezza a livello di messaggio non protegge le intestazioni HTTP. L'unico modo per proteggere le intestazioni HTTP consiste nell'usare il trasporto HTTPS anziché HTTP. Il trasporto HTTPS causa la crittografia dell'intero messaggio, incluse le intestazioni HTTP, tramite il protocollo SSL (Secure Sockets Layer).
Informazioni sui criteri
Il mantenimento della sicurezza dei criteri è importante, soprattutto negli scenari di federazione in cui i requisiti dei token rilasciati sensibili o le informazioni sull'autorità di certificazione del token vengono esposte nei criteri. In questi casi, è consigliabile proteggere l'endpoint dei criteri del servizio federato per impedire agli utenti malintenzionati di ottenere informazioni sul servizio, ad esempio il tipo di attestazioni da inserire nel token rilasciato o reindirizzare i client a autorità emittenti di token dannosi. Ad esempio, un attaccante potrebbe individuare coppie nome utente/password riconfigurando la catena di trust federata per terminare in un'entità che esegue un attacco man-in-the-middle. È inoltre consigliabile che i client federati che ottengono i bindings tramite il recupero delle politiche verifichino che considerino attendibili gli emettitori nella catena di fiducia federata ottenuta. Per altre informazioni sugli scenari di federazione, vedere Federazione.
Gli scarichi di memoria possono rivelare informazioni sulle richieste
Quando un'applicazione ha esito negativo, i file di log, ad esempio quelli prodotti da Dr. Watson, possono contenere le informazioni sull'attestazione. Queste informazioni non devono essere esportate in altre entità, ad esempio i team di supporto; in caso contrario, vengono esportate anche le informazioni sull'attestazione che contengono dati privati. È possibile attenuare questo problema non inviando i file di log a entità sconosciute.
Indirizzi endpoint
Un indirizzo endpoint contiene le informazioni necessarie per comunicare con un endpoint. La sicurezza SOAP deve includere l'indirizzo completo nei messaggi di negoziazione di sicurezza scambiati per negoziare una chiave simmetrica tra un client e un server. Poiché la negoziazione di sicurezza è un processo bootstrap, le intestazioni degli indirizzi non possono essere crittografate durante questo processo. Pertanto, l'indirizzo non deve contenere dati riservati; in caso contrario, porta ad attacchi di divulgazione di informazioni.
Certificati trasferiti non crittografati
Quando si usa un certificato X.509 per autenticare un client, il certificato viene trasferito in chiaro all'interno dell'intestazione SOAP. Essere consapevoli di questo come una potenziale divulgazione di informazioni personali (PII). Questo non è un problema in modalità TransportWithMessageCredential, in cui l'intero messaggio viene crittografato con la sicurezza a livello di trasporto.
Riferimenti al servizio
Un riferimento al servizio è un riferimento a un altro servizio. Ad esempio, un servizio può passare un riferimento al servizio a un client durante un'operazione. Il riferimento al servizio viene usato anche con un verificatore di identità di attendibilità, un componente interno che garantisce l'identità dell'entità di destinazione prima di divulgare informazioni quali i dati dell'applicazione o le credenziali alla destinazione. Se l'identità di attendibilità remota non può essere verificata o non è corretta, il mittente deve assicurarsi che non siano stati divulgati dati che potrebbero compromettere se stessi, l'applicazione o l'utente.
Le mitigazioni includono quanto segue:
Si presuppone che i riferimenti al servizio siano attendibili. Prestare attenzione ogni volta che si trasferiscono istanze di riferimento del servizio per assicurarsi che non siano state manomesse.
Alcune applicazioni possono presentare un'esperienza utente che consente la creazione interattiva di attendibilità in base ai dati nel riferimento al servizio e ai dati di attendibilità comprovati dall'host remoto. WCF fornisce punti di estendibilità per tale struttura, ma l'utente deve implementarli.
NTLM
Per impostazione predefinita, nell'ambiente di dominio Windows l'autenticazione di Windows usa il protocollo Kerberos per autenticare e autorizzare gli utenti. Se il protocollo Kerberos non può essere usato per qualche motivo, NT LAN Manager (NTLM) viene usato come fallback. È possibile disabilitare questo comportamento impostando la AllowNtlm proprietà su false. I problemi da tenere presenti quando si consente NTLM includono:
NTLM espone il nome utente del client. Se il nome utente deve essere mantenuto riservato, impostare la proprietà del binding
AllowNTLMsufalse.NTLM non fornisce l'autenticazione server. Pertanto, il client non può garantire che stia comunicando con il servizio corretto quando si usa NTLM come protocollo di autenticazione.
Specificare credenziali del client o identità non valida forza l'utilizzo di NTLM
Quando si crea un client, specificando le credenziali client senza un nome di dominio o specificando un'identità del server non valida, viene utilizzato NTLM anziché il protocollo Kerberos (se la AllowNtlm proprietà è impostata su true). Poiché NTLM non esegue l'autenticazione server, le informazioni possono essere potenzialmente divulgate.
Ad esempio, è possibile specificare le credenziali client di Windows senza un nome di dominio, come illustrato nel codice Visual C# seguente.
MyChannelFactory.Credentials.Windows.ClientCredential = new System.Net.NetworkCredential("username", "password");
Il codice non specifica un nome di dominio e pertanto verrà usato NTLM.
Se il dominio viene specificato, ma viene specificato un nome principale del servizio non valido utilizzando la funzionalità d'identità dell'endpoint, allora viene usato NTLM. Per altre informazioni sulla modalità di specifica dell'identità dell'endpoint, vedere Identità del servizio e autenticazione.