Med ASP.NET Core OpenIdConnect-mellanprogrammet kan appen fånga upp anropet till slutpunkten för Microsofts identitetsplattform utloggning genom att tillhandahålla en OpenIdConnect-händelse med namnetOnRedirectToIdentityProviderForSignOut
Använda begränsad livslängd för genererade SaS-token
Title
Details
Komponent
IoT-enhet
SDL-fas
Skapa
Tillämpliga tekniker
Allmän
Attribut
Ej tillämpligt
Referenser
Ej tillämpligt
Steg
SaS-token som genereras för autentisering till Azure IoT Hub bör ha en begränsad giltighetstid. Behåll Livslängden för SaS-token till ett minimum för att begränsa hur lång tid de kan spelas upp igen om token komprometteras.
Använd minsta livslängd för token för genererade resurstoken
Title
Details
Komponent
Azure Document DB
SDL-fas
Skapa
Tillämpliga tekniker
Allmän
Attribut
Ej tillämpligt
Referenser
Ej tillämpligt
Steg
Minska tidsintervallet för resurstoken till ett minsta värde som krävs. Resurstoken har ett giltigt standardtidsintervall på 1 timme.
Implementera korrekt utloggning med hjälp av WsFederation-metoder när du använder ADFS
Title
Details
Komponent
ADFS
SDL-fas
Skapa
Tillämpliga tekniker
Allmän
Attribut
Ej tillämpligt
Referenser
Ej tillämpligt
Steg
Om programmet förlitar sig på STS-token som utfärdats av ADFS bör händelsehanteraren för utloggning anropa metoden WSFederationAuthenticationModule.FederatedSignOut() för att logga ut användaren. Även den aktuella sessionen ska förstöras och värdet för sessionstoken ska återställas och nullifieras.
Exempel
[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);
}
Implementera korrekt utloggning när du använder Identity Server
IdentityServer stöder möjligheten att federera med externa identitetsprovidrar. När en användare loggar ut från en överordnad identitetsprovider, beroende på vilket protokoll som används, kan det vara möjligt att få ett meddelande när användaren loggar ut. Det gör att IdentityServer kan meddela sina klienter så att de också kan logga ut användaren. I dokumentationen i referensavsnittet finns information om implementeringen.
Program som är tillgängliga via HTTPS måste använda säkra cookies
Cookies är normalt endast tillgängliga för den domän som de var begränsade till. Definitionen av "domän" innehåller tyvärr inte protokollet, så cookies som skapas via HTTPS är tillgängliga via HTTP. Attributet "secure" anger för webbläsaren att cookien endast ska göras tillgänglig via HTTPS. Se till att alla cookies som anges via HTTPS använder det säkra attributet. Kravet kan tillämpas i filen web.config genom att ange attributet requireSSL till true. Det är den bästa metoden eftersom det framtvingar det säkra attributet för alla aktuella och framtida cookies utan att du behöver göra några ytterligare kodändringar.
Inställningen tillämpas även om HTTP används för att komma åt programmet. Om HTTP används för att komma åt programmet bryter inställningen programmet eftersom cookies har angetts med det säkra attributet och webbläsaren inte skickar tillbaka dem till programmet.
Title
Details
Komponent
Webbprogram
SDL-fas
Skapa
Tillämpliga tekniker
Webbformulär, MVC5
Attribut
EnvironmentType – OnPrem
Referenser
Ej tillämpligt
Steg
När webbappen är den förlitande parten och IdP:n är ADFS-server kan FedAuth-tokens säkra attribut konfigureras genom att ange requireSSL till True i system.identityModel.services avsnittet web.config:
Exempel
<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>
Alla http-baserade program ska endast ange http för cookiedefinition
För att minska risken för avslöjande av information med en XSS-attack (cross-site scripting) introducerades ett nytt attribut – httpOnly – för cookies och stöds av alla större webbläsare. Attributet anger att en cookie inte är tillgänglig via skript. Genom att använda HttpOnly-cookies minskar en webbapp risken för att känslig information i cookien kan stjälas via skript och skickas till en angripares webbplats.
Exempel
Alla HTTP-baserade program som använder cookies bör ange HttpOnly i cookiedefinitionen genom att implementera följande konfiguration i web.config:
Egenskapsvärdet RequireSSL anges i konfigurationsfilen för ett ASP.NET program med hjälp av attributet requireSSL för konfigurationselementet. Du kan ange i web.config-filen för ditt ASP.NET-program om TLS (Transport Layer Security), som tidigare kallades SSL (Secure Sockets Layer), krävs för att returnera cookien för formulärautentisering till servern genom att ange attributet requireSSL.
Exempel
I följande kodexempel anges attributet requireSSL i filen Web.config.
Åtgärda förfalskningsattacker (CSRF) mellan webbplatser på ASP.NET webbsidor
Title
Details
Komponent
Webbprogram
SDL-fas
Skapa
Tillämpliga tekniker
Allmän
Attribut
Ej tillämpligt
Referenser
Ej tillämpligt
Steg
Förfalskning av begäranden mellan webbplatser (CSRF eller XSRF) är en typ av attack där en angripare kan utföra åtgärder i säkerhetskontexten för en annan användares etablerade session på en webbplats. Målet är att ändra eller ta bort innehåll, om den riktade webbplatsen enbart förlitar sig på sessionscookies för att autentisera mottagna begäranden. En angripare kan utnyttja den här säkerhetsrisken genom att hämta en annan användares webbläsare för att läsa in en URL med ett kommando från en sårbar webbplats där användaren redan är inloggad. Det finns många sätt för en angripare att göra det, till exempel genom att vara värd för en annan webbplats som läser in en resurs från den sårbara servern eller få användaren att klicka på en länk. Attacken kan förhindras om servern skickar ytterligare en token till klienten, kräver att klienten inkluderar denna token i alla framtida begäranden och verifierar att alla framtida begäranden innehåller en token som gäller för den aktuella sessionen, till exempel genom att använda ASP.NET AntiForgeryToken eller ViewState.
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
Exempel
Samtidigt ger Html.AntiForgeryToken() besökaren en cookie som heter __RequestVerificationToken, med samma värde som det slumpmässiga dolda värdet som visas ovan. För att verifiera ett inkommande formulärinlägg lägger du sedan till filtret [ValidateAntiForgeryToken] i målåtgärdsmetoden. Till exempel:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Auktoriseringsfilter som kontrollerar att:
Den inkommande begäran har en cookie som heter __RequestVerificationToken
Den inkommande begäran har en Request.Form post som heter __RequestVerificationToken
Dessa cookies och Request.Form värden matchar Förutsatt att allt är bra går begäran igenom som vanligt. Men om inte, så har ett auktoriseringsfel med meddelandet "En nödvändig antiförfalskningstoken inte angetts eller var ogiltig".
Exempel
Anti-CSRF och AJAX: Formulärtoken kan vara ett problem för AJAX-begäranden, eftersom en AJAX-begäran kan skicka JSON-data, inte HTML-formulärdata. En lösning är att skicka token i ett anpassat HTTP-huvud. Följande kod använder Razor-syntax för att generera token och lägger sedan till token i en AJAX-begäran.
<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>
Exempel
När du bearbetar begäran extraherar du token från begärandehuvudet. Anropa sedan metoden AntiForgery.Validate för att verifiera token. Metoden Validate utlöser ett undantag om token inte är giltiga.
CSRF-attacker i WebForm-baserade program kan minimeras genom att ange ViewStateUserKey till en slumpmässig sträng som varierar för varje användare – användar-ID eller, ännu bättre, sessions-ID. Av ett antal tekniska och sociala skäl passar sessions-ID mycket bättre eftersom ett sessions-ID är oförutsägbart, överskrider tidsgränsen och varierar per användare.
Exempel
Här är den kod som du behöver ha på alla dina sidor:
Tidsgränsen för sessioner representerar den händelse som inträffar när en användare inte utför någon åtgärd på en webbplats under ett intervall (definierat av webbservern). Händelsen på serversidan ändrar statusen för användarsessionen till "ogiltig" (till exempel "används inte längre") och instruerar webbservern att förstöra den (ta bort alla data som ingår i den). I följande kodexempel anges timeout-sessionsattributet till 15 minuter i filen Web.config.
När webbprogrammet är förlitande part och ADFS är STS kan livslängden för autentiseringscookies – FedAuth-token – anges av följande konfiguration i web.config:
Exempel
<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>
Exempel
Även den ADFS-utfärdade SAML-anspråkstokens livslängd bör anges till 15 minuter genom att köra följande PowerShell-kommando på ADFS-servern:
Utför korrekt utloggning från programmet när användaren trycker på utloggningsknappen. Vid utloggning ska programmet förstöra användarens session och även återställa och nullifiera sessionscookievärde, tillsammans med återställning och nullifiering av cookievärdet för autentisering. När flera sessioner är knutna till en enskild användaridentitet måste de dessutom avslutas kollektivt på serversidan vid timeout eller utloggning. Slutligen kontrollerar du att utloggningsfunktionen är tillgänglig på varje sida.
Åtgärda förfalskningsattacker mellan webbplatser (CSRF) på ASP.NET webb-API:er
Title
Details
Komponent
Webb-API
SDL-fas
Skapa
Tillämpliga tekniker
Allmän
Attribut
Ej tillämpligt
Referenser
Ej tillämpligt
Steg
Förfalskning av begäranden mellan webbplatser (CSRF eller XSRF) är en typ av attack där en angripare kan utföra åtgärder i säkerhetskontexten för en annan användares etablerade session på en webbplats. Målet är att ändra eller ta bort innehåll, om den riktade webbplatsen enbart förlitar sig på sessionscookies för att autentisera mottagna begäranden. En angripare kan utnyttja den här säkerhetsrisken genom att hämta en annan användares webbläsare för att läsa in en URL med ett kommando från en sårbar webbplats där användaren redan är inloggad. Det finns många sätt för en angripare att göra det, till exempel genom att vara värd för en annan webbplats som läser in en resurs från den sårbara servern eller få användaren att klicka på en länk. Attacken kan förhindras om servern skickar ytterligare en token till klienten, kräver att klienten inkluderar denna token i alla framtida begäranden och verifierar att alla framtida begäranden innehåller en token som gäller för den aktuella sessionen, till exempel genom att använda ASP.NET AntiForgeryToken eller ViewState.
Anti-CSRF och AJAX: Formulärtoken kan vara ett problem för AJAX-begäranden, eftersom en AJAX-begäran kan skicka JSON-data, inte HTML-formulärdata. En lösning är att skicka token i ett anpassat HTTP-huvud. Följande kod använder Razor-syntax för att generera token och lägger sedan till token i en AJAX-begäran.
Exempel
<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>
Exempel
När du bearbetar begäran extraherar du token från begärandehuvudet. Anropa sedan metoden AntiForgery.Validate för att verifiera token. Metoden Validate utlöser ett undantag om token inte är giltiga.
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
Exempel
Samtidigt ger Html.AntiForgeryToken() besökaren en cookie som heter __RequestVerificationToken, med samma värde som det slumpmässiga dolda värdet som visas ovan. För att verifiera ett inkommande formulärinlägg lägger du sedan till filtret [ValidateAntiForgeryToken] i målåtgärdsmetoden. Till exempel:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Auktoriseringsfilter som kontrollerar att:
Den inkommande begäran har en cookie som heter __RequestVerificationToken
Den inkommande begäran har en Request.Form post som heter __RequestVerificationToken
Dessa cookies och Request.Form värden matchar Förutsatt att allt är bra går begäran igenom som vanligt. Men om inte, så har ett auktoriseringsfel med meddelandet "En nödvändig antiförfalskningstoken inte angetts eller var ogiltig".
Title
Details
Komponent
Webb-API
SDL-fas
Skapa
Tillämpliga tekniker
MVC5, MVC6
Attribut
Identitetsprovider – ADFS, identitetsprovider – Microsoft Entra-ID
Om webb-API:et skyddas med OAuth 2.0 förväntar den sig en ägartoken i huvudet för auktoriseringsbegäran och beviljar endast åtkomst till begäran om token är giltig. Till skillnad från cookiebaserad autentisering bifogar webbläsare inte ägartoken till begäranden. Den begärande klienten måste uttryckligen bifoga ägartoken i begärandehuvudet. För ASP.NET webb-API:er som skyddas med OAuth 2.0 betraktas därför ägartoken som ett skydd mot CSRF-attacker. Observera att om MVC-delen av programmet använder formulärautentisering (dvs. använder cookies) måste förfalskningstoken användas av MVC-webbappen.
Exempel
Webb-API:et måste informeras om att endast förlita sig på ägartoken och inte på cookies. Det kan göras genom följande konfiguration i WebApiConfig.Register metoden:
Metoden SuppressDefaultHostAuthentication instruerar webb-API:et att ignorera alla autentiseringar som sker innan begäran når webb-API-pipelinen, antingen av IIS eller av OWIN-mellanprogram. På så sätt kan vi begränsa webb-API:et till att endast autentisera med hjälp av ägartoken.