Udostępnij za pośrednictwem


Ramka zabezpieczeń: Zarządzanie sesjami

Produkt/usługa Artykuł
Microsoft Entra ID
Urządzenie IoT
Azure Document DB
Program ADFS
Serwer tożsamości
Aplikacja internetowa
Internetowy interfejs API

Implementowanie prawidłowego wylogowywanie przy użyciu metod biblioteki MSAL podczas korzystania z identyfikatora Entra firmy Microsoft

Stanowisko Szczegóły
Składnik Identyfikator usługi Microsoft Entra
Faza SDL Kompilacja
Odpowiednie technologie Ogólny element
Atrybuty Nie dotyczy
Dokumentacja Włącz aplikację internetową, aby logować użytkowników przy użyciu Platforma tożsamości Microsoft
Kroki Oprogramowanie pośredniczące ASP.NET Core OpenId Połączenie umożliwia aplikacji przechwycenie wywołania punktu końcowego wylogowania Platforma tożsamości Microsoft przez podanie zdarzenia OpenId Połączenie o nazwieOnRedirectToIdentityProviderForSignOut

Przykład

services.Configure<OpenIdConnectOptions>(OpenIdConnectDefaults.AuthenticationScheme, options =>
{
    options.Events.OnRedirectToIdentityProviderForSignOut = async context =>
    {
        //Your logic here
    };
});

Używanie okresów istnienia skończonych dla wygenerowanych tokenów SaS

Stanowisko Szczegóły
Składnik Urządzenie IoT
Faza SDL Kompilacja
Odpowiednie technologie Ogólny element
Atrybuty Nie dotyczy
Dokumentacja Nie dotyczy
Kroki Tokeny saS wygenerowane na potrzeby uwierzytelniania w usłudze Azure IoT Hub powinny mieć skończony okres wygaśnięcia. Zachowaj okresy istnienia tokenu saS do minimum, aby ograniczyć czas ich odtwarzania w przypadku naruszenia zabezpieczeń tokenów.

Używanie minimalnych okresów istnienia tokenów dla wygenerowanych tokenów zasobów

Stanowisko Szczegóły
Składnik Azure Document DB
Faza SDL Kompilacja
Odpowiednie technologie Ogólny element
Atrybuty Nie dotyczy
Dokumentacja Nie dotyczy
Kroki Zmniejsz przedział czasu tokenu zasobu do minimalnej wymaganej wartości. Tokeny zasobów mają domyślny przedział czasu 1 godziny.

Implementowanie prawidłowego wylogowywania przy użyciu metod WsFederation podczas korzystania z usług ADFS

Stanowisko Szczegóły
Składnik Program ADFS
Faza SDL Kompilacja
Odpowiednie technologie Ogólny element
Atrybuty Nie dotyczy
Dokumentacja Nie dotyczy
Kroki Jeśli aplikacja korzysta z tokenu STS wystawionego przez usługę ADFS, program obsługi zdarzeń wylogowywania powinien wywołać metodę WSFederationAuthenticationModule.FederatedSignOut(), aby wylogować użytkownika. Ponadto bieżąca sesja powinna zostać zniszczona, a wartość tokenu sesji powinna zostać zresetowana i unieważniona.

Przykład

        [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);
        }

Implementowanie prawidłowego wylogowywanie podczas korzystania z serwera tożsamości

Stanowisko Szczegóły
Składnik Serwer tożsamości
Faza SDL Kompilacja
Odpowiednie technologie Ogólny element
Atrybuty Nie dotyczy
Dokumentacja IdentityServer3-Federacyjne wylogowanie
Kroki Usługa IdentityServer obsługuje możliwość federacji z zewnętrznymi dostawcami tożsamości. Gdy użytkownik wy wylogował się z nadrzędnego dostawcy tożsamości, w zależności od używanego protokołu, może być możliwe otrzymanie powiadomienia po wylogowaniu użytkownika. Dzięki temu usługa IdentityServer może powiadamiać swoich klientów, aby mogli również wylogować użytkownika. Zapoznaj się z dokumentacją w sekcji referencyjnej, aby uzyskać szczegółowe informacje o implementacji.

Aplikacje dostępne za pośrednictwem protokołu HTTPS muszą używać bezpiecznych plików cookie

