Il middleware ASP.NET Core OpenId Connessione consente all'app di intercettare la chiamata all'endpoint di disconnessione di Microsoft Identity Platform fornendo un evento OpenId Connessione denominatoOnRedirectToIdentityProviderForSignOut
Usare durate limitate per i token di firma di accesso condiviso generati
Titolo
Dettagli
Componente
Dispositivo IoT
Fase SDL
Creazione
Tecnologie applicabili
Generica
Attributi
N/D
Riferimenti
N/D
Passaggi
I token di firma di accesso condiviso generati per l'autenticazione all'hub IoT di Azure devono avere un periodo di validità limitato. Impostare durate minime per i token di firma di accesso condiviso per limitare il periodo di tempo in cui i token possono essere riprodotti nel caso in cui vengano compromessi.
Usare durate minime per i token delle risorse generati
Titolo
Dettagli
Componente
Azure DocumentDB
Fase SDL
Creazione
Tecnologie applicabili
Generica
Attributi
N/D
Riferimenti
N/D
Passaggi
Ridurre l'intervallo di tempo del token della risorsa a un valore minimo necessario. I token delle risorse hanno un intervallo di tempo valido predefinito di 1 ora.
Implementare la disconnessione appropriata con i metodi WsFederation quando si usa AD FS
Titolo
Dettagli
Componente
File system distribuito di Azure
Fase SDL
Creazione
Tecnologie applicabili
Generica
Attributi
N/D
Riferimenti
N/D
Passaggi
Se l'applicazione si basa sul token del servizio token di sicurezza rilasciato da AD FS, il gestore eventi di disconnessione chiamerà il metodo WSFederationAuthenticationModule.FederatedSignOut() per disconnettere l'utente. Verrà anche eliminata definitivamente la sessione corrente e il valore del token della sessione verrà reimpostato e reso null.
Esempio
[HttpPost, ValidateAntiForgeryToken]
[Authorization]
public ActionResult SignOut(string redirectUrl)
{
if (!this.User.Identity.IsAuthenticated)
{
return this.View("LogOff", null);
}
// Removes the user profile.
this.Session.Clear();
this.Session.Abandon();
HttpContext.Current.Response.Cookies.Add(new System.Web.HttpCookie("ASP.NET_SessionId", string.Empty)
{
Expires = DateTime.Now.AddDays(-1D),
Secure = true,
HttpOnly = true
});
// Signs out at the specified security token service (STS) by using the WS-Federation protocol.
Uri signOutUrl = new Uri(FederatedAuthentication.WSFederationAuthenticationModule.Issuer);
Uri replyUrl = new Uri(FederatedAuthentication.WSFederationAuthenticationModule.Realm);
if (!string.IsNullOrEmpty(redirectUrl))
{
replyUrl = new Uri(FederatedAuthentication.WSFederationAuthenticationModule.Realm + redirectUrl);
}
// Signs out of the current session and raises the appropriate events.
var authModule = FederatedAuthentication.WSFederationAuthenticationModule;
authModule.SignOut(false);
// Signs out at the specified security token service (STS) by using the WS-Federation
// protocol.
WSFederationAuthenticationModule.FederatedSignOut(signOutUrl, replyUrl);
return new RedirectResult(redirectUrl);
}
Implementare la disconnessione appropriata quando si usa Identity Server
Identity Server supporta la federazione con i provider di identità eterni. Quando un utente si disconnette da un provider di identità upstream, a seconda del protocollo usato, potrebbe essere possibile ricevere una notifica quando l'utente si disconnette. Consente a IdentityServer di notificare ai client in modo che possano disconnettere l'utente. Per informazioni dettagliate sull'implementazione, vedere la documentazione nella sezione riferimenti.
Le applicazioni disponibili tramite HTTPS devono usare cookie sicuri
I cookie in genere sono accessibili solo per il dominio per il cui ambito sono stati definiti. La definizione di "dominio" purtroppo non include il protocollo, quindi i cookie creati tramite HTTPS sono accessibile tramite HTTP. L'attributo "secure" indica al browser che il cookie deve essere disponibile solo tramite HTTPS. Assicurarsi che tutti i cookie impostati tramite HTTPS usino l'attributo secure. Il requisito può essere applicato nel file web.config impostando l'attributo requireSSL su true. Si tratta dell'approccio da preferire perché applicherà l'attributo secure per tutti i cookie correnti e futuri senza dover apportare altre modifiche al codice.
L'impostazione viene applicata anche se viene usato HTTP per accedere all'applicazione. Se viene usato HTTP per accedere all'applicazione, l'impostazione interrompe l'applicazione perché i cookie vengono impostati con l'attributo secure e il browser non li invierà di nuovo all'applicazione.
Titolo
Dettagli
Componente
Applicazione Web
Fase SDL
Creazione
Tecnologie applicabili
Web Form, MVC 5
Attributi
Tipo di ambiente: locale
Riferimenti
N/D
Passaggi
Quando l'applicazione Web è la relying party e l'IdP è il server AD FS, l'attributo secure del token FedAuth può essere configurato impostando requireSSL su True nella sezione system.identityModel.services di web.config:
Esempio
<system.identityModel.services>
<federationConfiguration>
<!-- Set requireSsl=true; domain=application domain name used by FedAuth cookies (Ex: .gdinfra.com); -->
<cookieHandler requireSsl="true" persistentSessionLifetime="0.0:20:0" />
....
</federationConfiguration>
</system.identityModel.services>
Tutte le applicazioni basate su http devono specificare solo http per la definizione dei cookie
Per mitigare il rischio di diffusione di informazioni con un attacco di tipo cross-site scripting (XSS), un nuovo attributo (httpOnly) è stato introdotto nei cookie ed è supportato da tutti i principali browser. L'attributo specifica che un cookie non è accessibile tramite script. Usando i cookie HttpOnly, un'applicazione Web riduce la possibilità che le informazioni sensibili contenute nel cookie possano essere sottratte tramite script e inviate al sito Web di un utente malintenzionato.
Esempio
Tutte le applicazioni basate su HTTP che usano cookie devono specificare HttpOnly nella definizione del cookie, implementando la configurazione seguente in web.config:
Il valore della proprietà RequireSSL viene impostato nel file di configurazione per un'applicazione ASP.NET usando l'attributo requireSSL dell'elemento di configurazione. È possibile specificare nel file Web.config per l'applicazione ASP.NET se Transport Layer Security (TLS), noto in precedenza come SSL (Secure Sockets Layer), è necessario per restituire il cookie di autenticazione basata su form al server impostando l'attributo requireSSL.
Esempio
L'esempio di codice seguente imposta l'attributo requireSSL nel file Web.config.
Mitigare il rischio di attacchi basati su richieste intersito false nelle pagine Web ASP.NET
Titolo
Dettagli
Componente
Applicazione Web
Fase SDL
Creazione
Tecnologie applicabili
Generica
Attributi
N/D
Riferimenti
N/D
Passaggi
Richiesta intersito falsa (CSRF o XSRF) è un tipo di attacco in cui un utente malintenzionato può eseguire azioni nel contesto di protezione della sessione stabilita di un utente diverso in un sito web. L'obiettivo è quello di modificare o eliminare il contenuto, se il sito web di destinazione si affida esclusivamente ai cookie di sessione per autenticare la richiesta ricevuta. Un utente malintenzionato potrebbe sfruttare questa vulnerabilità acquisendo il browser di un altro utente per caricare un URL con un comando da un sito vulnerabile a cui l'utente è già connesso. Un utente malintenzionato può raggiungere questo scopo in diversi modi, ad esempio ospitando un sito Web diverso che carica una risorsa dal server vulnerabile o spingendo l'utente a fare clic su un collegamento. L'attacco può essere evitato se il server invia un token aggiuntivo al client, richiede al client di includere tale token in tutte le richieste future e verifica che tutte le richieste future includano un token relativo alla sessione corrente, ad esempio usando AntiForgeryToken o ViewState di ASP.NET.
Form ASP.NET MVC e contro le richieste intersito: usare il metodo helper AntiForgeryToken in Views. Inserire Html.AntiForgeryToken() nel form, ad esempio,
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
Esempio
Html.AntiForgeryToken() assegna contemporaneamente al visitatore un cookie denominato __RequestVerificationToken, con lo stesso valore del valore nascosto casuale illustrato sopra. Per convalidare un post del form in ingresso, aggiungere quindi il filtro [ValidateAntiForgeryToken] al metodo azione di destinazione. Ad esempio:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Filtro di autorizzazione che controlla che:
La richiesta in ingresso abbia un cookie denominato __RequestVerificationToken.
La richiesta in ingresso ha un cookie Request.Form denominato __RequestVerificationToken
Questi valori del cookie e di Request.Form corrispondono. Presumendo che sia tutto a posto, la richiesta viene completata normalmente. In caso contrario, si verifica un errore di autorizzazione e viene visualizzato il messaggio "Token antifalsificazione non specificato o non valido".
Esempio
Prevenzione di richieste intersito false e AJAX: il token del form può rappresentare un problema per le richieste AJAX, perché una richiesta AJAX potrebbe inviare dati JSON, non dati in formato HTML. Una soluzione consiste nell'inviare i token in un'intestazione HTTP personalizzata. Il codice seguente usa la sintassi Razor per generare i token e quindi li aggiunge a una richiesta AJAX.
<script>
@functions{
public string TokenHeaderValue()
{
string cookieToken, formToken;
AntiForgery.GetTokens(null, out cookieToken, out formToken);
return cookieToken + ":" + formToken;
}
}
$.ajax("api/values", {
type: "post",
contentType: "application/json",
data: { }, // JSON data goes here
dataType: "json",
headers: {
'RequestVerificationToken': '@TokenHeaderValue()'
}
});
</script>
Esempio
Quando si elabora la richiesta, estrarre i token dall'intestazione della richiesta. Chiamare quindi il metodo AntiForgery.Validate per convalidare i token. Il metodo Validate genera un'eccezione se i token non sono validi.
Gli attacchi basati su richieste intersito false nelle applicazioni basate su Web Form possono essere mitigati impostando ViewStateUserKey su una stringa casuale diversa per ogni utente (ID utente o, meglio ancora, ID sessione). Per diversi motivi tecnici e legati ai social network, l'ID sessione è molto più appropriato perché non è prevedibile, scade ed è diverso per ogni utente.
Esempio
Ecco il codice che è necessario avere in tutte le pagine:
Il timeout della sessione rappresenta l'evento che si verifica quando un utente non esegue alcuna azione in un sito Web durante un intervallo (definito dal server Web). L'evento sul lato server imposta lo stato della sessione utente come "non valida" (ad esempio, "non più usata") e indica al server Web di eliminarla definitivamente (eliminando tutti i dati contenuti). L'esempio di codice seguente imposta l'attributo del timeout della sessione su 15 minuti nel file Web.config.
Quando l'applicazione Web è la relying party e il file system distribuito di Azure è ADFS, la durata dei cookie di autenticazione, token FedAuth, può essere impostata tramite la configurazione seguente nel file web.config:
Esempio
<system.identityModel.services>
<federationConfiguration>
<!-- Set requireSsl=true; domain=application domain name used by FedAuth cookies (Ex: .gdinfra.com); -->
<cookieHandler requireSsl="true" persistentSessionLifetime="0.0:15:0" />
<!-- Set requireHttps=true; -->
<wsFederation passiveRedirectEnabled="true" issuer="http://localhost:39529/" realm="https://localhost:44302/" reply="https://localhost:44302/" requireHttps="true"/>
<!--
Use the code below to enable encryption-decryption of claims received from ADFS. Thumbprint value varies based on the certificate being used.
<serviceCertificate>
<certificateReference findValue="4FBBBA33A1D11A9022A5BF3492FF83320007686A" storeLocation="LocalMachine" storeName="My" x509FindType="FindByThumbprint" />
</serviceCertificate>
-->
</federationConfiguration>
</system.identityModel.services>
Esempio
Anche la durata del token dell'attestazione SAML rilasciato da AD FS deve essere impostato su 15 minuti, eseguendo il comando di PowerShell seguente nel server AD FS:
Implementare la disconnessione appropriata dall'applicazione
Titolo
Dettagli
Componente
Applicazione Web
Fase SDL
Creazione
Tecnologie applicabili
Generica
Attributi
N/D
Riferimenti
N/D
Passaggi
Eseguire la disconnessione appropriata dall'applicazione, quando l'utente fa clic sul pulsante di disconnessione. Durante la disconnessione, l'applicazione deve eliminare definitivamente la sessione dell'utente e anche reimpostare e rendere null il valore del cookie della sessione, oltre a reimpostare e rendere null il valore del cookie di autenticazione. Quando più sessioni sono collegate a una singola identità utente, è anche necessario terminarle collettivamente sul lato server al momento del timeout o della disconnessione. Assicurarsi infine che la funzionalità di disconnessione sia disponibile in ogni pagina.
Mitigare il rischio di attacchi basati su richieste intersito false nelle API Web ASP.NET
Titolo
Dettagli
Componente
API Web
Fase SDL
Creazione
Tecnologie applicabili
Generica
Attributi
N/D
Riferimenti
N/D
Passaggi
Richiesta intersito falsa (CSRF o XSRF) è un tipo di attacco in cui un utente malintenzionato può eseguire azioni nel contesto di protezione della sessione stabilita di un utente diverso in un sito web. L'obiettivo è quello di modificare o eliminare il contenuto, se il sito web di destinazione si affida esclusivamente ai cookie di sessione per autenticare la richiesta ricevuta. Un utente malintenzionato potrebbe sfruttare questa vulnerabilità acquisendo il browser di un altro utente per caricare un URL con un comando da un sito vulnerabile a cui l'utente è già connesso. Un utente malintenzionato può raggiungere questo scopo in diversi modi, ad esempio ospitando un sito Web diverso che carica una risorsa dal server vulnerabile o spingendo l'utente a fare clic su un collegamento. L'attacco può essere evitato se il server invia un token aggiuntivo al client, richiede al client di includere tale token in tutte le richieste future e verifica che tutte le richieste future includano un token relativo alla sessione corrente, ad esempio usando AntiForgeryToken o ViewState di ASP.NET.
Prevenzione di richieste intersito false e AJAX: il token del form può rappresentare un problema per le richieste AJAX, perché una richiesta AJAX potrebbe inviare dati JSON, non dati in formato HTML. Una soluzione consiste nell'inviare i token in un'intestazione HTTP personalizzata. Il codice seguente usa la sintassi Razor per generare i token e quindi li aggiunge a una richiesta AJAX.
Esempio
<script>
@functions{
public string TokenHeaderValue()
{
string cookieToken, formToken;
AntiForgery.GetTokens(null, out cookieToken, out formToken);
return cookieToken + ":" + formToken;
}
}
$.ajax("api/values", {
type: "post",
contentType: "application/json",
data: { }, // JSON data goes here
dataType: "json",
headers: {
'RequestVerificationToken': '@TokenHeaderValue()'
}
});
</script>
Esempio
Quando si elabora la richiesta, estrarre i token dall'intestazione della richiesta. Chiamare quindi il metodo AntiForgery.Validate per convalidare i token. Il metodo Validate genera un'eccezione se i token non sono validi.
Form ASP.NET MVC e contro le richieste intersito: usare il metodo helper AntiForgeryToken in Views. Inserire Html.AntiForgeryToken() nel form, ad esempio,
Nell'esempio precedente verrà generato un output simile al seguente:
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
Esempio
Html.AntiForgeryToken() assegna contemporaneamente al visitatore un cookie denominato __RequestVerificationToken, con lo stesso valore del valore nascosto casuale illustrato sopra. Per convalidare un post del form in ingresso, aggiungere quindi il filtro [ValidateAntiForgeryToken] al metodo azione di destinazione. Ad esempio:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Filtro di autorizzazione che controlla che:
La richiesta in ingresso abbia un cookie denominato __RequestVerificationToken.
La richiesta in ingresso ha un cookie Request.Form denominato __RequestVerificationToken
Questi valori del cookie e di Request.Form corrispondono. Presumendo che sia tutto a posto, la richiesta viene completata normalmente. In caso contrario, si verifica un errore di autorizzazione e viene visualizzato il messaggio "Token antifalsificazione non specificato o non valido".
Titolo
Dettagli
Componente
API Web
Fase SDL
Creazione
Tecnologie applicabili
MVC 5, MVC 6
Attributi
Provider di identità - ADFS, provider di identità - Microsoft Entra ID
Se l'API Web viene protetta con OAuth 2.0, è previsto un token di connessione nell'intestazione della richiesta di autorizzazione e l'accesso alla richiesta viene concesso solo se il token è valido. Diversamente dall'autenticazione basata su cookie, i browser non allegano i token di connessione alle richieste. Il client richiedente deve allegare esplicitamente il token di connessione nell'intestazione della richiesta. Per le API Web ASP.NET protette con OAuth 2.0, i token di connessione vengono quindi considerati una difesa contro gli attacchi basati su richieste intersito false. Tenere presente che, se la parte MVC dell'applicazione usa l'autenticazione basata su form (ad esempio, usa i cookie), dall'app Web MVC devono essere usati token antifalsificazione.
Esempio
All'API Web deve essere comunicato di basarsi SOLO sui token di connessione e non sui cookie. Per questa comunicazione è possibile usare la configurazione seguente nel metodo WebApiConfig.Register:
Il metodo SuppressDefaultHostAuthentication indica all'API Web di ignorare qualsiasi tipo di autenticazione che si verifica prima che la richiesta raggiunga la pipeline dell'API Web, tramite IIS o il middleware OWIN. In questo modo, è possibile limitare l'autenticazione dell'API Web usando solo i token di connessione.