Met de ASP.NET Core OpenId Verbinding maken middleware kan uw app de aanroep naar het afmeldingseindpunt van het Microsoft Identity Platform onderscheppen door een OpenId op te geven Verbinding maken gebeurtenis met de naamOnRedirectToIdentityProviderForSignOut
Eindige levensduur gebruiken voor gegenereerde SaS-tokens
Title
Details
Onderdeel
IoT-apparaat
SDL-fase
Bouwen
Toepasselijke technologieën
Algemeen
Kenmerken
N.v.t.
Naslaginformatie
N.v.t.
Stappen
SaS-tokens die zijn gegenereerd voor verificatie bij Azure IoT Hub, moeten een eindige verloopperiode hebben. Bewaar de levensduur van het SaS-token tot een minimum om de hoeveelheid tijd te beperken die ze opnieuw kunnen worden afgespeeld voor het geval de tokens worden gecompromitteerd.
Minimale levensduur van tokens gebruiken voor gegenereerde resourcetokens
Title
Details
Onderdeel
Azure Document DB
SDL-fase
Bouwen
Toepasselijke technologieën
Algemeen
Kenmerken
N.v.t.
Naslaginformatie
N.v.t.
Stappen
Verminder de tijdsduur van het resourcetoken tot een minimumwaarde die is vereist. Resourcetokens hebben een standaard geldige periode van 1 uur.
De juiste afmelding implementeren met WsFederation-methoden bij het gebruik van ADFS
Title
Details
Onderdeel
ADFS
SDL-fase
Bouwen
Toepasselijke technologieën
Algemeen
Kenmerken
N.v.t.
Naslaginformatie
N.v.t.
Stappen
Als de toepassing afhankelijk is van STS-token dat is uitgegeven door ADFS, moet de gebeurtenis-handler voor afmelden WSFederationAuthenticationModule.FederatedSignOut() aanroepen om de gebruiker af te melden. De huidige sessie moet ook worden vernietigd en de waarde van het sessietoken moet opnieuw worden ingesteld en null zijn.
voorbeeld
[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);
}
De juiste afmelding implementeren bij het gebruik van Identity Server
IdentityServer ondersteunt de mogelijkheid om te federeren met externe id-providers. Wanneer een gebruiker zich afmeldt bij een upstream-id-provider, afhankelijk van het gebruikte protocol, kan het mogelijk zijn om een melding te ontvangen wanneer de gebruiker zich afmeldt. Hiermee kan IdentityServer de clients op de hoogte stellen, zodat ze de gebruiker ook kunnen afmelden. Raadpleeg de documentatie in de sectie met verwijzingen voor de implementatiedetails.
Toepassingen die beschikbaar zijn via HTTPS, moeten beveiligde cookies gebruiken
Cookies zijn normaal gesproken alleen toegankelijk voor het domein waarvoor ze zijn gericht. Helaas bevat de definitie van 'domein' het protocol niet, zodat cookies die via HTTPS worden gemaakt, toegankelijk zijn via HTTP. Het kenmerk 'veilig' geeft aan de browser aan dat de cookie alleen beschikbaar moet worden gesteld via HTTPS. Zorg ervoor dat alle cookies die via HTTPS zijn ingesteld, gebruikmaken van het beveiligde kenmerk. De vereiste kan worden afgedwongen in het web.config-bestand door het kenmerk requireSSL in te stellen op true. Het is de voorkeursbenadering, omdat hiermee het veilige kenmerk wordt afgedwongen voor alle huidige en toekomstige cookies zonder dat u aanvullende codewijzigingen hoeft aan te brengen.
De instelling wordt afgedwongen, zelfs als HTTP wordt gebruikt voor toegang tot de toepassing. Als HTTP wordt gebruikt om toegang te krijgen tot de toepassing, wordt de toepassing verbroken omdat de cookies zijn ingesteld met het beveiligde kenmerk en de browser deze niet terugstuurt naar de toepassing.
Title
Details
Onderdeel
Webtoepassing
SDL-fase
Bouwen
Toepasselijke technologieën
Webformulieren, MVC5
Kenmerken
EnvironmentType - OnPrem
Naslaginformatie
N.v.t.
Stappen
Wanneer de webtoepassing de Relying Party is en de IdP ADFS-server is, kan het beveiligde kenmerk van het FedAuth-token worden geconfigureerd door instelling vereist datSSL waar is in system.identityModel.services de sectie web.config:
voorbeeld
<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>
Alle http-gebaseerde toepassingen moeten alleen http opgeven voor cookiedefinitie
Om het risico op openbaarmaking van informatie met een XSS-aanval (cross-site scripting) te beperken, is een nieuw kenmerk , httpOnly, geïntroduceerd in cookies en wordt ondersteund door alle belangrijke browsers. Het kenmerk geeft aan dat een cookie niet toegankelijk is via een script. Door HttpOnly-cookies te gebruiken, vermindert een webtoepassing de mogelijkheid dat gevoelige informatie in de cookie kan worden gestolen via een script en naar de website van een aanvaller kan worden verzonden.
voorbeeld
Alle HTTP-toepassingen die cookies gebruiken, moeten HttpOnly in de cookiedefinitie opgeven door de volgende configuratie in web.config te implementeren:
De waarde van de eigenschap RequireSSL wordt ingesteld in het configuratiebestand voor een ASP.NET toepassing met behulp van het kenmerk requireSSL van het configuratie-element. U kunt in het Web.config-bestand voor uw ASP.NET toepassing opgeven of Transport Layer Security (TLS), voorheen SSL (Secure Sockets Layer) wordt genoemd, vereist is om de cookie voor formulierverificatie naar de server te retourneren door het kenmerk requireSSL in te stellen.
voorbeeld
In het volgende codevoorbeeld wordt het kenmerk RequireSSL ingesteld in het web.config-bestand.
Beperken tegen CSRF-aanvallen (Cross-Site Request Forgery) op ASP.NET webpagina's
Title
Details
Onderdeel
Webtoepassing
SDL-fase
Bouwen
Toepasselijke technologieën
Algemeen
Kenmerken
N.v.t.
Naslaginformatie
N.v.t.
Stappen
Aanvraagvervalsing op meerdere sites (CSRF of XSRF) is een type aanval waarbij een aanvaller acties kan uitvoeren in de beveiligingscontext van de tot stand gebrachte sessie van een andere gebruiker op een website. Het doel is om inhoud te wijzigen of te verwijderen, als de doelwebsite uitsluitend afhankelijk is van sessiecookies om ontvangen aanvragen te verifiëren. Een aanvaller kan dit beveiligingsprobleem misbruiken door de browser van een andere gebruiker een URL te laten laden met een opdracht van een kwetsbare site waarop de gebruiker al is aangemeld. Er zijn veel manieren waarop een aanvaller dit kan doen, bijvoorbeeld door een andere website te hosten die een resource van de kwetsbare server laadt of de gebruiker op een koppeling te laten klikken. De aanval kan worden voorkomen als de server een extra token naar de client verzendt, vereist dat de client dat token opneemt in alle toekomstige aanvragen en controleert of alle toekomstige aanvragen een token bevatten dat betrekking heeft op de huidige sessie, zoals het gebruik van de ASP.NET AntiForgeryToken of ViewState.
Anti-CSRF- en ASP.NET MVC-formulieren: gebruik de AntiForgeryToken helpermethode voor weergaven; plaats een Html.AntiForgeryToken() in het formulier, bijvoorbeeld
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
voorbeeld
Tegelijkertijd geeft Html.AntiForgeryToken() de bezoeker een cookie met de naam __RequestVerificationToken, met dezelfde waarde als de willekeurige verborgen waarde die hierboven wordt weergegeven. Als u vervolgens een binnenkomend formulierbericht wilt valideren, voegt u het filter [ValidateAntiForgeryToken] toe aan de doelactiemethode. Bijvoorbeeld:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Autorisatiefilter waarmee wordt gecontroleerd of:
De binnenkomende aanvraag heeft een cookie met de naam __RequestVerificationToken
De binnenkomende aanvraag heeft een vermelding met de Request.Form naam __RequestVerificationToken
Deze cookie en Request.Form waarden komen overeen, ervan uitgaande dat alles goed is, de aanvraag wordt als normaal doorlopen. Maar als dat niet het probleem is, krijgt u een autorisatiefout met het bericht 'Er is geen vereist antivervalsingstoken opgegeven of ongeldig'.
voorbeeld
Anti-CSRF en AJAX: het formuliertoken kan een probleem zijn voor AJAX-aanvragen, omdat een AJAX-aanvraag JSON-gegevens kan verzenden, niet HTML-formuliergegevens. Een oplossing is het verzenden van de tokens in een aangepaste HTTP-header. De volgende code maakt gebruik van Razor-syntaxis om de tokens te genereren en voegt vervolgens de tokens toe aan een AJAX-aanvraag.
<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>
voorbeeld
Wanneer u de aanvraag verwerkt, extraheert u de tokens uit de aanvraagheader. Roep vervolgens de methode AntiForgery.Validate aan om de tokens te valideren. Met de validatiemethode wordt een uitzondering gegenereerd als de tokens niet geldig zijn.
CSRF-aanvallen in WebForm-toepassingen kunnen worden beperkt door ViewStateUserKey in te stellen op een willekeurige tekenreeks die varieert voor elke gebruiker: gebruikers-id of, beter nog, sessie-id. Om een aantal technische en sociale redenen is sessie-id veel beter geschikt omdat een sessie-id onvoorspelbaar is, er een time-out optreedt en per gebruiker varieert.
voorbeeld
Dit is de code die u op al uw pagina's moet hebben:
Sessietime-out vertegenwoordigt de gebeurtenis die optreedt wanneer een gebruiker tijdens een interval geen actie op een website uitvoert (gedefinieerd door webserver). De gebeurtenis, aan de serverzijde, wijzigt de status van de gebruikerssessie in 'ongeldig' (bijvoorbeeld 'niet meer gebruikt') en instrueert de webserver om deze te vernietigen (alle gegevens in de sessie verwijderen). In het volgende codevoorbeeld wordt het time-outsessiekenmerk ingesteld op 15 minuten in het web.config-bestand.
Wanneer de webtoepassing Relying Party is en ADFS de STS is, kan de levensduur van de verificatiecookies - FedAuth-tokens - worden ingesteld door de volgende configuratie in web.config:
voorbeeld
<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>
voorbeeld
De levensduur van het ADFS uitgegeven SAML-claimtoken moet ook worden ingesteld op 15 minuten door de volgende PowerShell-opdracht uit te voeren op de ADFS-server:
De juiste afmelding implementeren vanuit de toepassing
Title
Details
Onderdeel
Webtoepassing
SDL-fase
Bouwen
Toepasselijke technologieën
Algemeen
Kenmerken
N.v.t.
Naslaginformatie
N.v.t.
Stappen
Voer de juiste afmelding uit vanuit de toepassing wanneer de gebruiker op de knop Afmelden drukt. Bij afmelding moet de toepassing de sessie van de gebruiker vernietigen en ook de cookiewaarde van de sessie opnieuw instellen en nullificeren, samen met het opnieuw instellen en nullificeren van de cookiewaarde voor verificatie. Wanneer meerdere sessies zijn gekoppeld aan één gebruikersidentiteit, moeten ze ook gezamenlijk worden beëindigd aan de serverzijde tijdens time-out of afmelding. Zorg er ten slotte voor dat afmeldingsfunctionaliteit beschikbaar is op elke pagina.
Beperken tegen CSRF-aanvallen (Cross-Site Request Forgery) op ASP.NET web-API's
Title
Details
Onderdeel
Web-API
SDL-fase
Bouwen
Toepasselijke technologieën
Algemeen
Kenmerken
N.v.t.
Naslaginformatie
N.v.t.
Stappen
Aanvraagvervalsing op meerdere sites (CSRF of XSRF) is een type aanval waarbij een aanvaller acties kan uitvoeren in de beveiligingscontext van de tot stand gebrachte sessie van een andere gebruiker op een website. Het doel is om inhoud te wijzigen of te verwijderen, als de doelwebsite uitsluitend afhankelijk is van sessiecookies om ontvangen aanvragen te verifiëren. Een aanvaller kan dit beveiligingsprobleem misbruiken door de browser van een andere gebruiker een URL te laten laden met een opdracht van een kwetsbare site waarop de gebruiker al is aangemeld. Er zijn veel manieren waarop een aanvaller dit kan doen, bijvoorbeeld door een andere website te hosten die een resource van de kwetsbare server laadt of de gebruiker op een koppeling te laten klikken. De aanval kan worden voorkomen als de server een extra token naar de client verzendt, vereist dat de client dat token opneemt in alle toekomstige aanvragen en controleert of alle toekomstige aanvragen een token bevatten dat betrekking heeft op de huidige sessie, zoals het gebruik van de ASP.NET AntiForgeryToken of ViewState.
Anti-CSRF en AJAX: het formuliertoken kan een probleem zijn voor AJAX-aanvragen, omdat een AJAX-aanvraag JSON-gegevens kan verzenden, niet HTML-formuliergegevens. Een oplossing is het verzenden van de tokens in een aangepaste HTTP-header. De volgende code maakt gebruik van Razor-syntaxis om de tokens te genereren en voegt vervolgens de tokens toe aan een AJAX-aanvraag.
voorbeeld
<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>
voorbeeld
Wanneer u de aanvraag verwerkt, extraheert u de tokens uit de aanvraagheader. Roep vervolgens de methode AntiForgery.Validate aan om de tokens te valideren. Met de validatiemethode wordt een uitzondering gegenereerd als de tokens niet geldig zijn.
Anti-CSRF- en ASP.NET MVC-formulieren : gebruik de helpermethode AntiForgeryToken voor weergaven; plaats een Html.AntiForgeryToken() in het formulier, bijvoorbeeld
In het bovenstaande voorbeeld wordt ongeveer het volgende uitgevoerd:
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
voorbeeld
Tegelijkertijd geeft Html.AntiForgeryToken() de bezoeker een cookie met de naam __RequestVerificationToken, met dezelfde waarde als de willekeurige verborgen waarde die hierboven wordt weergegeven. Als u vervolgens een binnenkomend formulierbericht wilt valideren, voegt u het filter [ValidateAntiForgeryToken] toe aan de doelactiemethode. Bijvoorbeeld:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Autorisatiefilter waarmee wordt gecontroleerd of:
De binnenkomende aanvraag heeft een cookie met de naam __RequestVerificationToken
De binnenkomende aanvraag heeft een vermelding met de Request.Form naam __RequestVerificationToken
Deze cookie en Request.Form waarden komen overeen, ervan uitgaande dat alles goed is, de aanvraag wordt als normaal doorlopen. Maar als dat niet het probleem is, krijgt u een autorisatiefout met het bericht 'Er is geen vereist antivervalsingstoken opgegeven of ongeldig'.
Title
Details
Onderdeel
Web-API
SDL-fase
Bouwen
Toepasselijke technologieën
MVC5, MVC6
Kenmerken
Id-provider - ADFS, id-provider - Microsoft Entra-id
Als de web-API is beveiligd met OAuth 2.0, verwacht deze een bearer-token in de header van de autorisatieaanvraag en verleent deze alleen toegang tot de aanvraag als het token geldig is. In tegenstelling tot verificatie op basis van cookies voegen browsers de bearer-tokens niet toe aan aanvragen. De aanvragende client moet het bearer-token expliciet koppelen in de aanvraagheader. Daarom worden bearer-tokens voor ASP.NET web-API's die zijn beveiligd met OAuth 2.0, beschouwd als een verdediging tegen CSRF-aanvallen. Houd er rekening mee dat als het MVC-gedeelte van de toepassing gebruikmaakt van formulierverificatie (bijvoorbeeld cookies), antivervalsingstokens moeten worden gebruikt door de MVC-web-app.
voorbeeld
De web-API moet worden geïnformeerd om alleen te vertrouwen op bearertokens en niet op cookies. Dit kan worden gedaan door de volgende configuratie in WebApiConfig.Register de methode:
De methode SuppressDefaultHostAuthentication vertelt web-API om verificatie te negeren die plaatsvindt voordat de aanvraag de web-API-pijplijn bereikt, hetzij door IIS of door OWIN middleware. Op die manier kunnen we web-API beperken tot verificatie alleen met bearer-tokens.