Stanowisko Szczegóły
Składnik Aplikacja internetowa
Faza SDL Kompilacja
Odpowiednie technologie Ogólny element
Atrybuty EnvironmentType — OnPrem
Dokumentacja httpCookies, właściwość (ASP.NET Ustawienia Schema), HttpCookie.Secure
Kroki Pliki cookie są zwykle dostępne tylko dla domeny, dla której zostały objęte zakresem. Niestety definicja "domeny" nie zawiera protokołu, więc pliki cookie tworzone za pośrednictwem protokołu HTTPS są dostępne za pośrednictwem protokołu HTTP. Atrybut "secure" wskazuje przeglądarce, że plik cookie powinien być udostępniany tylko za pośrednictwem protokołu HTTPS. Upewnij się, że wszystkie pliki cookie ustawione za pośrednictwem protokołu HTTPS używają bezpiecznego atrybutu. Wymaganie można wymusić w pliku web.config, ustawiając atrybut requireSSL na true. Jest to preferowane podejście, ponieważ wymusza bezpieczny atrybut dla wszystkich bieżących i przyszłych plików cookie bez konieczności wprowadzania dodatkowych zmian w kodzie.

Przykład

<configuration>
  <system.web>
    <httpCookies requireSSL="true"/>
  </system.web>
</configuration>

To ustawienie jest wymuszane, nawet jeśli protokół HTTP jest używany do uzyskiwania dostępu do aplikacji. Jeśli protokół HTTP jest używany do uzyskiwania dostępu do aplikacji, ustawienie powoduje przerwanie aplikacji, ponieważ pliki cookie są ustawione za pomocą bezpiecznego atrybutu, a przeglądarka nie wyśle ich z powrotem do aplikacji.

Stanowisko Szczegóły
Składnik Aplikacja internetowa
Faza SDL Kompilacja
Odpowiednie technologie Web Forms, MVC5
Atrybuty EnvironmentType — OnPrem
Dokumentacja Nie dotyczy
Kroki Gdy aplikacja internetowa jest stroną uzależnioną, a dostawcą tożsamości jest serwer usługi ADFS, można skonfigurować bezpieczny atrybut tokenu FedAuth, ustawiając właściwość requireSSL na True w system.identityModel.services sekcji web.config:

Przykład

  <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>
Stanowisko Szczegóły
Składnik Aplikacja internetowa
Faza SDL Kompilacja
Odpowiednie technologie Ogólny element
Atrybuty Nie dotyczy
Dokumentacja Bezpieczny atrybut pliku cookie
Kroki Aby ograniczyć ryzyko ujawnienia informacji za pomocą ataku skryptów między witrynami (XSS), nowy atrybut — httpOnly — został wprowadzony do plików cookie i jest obsługiwany przez wszystkie główne przeglądarki. Atrybut określa, że plik cookie nie jest dostępny za pośrednictwem skryptu. Korzystając z plików cookie HttpOnly, aplikacja internetowa zmniejsza możliwość kradzieży poufnych informacji zawartych w pliku cookie za pośrednictwem skryptu i wysłania ich do witryny internetowej osoby atakującej.

Przykład

Wszystkie aplikacje oparte na protokole HTTP korzystające z plików cookie powinny określać wartość HttpOnly w definicji pliku cookie, implementując następującą konfigurację w pliku web.config:

<system.web>
.
.
   <httpCookies requireSSL="false" httpOnlyCookies="true"/>
.
.
</system.web>
Stanowisko Szczegóły
Składnik Aplikacja internetowa
Faza SDL Kompilacja
Odpowiednie technologie Formularze sieci Web
Atrybuty Nie dotyczy
Dokumentacja FormsAuthentication.RequireSSL, właściwość
Kroki Wartość właściwości RequireSSL jest ustawiana w pliku konfiguracji dla aplikacji ASP.NET przy użyciu atrybutu requireSSL elementu konfiguracji. Możesz określić w pliku Web.config dla aplikacji ASP.NET, czy protokół Transport Layer Security (TLS), wcześniej znany jako SSL (Secure Sockets Layer), jest wymagany do zwrócenia pliku cookie uwierzytelniania formularzy do serwera, ustawiając atrybut requireSSL.

Przykład

Poniższy przykład kodu ustawia atrybut requireSSL w pliku Web.config.

