Condividi tramite

Elevazione dei privilegi

  • Articolo

L'elevazione dei privilegi si verifica quando all'autore di un attacco vengono concesse autorizzazioni superiori a quelle iniziali. L'autore di un attacco con, ad esempio, un set di privilegi di autorizzazioni "di sola lettura" eleva il set per includere "lettura e scrittura".

Un servizio token di protezione affidabile deve firmare le attestazioni del token SAML

Un token SAML (Security Assertions Markup Language) è un token XML generico che è il tipo predefinito per i token emessi. Un token SAML può essere costruito da un servizio token di protezione (STS, Security Token Service) ritenuto affidabile dal servizio Web finale in uno scambio tipico. Nelle istruzioni, i token SAML contengono attestazioni. L'autore di un attacco può copiare le attestazioni da un token valido, creare un nuovo token SAML e firmarlo con un emittente diverso. Lo scopo è quello di determinare se il server sta convalidando gli emittenti e, in caso negativo, utilizzare la debolezza per costruire token SAML che consentano privilegi oltre quelli previsti da un servizio token di protezione.

La classe SamlAssertion verifica la firma digitale contenuta in un token SAML e SamlSecurityTokenAuthenticator predefinito richiede che i token SAML siano firmati da un certificato X.509 che sia valido quando il CertificateValidationMode della classe IssuedTokenServiceCredential è impostato su ChainTrust. La sola modalità ChainTrust non è sufficiente per stabilire se l'emittente del token SAML è affidabile. I servizi che richiedono un modello di affidabilità più granulare possono utilizzare i criteri di autorizzazione e di imposizione per controllare l'emittente degli insiemi di attestazioni prodotti dall'autenticazione del toke emesso oppure utilizzare le impostazioni di convalida X.509 in IssuedTokenServiceCredential per limitare l'insieme di certificati di firma consentiti. Per ulteriori informazioni, vedere Gestione di attestazioni e autorizzazioni con il modello di identità e Federazione e token emessi.

Cambio di identità senza un contesto di protezione

Quando segue si applica solo a .NET Framework 3.0.

Quando viene stabilita una connessione tra un client e un server, l'identità del client non cambia, tranne che in una situazione: dopo l'apertura del client WCF, se si verificano tutte le condizioni seguenti:

  • Le procedure per stabilire un contesto di protezione (utilizzando una sessione di protezione del trasporto o una sessione di protezione del messaggio) sono disattivate. La proprietà EstablishSecurityContext è impostata su false nel caso della protezione del messaggio oppure, nel caso della protezione del trasporto, è utilizzato un trasporto che non è in grado di stabilire sessioni di protezione. HTTPS è un esempio di questo tipo di trasporto.
  • Viene utilizzata l'autenticazione di Windows.
  • La credenziale non è impostata in modo esplicito.
  • Il servizio viene chiamato nel contesto di protezione rappresentato.

In presenza di queste condizioni, l'identità utilizzata per autenticare il client nei confronti del servizio potrebbe cambiare (potrebbe non essere l'identità rappresentata ma l'identità del processo) dopo l'apertura del client WCF. Ciò accade perché la credenziale di Windows utilizzata per autenticare il client al servizio viene trasmessa con ogni messaggio e la credenziale utilizzata per l'autenticazione viene ottenuta dall'identità di Windows del thread corrente. Se l'identità di Windows del thread corrente cambia (ad esempio, rappresentando un chiamante diverso), potrebbe cambiare anche la credenziale allegata al messaggio e utilizzata per autenticare il client al servizio.

Se si desidera ottenere un comportamento deterministico quando si utilizza l'autenticazione di Windows assieme alla rappresentazione, è necessario impostare in modo esplicito la credenziale di Windows oppure stabilire un contesto di protezione con il servizio. A tale scopo, utilizzare una sessione di protezione del messaggio o una sessione di protezione del trasporto. Il trasporto net.tcp, ad esempio, può fornire una sessione di protezione del trasporto. Quando si chiama il servizio , è inoltre necessario utilizzare solo una versione sincrona delle operazioni client. Se si stabilisce un contesto di protezione del messaggio, non mantenere aperta la connessione al servizio oltre il periodo di rinnovo della sessione configurato, perché l'identità può cambiare anche durante il processo di rinnovo della sessione.

