A ASP.NET Core OpenId Csatlakozás köztes szoftver lehetővé teszi, hogy az alkalmazás elfogja a Microsoft Identitásplatform kijelentkezés végpontjának hívását egy OpenId Csatlakozás nevű esemény megadásávalOnRedirectToIdentityProviderForSignOut
Véges élettartam használata a létrehozott SaS-jogkivonatokhoz
Cím
Részletek
Komponens
IoT-eszköz
SDL-fázis
Build
Alkalmazható technológiák
Általános
Attribútumok
N/A
Hivatkozások
N/A
Lépések
Az Azure IoT Hubon történő hitelesítéshez létrehozott SaS-jogkivonatoknak véges lejárati időszakuknak kell lennie. Az SaS-jogkivonat élettartamát tartsa minimálisra, hogy korlátozza az újrajátszható időt, ha a jogkivonatok megsérülnek.
Minimális jogkivonat-élettartam használata a létrehozott erőforrás-jogkivonatokhoz
Cím
Részletek
Komponens
Azure Document DB
SDL-fázis
Build
Alkalmazható technológiák
Általános
Attribútumok
N/A
Hivatkozások
N/A
Lépések
Csökkentse az erőforrás-jogkivonat időidejének minimális értékét. Az erőforrás-jogkivonatok alapértelmezett érvényes időideje 1 óra.
A megfelelő kijelentkezés implementálása WsFederation metódusokkal az ADFS használatakor
Cím
Részletek
Komponens
ADFS
SDL-fázis
Build
Alkalmazható technológiák
Általános
Attribútumok
N/A
Hivatkozások
N/A
Lépések
Ha az alkalmazás az ADFS által kibocsátott STS-jogkivonatra támaszkodik, a kijelentkezési eseménykezelőnek meghívnia kell a WSFederationAuthenticationModule.FederatedSignOut() metódust a felhasználó kijelentkeztetéséhez. Az aktuális munkamenetet is el kell pusztítani, és a munkamenet-jogkivonat értékét alaphelyzetbe kell állítani és érvényteleníteni kell.
Example
[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);
}
A megfelelő kijelentkezés megvalósítása az Identity Server használatakor
Az IdentityServer támogatja a külső identitásszolgáltatókkal való összevonás lehetőségét. Amikor egy felhasználó kijelentkezik egy felsőbb rétegbeli identitásszolgáltatóból, a használt protokolltól függően előfordulhat, hogy értesítést kaphat, amikor a felhasználó kijelentkezik. Lehetővé teszi, hogy az IdentityServer értesítse az ügyfeleit, hogy a felhasználót is kijelentkeztethesse. A megvalósítás részleteiért tekintse meg a dokumentációt a hivatkozások szakaszban.
A HTTPS-en keresztül elérhető alkalmazásoknak biztonságos cookie-kat kell használniuk
A cookie-k általában csak ahhoz a tartományhoz érhetők el, amelyre hatókörük kiterjed. Sajnos a "tartomány" definíciója nem tartalmazza a protokollt, így a HTTPS-en keresztül létrehozott cookie-k HTTP-en keresztül érhetők el. A "secure" attribútum azt jelzi a böngészőnek, hogy a cookie-t csak HTTPS-en keresztül szabad elérhetővé tenni. Győződjön meg arról, hogy a HTTPS-en beállított összes cookie a biztonságos attribútumot használja. A követelmény a web.config fájlban érvényesíthető a requireSSL attribútum igaz értékre állításával. Ez az előnyben részesített megközelítés, mivel minden jelenlegi és jövőbeli cookie esetében kényszeríti a biztonságos attribútumot anélkül, hogy további kódmódosításokat kellene végrehajtania.
A beállítás akkor is érvényes, ha HTTP-t használ az alkalmazás eléréséhez. Ha HTTP-t használ az alkalmazás eléréséhez, a beállítás megszakítja az alkalmazást, mert a cookie-k a biztonságos attribútummal vannak beállítva, és a böngésző nem küldi vissza őket az alkalmazásnak.
Cím
Részletek
Komponens
Webalkalmazás
SDL-fázis
Build
Alkalmazható technológiák
Webes űrlapok, MVC5
Attribútumok
EnvironmentType – OnPrem
Hivatkozások
N/A
Lépések
Ha a webalkalmazás a függő entitás, és az idP ADFS-kiszolgáló, a FedAuth-jogkivonat biztonságos attribútuma úgy konfigurálható, hogy a web.config szakaszban az SSL-nek true system.identityModel.services értéket kell megadnia:
Example
<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>
Minden http-alapú alkalmazásnak csak a cookie-definícióhoz kell http-t megadnia
A webhelyek közötti szkriptelés (XSS) támadással történő információfeltárás kockázatának csökkentése érdekében a cookie-k új attribútuma – httpOnly – lett bevezetve, és az összes fő böngésző támogatja. Az attribútum azt határozza meg, hogy egy cookie nem érhető el szkripttel. A HttpOnly-cookie-k használatával a webalkalmazások csökkentik annak lehetőségét, hogy a cookie-ban található bizalmas információk szkripttel ellophatók, és elküldhetők a támadó webhelyére.
Example
A cookie-kat használó HTTP-alapú alkalmazásoknak meg kell adniuk a HttpOnlyt a cookie-definícióban a web.config következő konfigurációjának implementálásával:
A RequireSSL tulajdonság értéke egy ASP.NET-alkalmazás konfigurációs fájljában van beállítva a konfigurációelem requireSL attribútumával. Az ASP.NET alkalmazás Web.config fájljában megadhatja, hogy a Transport Layer Security (TLS), korábbi nevén SSL (Secure Sockets Layer) szükséges-e az űrlap-hitelesítési cookie kiszolgálóhoz való visszaadásához a requireSSL attribútum beállításával.
Example
Az alábbi példakód a requireSSL attribútumot állítja be a Web.config fájlban.
A webhelyek közötti kérelemhamisítás (CSRF) ASP.NET weblapokon történő támadásainak enyhítése
Cím
Részletek
Komponens
Webalkalmazás
SDL-fázis
Build
Alkalmazható technológiák
Általános
Attribútumok
N/A
Hivatkozások
N/A
Lépések
A helyek közötti hamisítás (CSRF vagy XSRF) egy olyan támadástípus, amelyben a támadó műveleteket hajthat végre egy másik felhasználó által létrehozott munkamenet biztonsági kontextusában egy webhelyen. A cél a tartalom módosítása vagy törlése, ha a megcélzott webhely kizárólag munkamenet-cookie-kra támaszkodik a fogadott kérés hitelesítéséhez. A támadó kihasználhatja ezt a biztonsági rést, ha egy másik felhasználó böngészőjét választva betölt egy URL-címet egy olyan sebezhető webhelyről származó paranccsal, amelyen a felhasználó már bejelentkezett. A támadók többféleképpen is megtehetik ezt, például úgy, hogy egy másik webhelyet üzemeltetnek, amely betölt egy erőforrást a sebezhető kiszolgálóról, vagy ráveszik a felhasználót, hogy kattintson egy hivatkozásra. A támadás megelőzhető, ha a kiszolgáló további jogkivonatot küld az ügyfélnek, megköveteli, hogy az ügyfél minden jövőbeli kérésbe belefoglalja a jogkivonatot, és ellenőrzi, hogy az összes jövőbeli kérés tartalmaz-e egy, az aktuális munkamenethez kapcsolódó jogkivonatot, például az ASP.NET AntiForgeryToken vagy a ViewState használatával.
CsRF-ellenes és ASP.NET MVC-űrlapok – Használja a AntiForgeryToken segédmetódust a nézetekben; helyezzen be egy Html.AntiForgeryToken() űrlapot, például:
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
Example
Ugyanakkor a Html.AntiForgeryToken() egy __RequestVerificationToken nevű cookie-t ad a látogatónak, ugyanazzal az értékkel, mint a fent látható véletlenszerű rejtett érték. Ezután egy bejövő űrlapbeküldés érvényesítéséhez adja hozzá a [ValidateAntiForgeryToken] szűrőt a célműveleti módszerhez. Például:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Engedélyezési szűrő, amely ellenőrzi, hogy:
A bejövő kéréshez egy __RequestVerificationToken nevű cookie tartozik.
A bejövő kérelem egy Request.Form __RequestVerificationToken nevű bejegyzéssel rendelkezik
Ezek a cookie-k és Request.Form értékek egyeznek, feltéve, hogy minden rendben van, a kérés a szokásos módon megy keresztül. Ha azonban nem, akkor a "Kötelező hamisítás elleni jogkivonat nem lett megadva vagy érvénytelen" üzenettel kapcsolatos engedélyezési hiba.
Example
Anti-CSRF és AJAX: Az űrlap jogkivonata problémát jelenthet az AJAX-kérések esetében, mivel az AJAX-kérések JSON-adatokat küldhetnek, nem HTML-űrlapadatokat. Az egyik megoldás a jogkivonatok elküldése egy egyéni HTTP-fejlécben. Az alábbi kód Razor-szintaxissal hozza létre a jogkivonatokat, majd hozzáadja a jogkivonatokat egy AJAX-kérelemhez.
<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>
Example
A kérés feldolgozásakor bontsa ki a jogkivonatokat a kérelem fejlécéből. Ezután hívja meg az AntiForgery.Validate metódust a jogkivonatok érvényesítéséhez. Az Érvényesítési módszer kivételt eredményez, ha a jogkivonatok érvénytelenek.
A WebForm-alapú alkalmazások CSRF-támadásait úgy lehet enyhíteni, hogy a ViewStateUserKey-t véletlenszerű sztringre állítja, amely minden felhasználótól függően változik – felhasználói azonosítóra vagy még jobb, munkamenet-azonosítóra. Számos technikai és társadalmi okból a munkamenet-azonosító sokkal jobban illik, mert a munkamenet-azonosító kiszámíthatatlan, időtúllépési és felhasználónkénti alapon változik.
A munkamenet időtúllépése azt az eseményt jelöli, amely akkor fordul elő, amikor a felhasználó nem hajt végre semmilyen műveletet egy webhelyen egy adott időszak alatt (amelyet a webkiszolgáló határoz meg). Az esemény kiszolgálóoldalon módosítsa a felhasználói munkamenet állapotát "érvénytelen" értékre (például "többé nem használják"), és utasítsa a webkiszolgálót, hogy semmisítse meg (törölje a benne lévő összes adatot). Az alábbi példakód az időtúllépési munkamenet attribútumát 15 percre állítja a Web.config fájlban.
Ha a webalkalmazás függő entitás, és az ADFS az STS, a hitelesítési cookie-k élettartamát – FedAuth-jogkivonatokat – a web.config következő konfigurációja állíthatja be:
Example
<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>
Example
Az ADFS által kiadott SAML-jogcímjogkivonat élettartamát is 15 percre kell állítani az alábbi PowerShell-parancs végrehajtásával az ADFS-kiszolgálón:
Megfelelő kijelentkezés implementálása az alkalmazásból
Cím
Részletek
Komponens
Webalkalmazás
SDL-fázis
Build
Alkalmazható technológiák
Általános
Attribútumok
N/A
Hivatkozások
N/A
Lépések
Amikor a felhasználó lenyomja a kijelentkezés gombot, végezze el a megfelelő kijelentkezést az alkalmazásból. Kijelentkezéskor az alkalmazásnak meg kell semmisítenie a felhasználó munkamenetét, valamint alaphelyzetbe kell állítania és null értékűre kell állítania a munkamenet cookie-értékét, valamint alaphelyzetbe kell állítania és érvénytelenítenie kell a hitelesítési cookie-értéket. Ha több munkamenet is egyetlen felhasználói identitáshoz van kötve, akkor a kiszolgálóoldalon az időtúllépéskor vagy kijelentkezéskor együttesen le kell zárni őket. Végül győződjön meg arról, hogy a Kijelentkezés funkció minden oldalon elérhető.
A ASP.NET webes API-k webhelyközi hamisítási (CSRF) támadásainak elhárításán
Cím
Részletek
Komponens
Webes API
SDL-fázis
Build
Alkalmazható technológiák
Általános
Attribútumok
N/A
Hivatkozások
N/A
Lépések
A helyek közötti hamisítás (CSRF vagy XSRF) egy olyan támadástípus, amelyben a támadó műveleteket hajthat végre egy másik felhasználó által létrehozott munkamenet biztonsági kontextusában egy webhelyen. A cél a tartalom módosítása vagy törlése, ha a megcélzott webhely kizárólag munkamenet-cookie-kra támaszkodik a fogadott kérés hitelesítéséhez. A támadó kihasználhatja ezt a biztonsági rést, ha egy másik felhasználó böngészőjét választva betölt egy URL-címet egy olyan sebezhető webhelyről származó paranccsal, amelyen a felhasználó már bejelentkezett. A támadók többféleképpen is megtehetik ezt, például úgy, hogy egy másik webhelyet üzemeltetnek, amely betölt egy erőforrást a sebezhető kiszolgálóról, vagy ráveszik a felhasználót, hogy kattintson egy hivatkozásra. A támadás megelőzhető, ha a kiszolgáló további jogkivonatot küld az ügyfélnek, megköveteli, hogy az ügyfél minden jövőbeli kérésbe belefoglalja a jogkivonatot, és ellenőrzi, hogy az összes jövőbeli kérés tartalmaz-e egy, az aktuális munkamenethez kapcsolódó jogkivonatot, például az ASP.NET AntiForgeryToken vagy a ViewState használatával.
Anti-CSRF és AJAX: Az űrlap jogkivonata problémát jelenthet az AJAX-kérések esetében, mivel az AJAX-kérések JSON-adatokat küldhetnek, nem HTML-űrlapadatokat. Az egyik megoldás a jogkivonatok elküldése egy egyéni HTTP-fejlécben. Az alábbi kód Razor-szintaxissal hozza létre a jogkivonatokat, majd hozzáadja a jogkivonatokat egy AJAX-kérelemhez.
Example
<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>
Example
A kérés feldolgozásakor bontsa ki a jogkivonatokat a kérelem fejlécéből. Ezután hívja meg az AntiForgery.Validate metódust a jogkivonatok érvényesítéséhez. Az Érvényesítési módszer kivételt eredményez, ha a jogkivonatok érvénytelenek.
Anti-CSRF és ASP.NET MVC űrlapok – Használja az AntiForgeryToken segédmetódust a nézeteken; html.AntiForgeryToken() karaktert helyez el az űrlapon, például
A fenti példa a következőhöz hasonló kimenetet ad ki:
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
Example
Ugyanakkor a Html.AntiForgeryToken() egy __RequestVerificationToken nevű cookie-t ad a látogatónak, ugyanazzal az értékkel, mint a fent látható véletlenszerű rejtett érték. Ezután egy bejövő űrlapbeküldés érvényesítéséhez adja hozzá a [ValidateAntiForgeryToken] szűrőt a célműveleti módszerhez. Például:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Engedélyezési szűrő, amely ellenőrzi, hogy:
A bejövő kéréshez egy __RequestVerificationToken nevű cookie tartozik.
A bejövő kérelem egy Request.Form __RequestVerificationToken nevű bejegyzéssel rendelkezik
Ezek a cookie-k és Request.Form értékek egyeznek, feltéve, hogy minden rendben van, a kérés a szokásos módon megy keresztül. Ha azonban nem, akkor a "Kötelező hamisítás elleni jogkivonat nem lett megadva vagy érvénytelen" üzenettel kapcsolatos engedélyezési hiba.
Cím
Részletek
Komponens
Webes API
SDL-fázis
Build
Alkalmazható technológiák
MVC5, MVC6
Attribútumok
Identitásszolgáltató – ADFS, identitásszolgáltató – Microsoft Entra ID
Ha a webes API az OAuth 2.0-val van védve, akkor egy tulajdonosi jogkivonatot vár az Engedélyezési kérelem fejlécében, és csak akkor biztosít hozzáférést a kéréshez, ha a jogkivonat érvényes. A cookie-alapú hitelesítéssel ellentétben a böngészők nem csatolják a tulajdonosi jogkivonatokat a kérésekhez. A kérelmező ügyfélnek explicit módon kell csatolnia a tulajdonosi jogkivonatot a kérés fejlécében. Ezért az OAuth 2.0 használatával védett ASP.NET webes API-k esetében a tulajdonosi jogkivonatok a CSRF-támadások elleni védelemnek minősülnek. Vegye figyelembe, hogy ha az alkalmazás MVC része űrlaphitelesítést használ (azaz cookie-kat használ), akkor a hamisítás elleni jogkivonatokat az MVC webalkalmazásnak kell használnia.
Example
A webes API-t tájékoztatni kell, hogy CSAK a tulajdonosi jogkivonatokra támaszkodjon, és ne a cookie-kra. Ezt a következő konfigurációval teheti meg a WebApiConfig.Register következő módszerrel:
A SuppressDefaultHostAuthentication metódus arra utasítja a Web API-t, hogy hagyja figyelmen kívül azokat a hitelesítéseket, amelyek azelőtt történnek, hogy a kérés elérné a Webes API-folyamatot IIS vagy OWIN köztes szoftver használatával. Így korlátozhatjuk, hogy a Webes API csak tulajdonosi jogkivonatok használatával hitelesítsen.