<authentication mode="Forms">
  <forms loginUrl="member_login.aspx" cookieless="UseCookies" requireSSL="true"/>
</authentication>
Stanowisko Szczegóły
Składnik Aplikacja internetowa
Faza SDL Kompilacja
Odpowiednie technologie MVC5
Atrybuty EnvironmentType — OnPrem
Dokumentacja Konfiguracja programu Windows Identity Foundation (WIF) — część II
Kroki Aby ustawić atrybut httpOnly dla plików cookie FedAuth, należy ustawić wartość atrybutu hideFromCsript na true.

Przykład

Poniższa konfiguracja pokazuje poprawną konfigurację:

<federatedAuthentication>
<cookieHandler mode="Custom"
                       hideFromScript="true"
                       name="FedAuth"
                       path="/"
                       requireSsl="true"
                       persistentSessionLifetime="25">
</cookieHandler>
</federatedAuthentication>

Eliminowanie ataków fałszerzowania żądań między witrynami (CSRF) na ASP.NET stronach internetowych

Stanowisko Szczegóły
Składnik Aplikacja internetowa
Faza SDL Kompilacja
Odpowiednie technologie Ogólny element
Atrybuty Nie dotyczy
Dokumentacja Nie dotyczy
Kroki Fałszerzować żądania obejmujące wiele witryn (CSRF lub XSRF) to rodzaj ataku, w którym osoba atakująca może wykonywać akcje w kontekście zabezpieczeń sesji innego użytkownika w witrynie internetowej. Celem jest zmodyfikowanie lub usunięcie zawartości, jeśli docelowa witryna internetowa opiera się wyłącznie na plikach cookie sesji w celu uwierzytelnienia odebranych żądań. Osoba atakująca może wykorzystać tę lukę w zabezpieczeniach, uzyskując przeglądarkę innego użytkownika w celu załadowania adresu URL za pomocą polecenia z witryny podatnej na zagrożenia, w której użytkownik jest już zalogowany. Istnieje wiele sposobów na to, aby osoba atakująca to zrobiła, na przykład hostując inną witrynę internetową, która ładuje zasób z serwera podatnego na zagrożenia lub umożliwiając użytkownikowi kliknięcie linku. Atak może być blokowany, jeśli serwer wysyła dodatkowy token do klienta, wymaga, aby klient uwzględnił ten token we wszystkich przyszłych żądaniach i sprawdza, czy wszystkie przyszłe żądania zawierają token odnoszący się do bieżącej sesji, na przykład przy użyciu ASP.NET AntiForgeryToken lub ViewState.
Stanowisko Szczegóły
Składnik Aplikacja internetowa
Faza SDL Kompilacja
Odpowiednie technologie MVC5, MVC6
Atrybuty Nie dotyczy
Dokumentacja Zapobieganie atakom XSRF/CSRF we wzorcach ASP.NET MVC i Web Pages
Kroki Anty-CSRF i ASP.NET formularzy MVC — użyj metody pomocniczej AntiForgeryToken w widokach; na przykład umieść element Html.AntiForgeryToken() w formularzu

Przykład