Acquisizione delle credenziali

Quanto segue si applica a .NET Framework versione 3.5 e versioni successive.

Le credenziali utilizzate dal client o dal servizio sono basate sul thread del contesto corrente. Le credenziali vengono ottenute quando si chiama il metodo Open (o BeginOpen, per le chiamate asincrone) del client o del servizio. Per entrambe le classi ServiceHost e ClientBase, i metodi Open e BeginOpen ereditano dai metodi Open e BeginOpen della classe CommunicationObject.

Nota

Quando si utilizza il metodo BeginOpen, non è possibile garantire che le credenziali acquisite siano quelle del processo che chiama il metodo.

I token memorizzati nella cache consentono la riproduzione utilizzando dati obsoleti

WCF utilizza la funzione LogonUser dell'autorità di protezione locale (LSA, Local Security Authority) per autenticare gli utenti tramite nome utente e password. Dato che la funzione di accesso è un'operazione che consuma molte risorse, per aumentare le prestazioni WCF consente di memorizzare nella cache i token che rappresentano gli utenti autenticati. Il meccanismo di memorizzazione nella cache salva i risultati ottenuti da LogonUser per utilizzi successivi. Per impostazione predefinita, questo meccanismo è disattivato. Per attivarlo, impostare la proprietà CacheLogonTokens su true o utilizzare l'attributo cacheLogonTokens di userNameAuthentication element.

È possibile impostare la durata (TTL) per i token memorizzati nella cache, impostando la proprietà CachedLogonTokenLifetime su un TimeSpan, oppure utilizzare l'attributo cachedLogonTokenLifetime dell'elemento userNameAuthentication. L'impostazione predefinita è 15 minuti. Si noti che quando un token è memorizzato nella cache, può essere utilizzato da qualsiasi client che presenti lo stesso nome utente e la stessa password, anche se l'account utente viene eliminato da Windows o se la sua password è stata modificata. Fino alla scadenza del TTL e finché il token non viene rimosso dalla cache, WCF consente all'utente (forse malintenzionato) di autenticarsi.

Per limitare questo problema, ridurre il tempo a disposizione dell'attacco impostando il valore cachedLogonTokenLifetime sull'intervallo di tempo più breve necessario per gli utenti.

Autorizzazione del token emesso: scadenza reimpostata su un valore grande

In certe condizioni, la proprietà ExpirationTime di AuthorizationContext può essere impostata su un valore inaspettatamente superiore (il valore del campo MaxValue meno un giorno, o 20 dicembre 9999).

Ciò si verifica quando si utilizza WSFederationHttpBinding e una qualsiasi delle associazioni fornite dal sistema che ha un token emesso come tipo di credenziale client.

Lo stesso accade anche quando si creano associazioni personalizzate utilizzando uno dei metodi seguenti:

Per limitare questo problema, il criterio di autorizzazione deve controllare l'azione e la data di scadenza di ogni criterio di autorizzazione.

Il servizio utilizza un certificato diverso da quello previsto dal client

In certe condizioni, un client può firmare digitalmente un messaggio con un certificato X.509 e far sì che il servizio recuperi un certificato diverso da quello previsto.

Ciò può verificarsi nelle circostanze seguenti:

  • Il client firma digitalmente un messaggio utilizzando un certificato X.509 e non allega il certificato X.509 al messaggio, ma fa semplicemente riferimento al certificato utilizzando il suo identificatore chiave del soggetto.
  • Il computer del servizio contiene due o più certificati con la stessa chiave pubblica, ma tali certificati contengono informazioni diverse.
  • Il servizio recupera un certificato che corrisponde all'identificatore chiave del soggetto, ma non è quello che il client doveva utilizzare. Quando WCF riceve il messaggio e verifica la firma, WCF esegue il mapping delle informazioni nel certificato X.509 non previsto a un insieme di attestazioni che sono diverse e potenzialmente con privilegi più elevi rispetto a quelli previsti dal client.

Per limitare questo problema, fare riferimento al certificato X.509 in un altro modo, ad esempio utilizzando IssuerSerial.

Vedere anche

Concetti

Diffusione di informazioni
Denial of Service (Negazione del servizio)
Attacchi di tipo replay
Manomissioni
Scenari non supportati

Altre risorse

Considerazioni sulla protezione