Middleware ASP.NET Core OpenId Připojení umožňuje vaší aplikaci zachytit volání koncového bodu odhlášení platformy Microsoft Identity Platform zadáním OpenId Připojení události s názvemOnRedirectToIdentityProviderForSignOut
Použití konečných životností pro vygenerované tokeny SaS
Název
Detaily
Součást
Zařízení IoT
Fáze SDL
Build
Použitelné technologie
Obecná
Atributy
–
Odkazy
–
Kroky
Tokeny SaS vygenerované pro ověřování ve službě Azure IoT Hub by měly mít omezenou dobu vypršení platnosti. Ponechte životnost tokenu SaS na minimum, abyste omezili dobu, po kterou je možné znovu přehrát v případě ohrožení tokenů.
Použití minimální doby životnosti tokenů pro vygenerované tokeny prostředků
Název
Detaily
Součást
Azure Document DB
Fáze SDL
Build
Použitelné technologie
Obecná
Atributy
–
Odkazy
–
Kroky
Snižte časový rozsah tokenu prostředku na minimální požadovanou hodnotu. Tokeny prostředků mají výchozí platný časový rozsah 1 hodinu.
Implementace správného odhlášení pomocí metod WsFederation při použití ADFS
Název
Detaily
Součást
ADFS
Fáze SDL
Build
Použitelné technologie
Obecná
Atributy
–
Odkazy
–
Kroky
Pokud aplikace spoléhá na token STS vystavený službou AD FS, měla by obslužná rutina události odhlášení volat metodu WSFederationAuthenticationModule.FederatedSignOut() pro odhlášení uživatele. Zároveň by se měla zničit aktuální relace a hodnota tokenu relace by měla být resetována a nullified.
Příklad
[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);
}
Implementace správného odhlášení při použití serveru identit
IdentityServer podporuje možnost federovat s externími zprostředkovateli identit. Když se uživatel odhlásí od upstreamového zprostředkovatele identity v závislosti na použitém protokolu, může být možné obdržet oznámení, když se uživatel odhlásí. Umožňuje serveru IdentityServer oznámit svým klientům, aby se mohli odhlásit také od uživatele. Podrobnosti o implementaci najdete v dokumentaci v části reference.
Aplikace dostupné přes PROTOKOL HTTPS musí používat zabezpečené soubory cookie.
Soubory cookie jsou obvykle přístupné pouze pro doménu, pro kterou byly vymezeny. Definice domény bohužel neobsahuje protokol, takže soubory cookie vytvořené přes PROTOKOL HTTPS jsou přístupné přes protokol HTTP. Atribut "secure" označuje prohlížeč, že soubor cookie by měl být zpřístupněn pouze přes HTTPS. Ujistěte se, že všechny soubory cookie nastavené přes PROTOKOL HTTPS používají zabezpečený atribut. Požadavek lze vynutit v souboru web.config nastavením atributu requireSSL na true. Je to upřednostňovaný přístup, protože bude vynucovat zabezpečený atribut pro všechny aktuální a budoucí soubory cookie, aniž by bylo nutné provádět další změny kódu.
Nastavení se vynucuje i v případě, že se pro přístup k aplikaci používá protokol HTTP. Pokud se pro přístup k aplikaci používá protokol HTTP, nastavení aplikaci přeruší, protože soubory cookie jsou nastaveny pomocí zabezpečeného atributu a prohlížeč je neodesílá zpět do aplikace.
Název
Detaily
Součást
Webová aplikace
Fáze SDL
Build
Použitelné technologie
Webové formuláře, MVC5
Atributy
EnvironmentType – OnPrem
Odkazy
–
Kroky
Pokud je webová aplikace předávající stranou a zprostředkovatel identity je server ADFS, může být zabezpečený atribut tokenu FedAuth nakonfigurován nastavením, který vyžaduje hodnotu True v system.identityModel.services části web.config:
Příklad
<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>
Všechna aplikace založená na protokolu HTTP by měla specifikovat pouze http pro definici souboru cookie.
Pro zmírnění rizika zpřístupnění informací při útoku na skriptování mezi weby (XSS) byl do souborů cookie zaveden nový atribut httpOnly a je podporován všemi hlavními prohlížeči. Atribut určuje, že soubor cookie není přístupný prostřednictvím skriptu. Použitím souborů cookie HttpOnly webová aplikace snižuje možnost, že citlivé informace obsažené v souboru cookie mohou být odcizeny prostřednictvím skriptu a odeslány na web útočníka.
Příklad
Všechny aplikace založené na protokolu HTTP, které používají soubory cookie, by měly v definici souboru cookie určit HttpOnly implementací následující konfigurace v souboru web.config:
Hodnota vlastnosti RequireSSL je nastavena v konfiguračním souboru pro ASP.NET aplikace pomocí atributu requireSSL elementu konfigurace. V souboru Web.config pro vaši aplikaci ASP.NET můžete zadat, jestli se k vrácení souboru cookie ověřování pomocí formulářů na server vyžaduje protokol TLS (Transport Layer Layer), který se dříve označuje jako SSL (Secure Sockets Layer), a to nastavením atributu requireSSL.
Příklad
Následující příklad kódu nastaví atribut requireSSL v souboru Web.config.
Zmírnění rizik proti útokům CSRF (Cross-Site Request Forgery) na ASP.NET webových stránkách
Název
Detaily
Součást
Webová aplikace
Fáze SDL
Build
Použitelné technologie
Obecná
Atributy
–
Odkazy
–
Kroky
Typ útoku mezi weby (CSRF nebo XSRF) je typ útoku, ve kterém může útočník provádět akce v kontextu zabezpečení vytvořené relace jiného uživatele na webu. Cílem je upravit nebo odstranit obsah, pokud cílový web spoléhá výhradně na soubory cookie relace k ověření přijaté žádosti. Útočník by mohl tuto chybu zabezpečení zneužít získáním prohlížeče jiného uživatele k načtení adresy URL pomocí příkazu z zranitelného webu, na kterém je uživatel již přihlášený. Existuje mnoho způsobů, jak to útočník udělat, například hostováním jiného webu, který načte prostředek z zranitelného serveru, nebo získáním uživatele, aby klikl na odkaz. Útok může být znemožněný, pokud server odešle klientovi další token, vyžaduje, aby tento token zahrnul do všech budoucích požadavků a ověřil, že všechny budoucí požadavky zahrnují token, který se týká aktuální relace, například pomocí ASP.NET AntiForgeryToken nebo ViewState.
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
Příklad
Současně html.AntiForgeryToken() dává návštěvníku soubor cookie s názvem __RequestVerificationToken se stejnou hodnotou jako náhodná skrytá hodnota zobrazená výše. Pokud chcete ověřit příspěvek příchozího formuláře, přidejte do metody cílové akce filtr [ValidateAntiForgeryToken]. Příklad:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Filtr autorizace, který kontroluje, že:
Příchozí požadavek má soubor cookie s názvem __RequestVerificationToken
Příchozí požadavek obsahuje Request.Form položku s názvem __RequestVerificationToken
Tyto soubory cookie a Request.Form hodnoty odpovídají za předpokladu, že vše je v pořádku, požadavek prochází jako normální. Pokud ne, pak došlo k chybě autorizace se zprávou"Požadovaný token proti padělání nebyl zadán nebo byl neplatný".
Příklad
Anti-CSRF a AJAX: Token formuláře může být problém pro požadavky AJAX, protože požadavek AJAX může odesílat data JSON, nikoli data formuláře HTML. Jedním z řešení je odeslání tokenů do vlastní hlavičky HTTP. Následující kód používá syntaxi Razor k vygenerování tokenů a pak tyto tokeny přidá do požadavku 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>
Příklad
Při zpracování požadavku extrahujte tokeny z hlavičky požadavku. Potom zavolejte AntiForgery.Validate metoda pro ověření tokenů. Metoda Validate vyvolá výjimku, pokud tokeny nejsou platné.
Útoky CSRF v aplikacích založených na webových formulářích je možné zmírnit nastavením ViewStateUserKey na náhodný řetězec, který se pro každého uživatele liší – ID uživatele nebo ještě lépe ID relace. Z mnoha technických a sociálních důvodů je ID relace mnohem vhodnější, protože ID relace je nepředvídatelné, vyprší časový limit a liší se podle jednotlivých uživatelů.
Příklad
Tady je kód, který potřebujete mít na všech stránkách:
Časový limit relace představuje událost, ke které dochází, když uživatel během intervalu (definovaný webovým serverem) neprovádí žádnou akci na webu. Událost na straně serveru změňte stav uživatelské relace na neplatnou (například "už se nepoužívá") a instruujte webovému serveru, aby ho zničil (odstranění všech dat obsažených v ní). Následující příklad kódu nastaví atribut relace časového limitu na 15 minut v souboru Web.config.
Pokud je webová aplikace předávající stranou a služba AD FS je služba TOKENS, může být doba platnosti ověřovacích souborů cookie – tokeny FedAuth – nastavena pomocí následující konfigurace v souboru web.config:
Příklad
<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>
Příklad
Životnost tokenu deklarace identity SAML vydané službou AD FS by také měla být nastavená na 15 minut spuštěním následujícího příkazu PowerShellu na serveru ADFS:
Proveďte správné odhlášení z aplikace, když uživatel stiskne tlačítko odhlásit se. Při odhlášení by aplikace měla zničit relaci uživatele a také resetovat a nullify hodnoty cookie relace spolu s resetováním a nullify ověřovací hodnoty cookie. Pokud je několik relací svázaných s jednou identitou uživatele, musí být společně ukončeny na straně serveru při vypršení časového limitu nebo odhlášení. Nakonec se ujistěte, že je funkce odhlášení dostupná na každé stránce.
Zmírnění útoků CSRF (Cross-Site Request Forgery) na ASP.NET webových rozhraníCH API
Název
Detaily
Součást
Webové rozhraní API
Fáze SDL
Build
Použitelné technologie
Obecná
Atributy
–
Odkazy
–
Kroky
Typ útoku mezi weby (CSRF nebo XSRF) je typ útoku, ve kterém může útočník provádět akce v kontextu zabezpečení vytvořené relace jiného uživatele na webu. Cílem je upravit nebo odstranit obsah, pokud cílový web spoléhá výhradně na soubory cookie relace k ověření přijaté žádosti. Útočník by mohl tuto chybu zabezpečení zneužít získáním prohlížeče jiného uživatele k načtení adresy URL pomocí příkazu z zranitelného webu, na kterém je uživatel již přihlášený. Existuje mnoho způsobů, jak to útočník udělat, například hostováním jiného webu, který načte prostředek z zranitelného serveru, nebo získáním uživatele, aby klikl na odkaz. Útok může být znemožněný, pokud server odešle klientovi další token, vyžaduje, aby tento token zahrnul do všech budoucích požadavků a ověřil, že všechny budoucí požadavky zahrnují token, který se týká aktuální relace, například pomocí ASP.NET AntiForgeryToken nebo ViewState.
Anti-CSRF a AJAX: Token formuláře může být problém pro požadavky AJAX, protože požadavek AJAX může odesílat data JSON, nikoli data formuláře HTML. Jedním z řešení je odeslání tokenů do vlastní hlavičky HTTP. Následující kód používá syntaxi Razor k vygenerování tokenů a pak tyto tokeny přidá do požadavku AJAX.
Příklad
<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>
Příklad
Při zpracování požadavku extrahujte tokeny z hlavičky požadavku. Potom zavolejte AntiForgery.Validate metoda pro ověření tokenů. Metoda Validate vyvolá výjimku, pokud tokeny nejsou platné.
Ve výše uvedeném příkladu bude výstup vypadat přibližně takto:
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
Příklad
Současně html.AntiForgeryToken() dává návštěvníku soubor cookie s názvem __RequestVerificationToken se stejnou hodnotou jako náhodná skrytá hodnota zobrazená výše. Pokud chcete ověřit příspěvek příchozího formuláře, přidejte do metody cílové akce filtr [ValidateAntiForgeryToken]. Příklad:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Filtr autorizace, který kontroluje, že:
Příchozí požadavek má soubor cookie s názvem __RequestVerificationToken
Příchozí požadavek obsahuje Request.Form položku s názvem __RequestVerificationToken
Tyto soubory cookie a Request.Form hodnoty odpovídají za předpokladu, že vše je v pořádku, požadavek prochází jako normální. Pokud ne, pak došlo k chybě autorizace se zprávou"Požadovaný token proti padělání nebyl zadán nebo byl neplatný".
Název
Detaily
Součást
Webové rozhraní API
Fáze SDL
Build
Použitelné technologie
MVC5, MVC6
Atributy
Zprostředkovatel identity – ADFS, zprostředkovatel identity – Microsoft Entra ID
Pokud je webové rozhraní API zabezpečené pomocí OAuth 2.0, očekává nosný token v hlavičce žádosti o autorizaci a udělí přístup k požadavku pouze v případě, že je token platný. Na rozdíl od ověřování na základě souborů cookie nepřipojí prohlížeče nosné tokeny k žádostem. Žádající klient musí explicitně připojit nosný token v hlavičce požadavku. Proto pro ASP.NET webová rozhraní API chráněná pomocí OAuth 2.0 se nosné tokeny považují za ochranu před útoky CSRF. Upozorňujeme, že pokud část aplikace MVC používá ověřování pomocí formulářů (tj. používá soubory cookie), musí webová aplikace MVC používat anti-forgery tokeny.
Příklad
Webové rozhraní API musí být informováno, aby se spoléhalo pouze na nosné tokeny, a ne na soubory cookie. To lze provést pomocí následující konfigurace v WebApiConfig.Register metodě:
Metoda SuppressDefaultHostAuthentication říká webovému rozhraní API, aby ignorovala veškeré ověřování, ke kterému dojde dříve, než požadavek dosáhne kanálu webového rozhraní API, a to buď službou IIS, nebo middlewarem OWIN. Tímto způsobem můžeme webové rozhraní API omezit na ověřování pouze pomocí nosných tokenů.
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu: https://aka.ms/ContentUserFeedback.