@using (Html.BeginForm("UserProfile", "SubmitUpdate")) { 
    @Html.ValidationSummary(true) 
    @Html.AntiForgeryToken()
    <fieldset> 

Przykład

<form action="/UserProfile/SubmitUpdate" method="post">
    <input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
    <!-- rest of form goes here -->
</form>

Przykład

Jednocześnie html.AntiForgeryToken() udostępnia odwiedzającym plik cookie o nazwie __RequestVerificationToken z taką samą wartością jak losowa wartość ukryta pokazana powyżej. Następnie, aby zweryfikować wpis formularza przychodzącego, dodaj filtr [ValidateAntiForgeryToken] do metody akcji docelowej. Przykład:

[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}

Filtr autoryzacji sprawdzający, czy:

  • Żądanie przychodzące ma plik cookie o nazwie __RequestVerificationToken
  • Żądanie przychodzące ma Request.Form wpis o nazwie __RequestVerificationToken
  • Te pliki cookie i Request.Form wartości są zgodne przy założeniu, że wszystko jest dobrze, żądanie przechodzi tak normalnie. Jeśli tak nie jest, to błąd autoryzacji z komunikatem "Wymagany token ochrony przed fałszerstwom nie został podany lub był nieprawidłowy".

Przykład

Anti-CSRF i AJAX: token formularza może być problemem dla żądań AJAX, ponieważ żądanie AJAX może wysyłać dane JSON, a nie dane formularza HTML. Jednym z rozwiązań jest wysłanie tokenów w niestandardowym nagłówku HTTP. Poniższy kod używa składni Razor do generowania tokenów, a następnie dodaje tokeny do żądania 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>

Przykład

Podczas przetwarzania żądania wyodrębnij tokeny z nagłówka żądania. Następnie wywołaj metodę AntiForgery.Validate, aby zweryfikować tokeny. Metoda Validate zgłasza wyjątek, jeśli tokeny są nieprawidłowe.

void ValidateRequestHeader(HttpRequestMessage request)
{
    string cookieToken = "";
    string formToken = "";

    IEnumerable<string> tokenHeaders;
    if (request.Headers.TryGetValues("RequestVerificationToken", out tokenHeaders))
    {
        string[] tokens = tokenHeaders.First().Split(':');
        if (tokens.Length == 2)
        {
            cookieToken = tokens[0].Trim();
            formToken = tokens[1].Trim();
        }
    }
    AntiForgery.Validate(cookieToken, formToken);
}
Stanowisko Szczegóły
Składnik Aplikacja internetowa
Faza SDL Kompilacja
Odpowiednie technologie Formularze sieci Web
Atrybuty Nie dotyczy
Dokumentacja Korzystaj z wbudowanych funkcji ASP.NET, aby odeprzeć ataki internetowe
Kroki Ataki CSRF w aplikacjach opartych na formach WebForm można ograniczyć, ustawiając wartość ViewStateUserKey na losowy ciąg, który różni się dla każdego użytkownika — identyfikator użytkownika lub, jeszcze lepiej, identyfikator sesji. Z wielu powodów technicznych i społecznościowych identyfikator sesji jest znacznie lepszy, ponieważ identyfikator sesji jest nieprzewidywalny, limit czasu i różni się w zależności od użytkownika.

Przykład

Oto kod, który musisz mieć na wszystkich stronach:

void Page_Init (object sender, EventArgs e) {
   ViewStateUserKey = Session.SessionID;
   :
}

Konfigurowanie sesji pod kątem okresu istnienia braku aktywności

Stanowisko Szczegóły
Składnik Aplikacja internetowa
Faza SDL Kompilacja
Odpowiednie technologie Ogólny element
Atrybuty Nie dotyczy
Dokumentacja Właściwość HttpSessionState.Timeout
Kroki Limit czasu sesji reprezentuje zdarzenie występujące, gdy użytkownik nie wykonuje żadnej akcji w witrynie internetowej w interwale (zdefiniowanym przez serwer internetowy). Zdarzenie po stronie serwera zmienia stan sesji użytkownika na "nieprawidłowy" (na przykład "nie jest już używany") i poinstruuj serwer internetowy, aby go zniszczył (usunięcie wszystkich zawartych w nim danych). Poniższy przykład kodu ustawia atrybut sesji limitu czasu na 15 minut w pliku Web.config.

Przykład

<configuration>
  <system.web>
    <sessionState mode="InProc" cookieless="true" timeout="15" />
  </system.web>
</configuration>

Włączanie wykrywania zagrożeń w usłudze Azure SQL

Stanowisko Szczegóły
Składnik Aplikacja internetowa
Faza SDL Kompilacja
Odpowiednie technologie Formularze sieci Web
Atrybuty Nie dotyczy
Dokumentacja Element formularzy na potrzeby uwierzytelniania (schemat ASP.NET Ustawienia)
Kroki Ustaw limit czasu pliku cookie biletu uwierzytelniania formularzy na 15 minut

Przykład

<forms  name=".ASPXAUTH" loginUrl="login.aspx"  defaultUrl="default.aspx" protection="All" timeout="15" path="/" requireSSL="true" slidingExpiration="true"/>
</forms>
Tytuł Szczegóły
Składnik Aplikacja internetowa
Faza SDL Kompilacja
Odpowiednie technologie Web Forms, MVC5
Atrybuty EnvironmentType — OnPrem
Dokumentacja asdeqa
Kroki Gdy aplikacja internetowa jest stroną uzależnioną, a usługi ADFS są usługą STS, okres istnienia plików cookie uwierzytelniania — tokeny FedAuth — można ustawić przez następującą konfigurację w pliku web.config:

Przykład

  <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>

Przykład

Ponadto okres istnienia tokenu oświadczeń SAML wystawiony przez usługę ADFS powinien być ustawiony na 15 minut, wykonując następujące polecenie programu PowerShell na serwerze usług AD FS:

Set-ADFSRelyingPartyTrust -TargetName "<RelyingPartyWebApp>" -ClaimsProviderName @("Active Directory") -TokenLifetime 15 -AlwaysRequireAuthentication $true

Implementowanie prawidłowego wylogowywanie z aplikacji

Stanowisko Szczegóły
Składnik Aplikacja internetowa
Faza SDL Kompilacja
Odpowiednie technologie Ogólny element
Atrybuty Nie dotyczy
Dokumentacja Nie dotyczy
Kroki Wykonaj odpowiednie wylogowywanie z aplikacji, gdy użytkownik naciska przycisk wylogowania. Po wylogowaniu aplikacja powinna zniszczyć sesję użytkownika, a także zresetować i unieważnić wartość pliku cookie sesji, a także zresetować i unieważnić wartość pliku cookie uwierzytelniania. Ponadto, gdy wiele sesji jest powiązanych z jedną tożsamością użytkownika, musi zostać zbiorczo przerwane po stronie serwera przy przekroczeniu limitu czasu lub wylogowaniu. Na koniec upewnij się, że funkcja wylogowywanie jest dostępna na każdej stronie.

Eliminowanie ataków fałszerzowania żądań między witrynami (CSRF) na ASP.NET internetowych interfejsach API

Stanowisko Szczegóły
Składnik Internetowy interfejs API
Faza SDL Kompilacja
Odpowiednie technologie Ogólny element
Atrybuty Nie dotyczy
Dokumentacja Nie dotyczy
Kroki Fałszerzować żądania obejmujące wiele witryn (CSRF lub XSRF) to rodzaj ataku, w którym osoba atakująca może wykonywać akcje w kontekście zabezpieczeń sesji innego użytkownika w witrynie internetowej. Celem jest zmodyfikowanie lub usunięcie zawartości, jeśli docelowa witryna internetowa opiera się wyłącznie na plikach cookie sesji w celu uwierzytelnienia odebranych żądań. Osoba atakująca może wykorzystać tę lukę w zabezpieczeniach, uzyskując przeglądarkę innego użytkownika w celu załadowania adresu URL za pomocą polecenia z witryny podatnej na zagrożenia, w której użytkownik jest już zalogowany. Istnieje wiele sposobów na to, aby osoba atakująca to zrobiła, na przykład hostując inną witrynę internetową, która ładuje zasób z serwera podatnego na zagrożenia lub umożliwiając użytkownikowi kliknięcie linku. Atak może być blokowany, jeśli serwer wysyła dodatkowy token do klienta, wymaga, aby klient uwzględnił ten token we wszystkich przyszłych żądaniach i sprawdza, czy wszystkie przyszłe żądania zawierają token odnoszący się do bieżącej sesji, na przykład przy użyciu ASP.NET AntiForgeryToken lub ViewState.
Stanowisko Szczegóły
Składnik Internetowy interfejs API
Faza SDL Kompilacja
Odpowiednie technologie MVC5, MVC6
Atrybuty Nie dotyczy
Dokumentacja Zapobieganie atakom fałszerstwa żądań między witrynami (CSRF) w internetowym interfejsie API ASP.NET
Kroki Anti-CSRF i AJAX: token formularza może być problemem dla żądań AJAX, ponieważ żądanie AJAX może wysyłać dane JSON, a nie dane formularza HTML. Jednym z rozwiązań jest wysłanie tokenów w niestandardowym nagłówku HTTP. Poniższy kod używa składni Razor do generowania tokenów, a następnie dodaje tokeny do żądania AJAX.

Przykład

<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>

Przykład

Podczas przetwarzania żądania wyodrębnij tokeny z nagłówka żądania. Następnie wywołaj metodę AntiForgery.Validate, aby zweryfikować tokeny. Metoda Validate zgłasza wyjątek, jeśli tokeny są nieprawidłowe.

void ValidateRequestHeader(HttpRequestMessage request)
{
    string cookieToken = "";
    string formToken = "";

    IEnumerable<string> tokenHeaders;
    if (request.Headers.TryGetValues("RequestVerificationToken", out tokenHeaders))
    {
        string[] tokens = tokenHeaders.First().Split(':');
        if (tokens.Length == 2)
        {
            cookieToken = tokens[0].Trim();
            formToken = tokens[1].Trim();
        }
    }
    AntiForgery.Validate(cookieToken, formToken);
}

Przykład

Formularze anti-CSRF i ASP.NET MVC — użyj metody pomocnika AntiForgeryToken w widokach; umieść element Html.AntiForgeryToken() w formularzu, na przykład

@using (Html.BeginForm("UserProfile", "SubmitUpdate")) { 
    @Html.ValidationSummary(true) 
    @Html.AntiForgeryToken()
    <fieldset> 
}

Przykład

W powyższym przykładzie zostaną wyświetlone dane wyjściowe podobne do następujących:

<form action="/UserProfile/SubmitUpdate" method="post">
    <input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
    <!-- rest of form goes here -->
</form>

Przykład

Jednocześnie html.AntiForgeryToken() udostępnia odwiedzającym plik cookie o nazwie __RequestVerificationToken z taką samą wartością jak losowa wartość ukryta pokazana powyżej. Następnie, aby zweryfikować wpis formularza przychodzącego, dodaj filtr [ValidateAntiForgeryToken] do metody akcji docelowej. Przykład:

[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}

Filtr autoryzacji sprawdzający, czy:

  • Żądanie przychodzące ma plik cookie o nazwie __RequestVerificationToken
  • Żądanie przychodzące ma Request.Form wpis o nazwie __RequestVerificationToken
  • Te pliki cookie i Request.Form wartości są zgodne przy założeniu, że wszystko jest dobrze, żądanie przechodzi tak normalnie. Jeśli tak nie jest, to błąd autoryzacji z komunikatem "Wymagany token ochrony przed fałszerstwom nie został podany lub był nieprawidłowy".
Stanowisko Szczegóły
Składnik Internetowy interfejs API
Faza SDL Kompilacja
Odpowiednie technologie MVC5, MVC6
Atrybuty Dostawca tożsamości — ADFS, dostawca tożsamości — identyfikator entra firmy Microsoft
Dokumentacja Zabezpieczanie internetowego interfejsu API przy użyciu indywidualnych kont i logowania lokalnego w interfejsie API sieci Web 2.2 ASP.NET
Kroki Jeśli internetowy interfejs API jest zabezpieczony przy użyciu protokołu OAuth 2.0, oczekuje tokenu elementu nośnego w nagłówku żądania autoryzacji i udziela dostępu do żądania tylko wtedy, gdy token jest prawidłowy. W przeciwieństwie do uwierzytelniania opartego na plikach cookie przeglądarki nie dołączają tokenów elementu nośnego do żądań. Klient żądający musi jawnie dołączyć token elementu nośnego w nagłówku żądania. W związku z tym w przypadku ASP.NET internetowych interfejsów API chronionych przy użyciu protokołu OAuth 2.0 tokeny elementu nośnego są uznawane za obronę przed atakami CSRF. Należy pamiętać, że jeśli część MVC aplikacji używa uwierzytelniania formularzy (tj. używa plików cookie), tokeny ochrony przed fałszerzami muszą być używane przez aplikację internetową MVC.

Przykład

Internetowy interfejs API musi być informowany, aby polegać tylko na tokenach elementu nośnego, a nie na plikach cookie. Można to zrobić za pomocą następującej konfiguracji w WebApiConfig.Register metodzie:

config.SuppressDefaultHostAuthentication();
config.Filters.Add(new HostAuthenticationFilter(OAuthDefaults.AuthenticationType));

Metoda SuppressDefaultHostAuthentication informuje internetowy interfejs API o ignorowaniu uwierzytelniania, które ma miejsce przed dotarciem żądania do potoku internetowego interfejsu API przez usługi IIS lub oprogramowanie pośredniczące OWIN. Dzięki temu możemy ograniczyć internetowy interfejs API do uwierzytelniania tylko przy użyciu tokenów elementu nośnego.