Udostępnij za pośrednictwem

Zapobieganie atakom XSRF/CSRF we wzorcach ASP.NET MVC i Web Pages

  • Artykuł

Autor : Rick Anderson

Fałszerzować żądania obejmujące wiele witryn (nazywane również XSRF lub CSRF) to atak na aplikacje hostowane w Internecie, w których złośliwa witryna internetowa może wpływać na interakcję między przeglądarką klienta a witryną internetową zaufaną przez tę przeglądarkę. Te ataki są możliwe, ponieważ przeglądarki internetowe będą automatycznie wysyłać tokeny uwierzytelniania z każdym żądaniem do witryny internetowej. Przykładem kanonicznym jest plik cookie uwierzytelniania, taki jak ASP. Bilet uwierzytelniania formularzy platformy NET. Jednak witryny sieci Web korzystające z dowolnego mechanizmu uwierzytelniania trwałego (takiego jak uwierzytelnianie systemu Windows, podstawowe i tak dalej) mogą być celem tych ataków.

Atak XSRF różni się od ataku wyłudzania informacji. Ataki wyłudzane informacje wymagają interakcji ze strony ofiary. W przypadku ataku wyłudzania informacji złośliwa witryna internetowa naśladuje docelową witrynę internetową, a ofiara zostaje oszukana do dostarczania poufnych informacji osobie atakującej. W przypadku ataku XSRF często nie ma żadnej interakcji ze strony ofiary. Zamiast tego osoba atakująca polega na przeglądarce automatycznie wysyła wszystkie odpowiednie pliki cookie do docelowej witryny sieci Web.

Aby uzyskać więcej informacji, zobacz Open Web Application Security Project (OWASP) XSRF.

Anatomia ataku

Aby przejść przez atak XSRF, rozważ użytkownika, który chce wykonać niektóre transakcje bankowe online. Ten użytkownik najpierw odwiedza WoodgroveBank.com i loguje się, w którym momencie nagłówek odpowiedzi będzie zawierał jej plik cookie uwierzytelniania:

HTTP/1.1 200 OK
Date: Mon, 18 Jun 2012 21:22:33 GMT
X-AspNet-Version: 4.0.30319
Set-Cookie: .ASPXAUTH={authentication-token}; path=/; secure; HttpOnly;
{ Cache-Control, Content-Type, Location, Server and other keys/values not listed. }

Ponieważ plik cookie uwierzytelniania jest plikiem cookie sesji, zostanie automatycznie wyczyszczone przez przeglądarkę po zakończeniu procesu przeglądarki. Jednak do tego czasu przeglądarka automatycznie dołączy plik cookie do każdego żądania WoodgroveBank.com. Użytkownik chce teraz przenieść 1000 USD na inne konto, więc wypełnia formularz w witrynie bankowej, a przeglądarka wysyła to żądanie do serwera:

POST /DoTransfer HTTP/1.1
Host: WoodgroveBank.com
Content-Type: application/x-www-form-urlencoded
Cookie: .ASPXAUTH={authentication-token}
toAcct=12345&amount=1,000.00

Ponieważ ta operacja ma efekt uboczny (inicjuje transakcję pieniężną), witryna bankowa zdecydowała się na wymaganie postu HTTP w celu zainicjowania tej operacji. Serwer odczytuje token uwierzytelniania z żądania, wyszukuje numer konta bieżącego użytkownika, sprawdza, czy istnieją wystarczające fundusze, a następnie inicjuje transakcję na koncie docelowym.

Jej bankowość online kończy się, użytkownik przechodzi z dala od witryny bankowej i odwiedza inne lokalizacje w Internecie. Jedna z tych witryn — fabrikam.com — zawiera następujące znaczniki na stronie osadzonej w ramce <iframe>:

<form id="theForm" action="https://WoodgroveBank.com/DoTransfer" method="post">
    <input type="hidden" name="toAcct" value="67890" />
    <input type="hidden" name="amount" value="250.00" />
</form>
<script type="text/javascript">
    document.getElementById('theForm').submit();
</script>

Co powoduje, że przeglądarka wysyła to żądanie:

POST /DoTransfer HTTP/1.1
Host: WoodgroveBank.com
Content-Type: application/x-www-form-urlencoded
Cookie: .ASPXAUTH={authentication-token}
toAcct=67890&amount=250.00

Osoba atakująca wykorzystuje fakt, że użytkownik może nadal mieć prawidłowy token uwierzytelniania dla docelowej witryny internetowej, a ona używa małego fragmentu kodu JavaScript, aby spowodować, że przeglądarka automatycznie utworzy wpis HTTP POST w witrynie docelowej. Jeśli token uwierzytelniania jest nadal ważny, witryna bankowa zainicjuje przeniesienie w wysokości 250 USD na konto wybranego przez osobę atakującą.

Nieskuteczne środki zaradcze

Warto zauważyć, że w powyższym scenariuszu fakt, że dostęp do WoodgroveBank.com był uzyskiwany za pośrednictwem protokołu SSL i plik cookie uwierzytelniania tylko ssl był niewystarczający do udaremnienia ataku. Osoba atakująca może określić schemat identyfikatora URI (https) w elemecie <formularza> , a przeglądarka będzie nadal wysyłać niewygasłe pliki cookie do witryny docelowej, o ile te pliki cookie są zgodne ze schematem identyfikatora URI zamierzonego obiektu docelowego.

Można argumentować, że użytkownik po prostu nie powinien odwiedzać niezaufanych witryn, ponieważ odwiedzanie tylko zaufanych witryn pomaga zachować bezpieczeństwo online. Jest taka prawda, ale niestety ta rada nie zawsze jest praktyczna. Być może użytkownik "ufa" lokalnej witrynie wiadomości ConsolidatedMessenger.com i przechodzi do tej witryny zamiast tego, ale ta witryna ma lukę w zabezpieczeniach XSS, która umożliwia atakującemu wstrzyknięcie tego samego fragmentu kodu uruchomionego na fabrikam.com.

Możesz sprawdzić, czy żądania przychodzące mają nagłówek Odwołania odwołujące się do domeny. Spowoduje to zatrzymanie żądań nieświadomie przesłanych z domeny innej firmy. Jednak niektóre osoby wyłączają nagłówek referer przeglądarki ze względów prywatności, a osoby atakujące mogą czasami fałszować ten nagłówek, jeśli ofiara ma zainstalowane pewne niezabezpieczone oprogramowanie. Sprawdzanie, czy nagłówek referera nie jest uważany za bezpieczne podejście do zapobiegania atakom XSRF.

Środki zaradcze XSRF środowiska uruchomieniowego usługi Web Stack

Środowisko uruchomieniowe usługi Web Stack ASP.NET używa wariantu wzorca tokenu synchronizatora do obrony przed atakami XSRF. Ogólną formą wzorca tokenu synchronizatora jest to, że dwa tokeny anty-XSRF są przesyłane do serwera z każdym tokenem HTTP POST (oprócz tokenu uwierzytelniania): jeden token jako plik cookie, a drugi jako wartość formularza. Wartości tokenu generowane przez środowisko uruchomieniowe ASP.NET nie są deterministyczne ani przewidywalne przez osobę atakującą. Po przesłaniu tokenów serwer zezwoli na kontynuowanie żądania tylko wtedy, gdy oba tokeny przejdą kontrolę porównania.

Token sesji weryfikacji żądania XSRF jest przechowywany jako plik cookie HTTP i obecnie zawiera następujące informacje w ładunku:

  • Token zabezpieczający składający się z losowego identyfikatora 128-bitowego.
    Na poniższej ilustracji przedstawiono token sesji weryfikacji żądania XSRF wyświetlany za pomocą narzędzi deweloperskich programu Internet Explorer F12: (Zwróć uwagę, że jest to bieżąca implementacja i może nawet ulec zmianie).

Zrzut ekranu przedstawiający stronę Indeks aplikacji My A A S P dot NET M V C. Karta Sieć jest otwarta.

Token pola jest przechowywany jako element <input type="hidden" /> i zawiera następujące informacje w ładunku:

Ładunki tokenów anti-XSRF są szyfrowane i podpisane, więc nie można wyświetlić nazwy użytkownika podczas korzystania z narzędzi do badania tokenów. Gdy aplikacja internetowa jest przeznaczona dla ASP.NET 4.0, usługi kryptograficzne są udostępniane przez procedurę MachineKey.Encode . Gdy aplikacja internetowa jest przeznaczona dla ASP.NET 4.5 lub nowszej, usługi kryptograficzne są udostępniane przez procedurę MachineKey.Protect , która zapewnia lepszą wydajność, rozszerzalność i zabezpieczenia. Aby uzyskać więcej informacji, zobacz następujące wpisy w blogu:

Generowanie tokenów

Aby wygenerować tokeny anty-XSRF, wywołaj metodę @Html.AntiForgeryToken z widoku MVC lub @AntiForgery.GetHtml() ze strony Razor. Następnie środowisko uruchomieniowe wykona następujące czynności:

  1. Jeśli bieżące żądanie HTTP zawiera już token sesji anti-XSRF (plik cookie anti-XSRF __RequestVerificationToken), token zabezpieczający zostanie wyodrębniony z niego. Jeśli żądanie HTTP nie zawiera tokenu sesji anti-XSRF lub wyodrębnianie tokenu zabezpieczającego nie powiedzie się, zostanie wygenerowany nowy losowy token anty-XSRF.
  2. Token pola anti-XSRF jest generowany przy użyciu tokenu zabezpieczającego z kroku (1) powyżej i tożsamości bieżącego zalogowanego użytkownika. (Aby uzyskać więcej informacji na temat określania tożsamości użytkownika, zobacz sekcję Scenariusze ze specjalną pomocą techniczną poniżej). Ponadto jeśli skonfigurowano element IAntiForgeryAdditionalDataProvider , środowisko uruchomieniowe wywoła metodę GetAdditionalData i uwzględni zwrócony ciąg w tokenie pola. (Aby uzyskać więcej informacji, zobacz sekcję Konfiguracja i rozszerzalność ).
  3. Jeśli w kroku 1 został wygenerowany nowy token anty-XSRF, zostanie utworzony nowy token sesji zawierający go i zostanie dodany do kolekcji wychodzących plików cookie HTTP. Token pola z kroku (2) zostanie opakowany w element, a ten znacznik HTML będzie zwracaną wartością <input type="hidden" />Html.AntiForgeryToken() lub AntiForgery.GetHtml().

Weryfikowanie tokenów

Aby sprawdzić poprawność przychodzących tokenów anty-XSRF, deweloper zawiera atrybut ValidateAntiForgeryToken w jej akcji lub kontrolerze MVC albo wywołuje wywołania @AntiForgery.Validate() ze strony Razor. Środowisko uruchomieniowe wykona następujące czynności:

  1. Token sesji przychodzącej i token pola są odczytywane oraz token anty-XSRF wyodrębniony z każdego z nich. Tokeny anti-XSRF muszą być identyczne dla każdego kroku (2) w procedurze generowania.
  2. Jeśli bieżący użytkownik jest uwierzytelniony, jej nazwa użytkownika jest porównywana z nazwą użytkownika przechowywaną w tokenie pola. Nazwy użytkowników muszą być zgodne.
  3. Jeśli skonfigurowano element IAntiForgeryAdditionalDataProvider , środowisko uruchomieniowe wywołuje metodę ValidateAdditionalData . Metoda musi zwrócić wartość logiczną true.

Jeśli walidacja zakończy się pomyślnie, żądanie może kontynuować. Jeśli walidacja nie powiedzie się, platforma zgłosi wyjątek HttpAntiForgeryException.

Warunki awarii

Począwszy od środowiska uruchomieniowego stosu internetowego ASP.NET w wersji 2, wszelkie wyjątki HttpAntiForgeryException zgłaszane podczas walidacji będą zawierać szczegółowe informacje o tym, co poszło nie tak. Obecnie zdefiniowane warunki niepowodzenia to:

  • Token sesji lub token formularza nie jest obecny w żądaniu.
  • Token sesji lub token formularza jest nieczytelny. Najbardziej prawdopodobną przyczyną tego problemu jest farma z niezgodnymi wersjami środowiska uruchomieniowego stosu internetowego ASP.NET lub farmą, w której <element machineKey> w Web.config różni się między maszynami. Możesz użyć narzędzia takiego jak Fiddler, aby wymusić ten wyjątek, zakłócając użycie tokenu anti-XSRF.
  • Token sesji i token pola zostały zamienione.
  • Token sesji i token pola zawierają niezgodne tokeny zabezpieczające.
  • Nazwa użytkownika osadzona w tokenie pola jest niezgodna z nazwą użytkownika zalogowanego zalogowanego użytkownika.
  • Metoda IAntiForgeryAdditionalDataProvider.ValidateAdditionalData zwróciła wartość false.

Urządzenia anty-XSRF mogą również wykonywać dodatkowe kontrole podczas generowania lub walidacji tokenu, a błędy podczas tych kontroli mogą powodować zgłaszanie wyjątków. Aby uzyskać więcej informacji, zobacz sekcje Uwierzytelnianie oparte na oświadczeniach i Konfiguracja i rozszerzalność programu WIF/ACS.

Scenariusze ze specjalną pomocą techniczną

Uwierzytelnianie anonimowe

System anty-XSRF zawiera specjalną obsługę użytkowników anonimowych, gdzie "anonimowy" jest definiowany jako użytkownik, w którym właściwość IIdentity.IsAuthenticated zwraca wartość false. Scenariusze obejmują zapewnienie ochrony XSRF na stronie logowania (przed uwierzytelnieniem użytkownika) i niestandardowe schematy uwierzytelniania, w których aplikacja używa mechanizmu innego niż IIdentity do identyfikowania użytkowników.

Aby obsługiwać te scenariusze, należy pamiętać, że tokeny sesji i pola są przyłączone przez token zabezpieczający, który jest 128-bitowym losowo wygenerowanym nieprzezroczystym identyfikatorem. Ten token zabezpieczający służy do śledzenia sesji pojedynczego użytkownika podczas nawigowania po witrynie, dzięki czemu skutecznie służy do celów identyfikatora anonimowego. Pusty ciąg jest używany zamiast nazwy użytkownika dla procedur generowania i walidacji opisanych powyżej.

Uwierzytelnianie oparte na oświadczeniach/programu WIF/ACS

Zwykle klasy IIdentity wbudowane w .NET Framework mają właściwość, która IIdentity.Name jest wystarczająca, aby jednoznacznie zidentyfikować określonego użytkownika w określonej aplikacji. Na przykład FormsIdentity.Name zwraca nazwę użytkownika przechowywaną w bazie danych członkostwa (unikatową dla wszystkich aplikacji w zależności od tej bazy danych), WindowsIdentity.Name zwraca tożsamość kwalifikowaną przez domenę użytkownika itd. Te systemy zapewniają nie tylko uwierzytelnianie; identyfikują również użytkowników w aplikacji.

Z drugiej strony uwierzytelnianie oparte na oświadczeniach nie wymaga identyfikacji określonego użytkownika. Zamiast tego typy ClaimsPrincipal i ClaimsIdentity są skojarzone z zestawem wystąpień oświadczeń , gdzie poszczególne oświadczenia mogą mieć wartość "18+ lat" lub "jest administratorem" do niczego innego. Ponieważ użytkownik niekoniecznie został zidentyfikowany, środowisko uruchomieniowe nie może użyć właściwości ClaimsIdentity.Name jako unikatowego identyfikatora dla tego konkretnego użytkownika. Zespół widział rzeczywiste przykłady, w których ClaimsIdentity.Name zwraca wartość null, zwraca przyjazną (wyświetlaną) nazwę lub w inny sposób zwraca ciąg, który nie jest odpowiedni do użycia jako unikatowy identyfikator użytkownika.

Wiele wdrożeń korzystających z uwierzytelniania opartego na oświadczeniach korzysta w szczególności z usługi Azure Access Control Service (ACS). Usługa ACS umożliwia deweloperowi skonfigurowanie poszczególnych dostawców tożsamości (takich jak ADFS, dostawca konta Microsoft, dostawcy openID, takich jak Yahoo!itp.), a dostawcy tożsamości zwracają identyfikatory nazw. Te identyfikatory nazw mogą zawierać dane osobowe (PII), takie jak adres e-mail, lub mogą być anonimowe, takie jak prywatny identyfikator osobisty (PPID). Niezależnie od tego, krotka (dostawca tożsamości, identyfikator nazwy) wystarczająco służy jako odpowiedni token śledzenia dla określonego użytkownika podczas przeglądania witryny, więc środowisko uruchomieniowe usługi Web Stack ASP.NET może używać krotki zamiast nazwy użytkownika podczas generowania i weryfikowania tokenów pól anti-XSRF. Określone identyfikatory URI dostawcy tożsamości i identyfikator nazwy to :

  • https://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider
  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

(zobacz tę stronę dokumentu ACS , aby uzyskać więcej informacji).

Podczas generowania lub weryfikowania tokenu środowisko uruchomieniowe ASP.NET Web Stack Runtime podejmie próbę powiązania z typami:

  • Microsoft.IdentityModel.Claims.IClaimsIdentity, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 (W przypadku zestawu SDK programu WIF).
  • System.Security.Claims.ClaimsIdentity (Dla platformy .NET 4.5).

Jeśli te typy istnieją, a jeśli identyfikator IIIIdentity bieżącego użytkownika implementuje lub podklasy jednego z tych typów, obiekt anti-XSRF użyje krotki (dostawcy tożsamości, identyfikatora nazwy) zamiast nazwy użytkownika podczas generowania i weryfikowania tokenów. Jeśli taka krotka nie jest obecna, żądanie zakończy się niepowodzeniem z błędem opisującym deweloperowi sposób konfigurowania systemu anti-XSRF w celu zrozumienia określonego mechanizmu uwierzytelniania opartego na oświadczeniach w użyciu. Aby uzyskać więcej informacji, zobacz sekcję Konfiguracja i rozszerzalność .

Uwierzytelnianie OAuth/OpenID

Na koniec funkcja anti-XSRF ma specjalne wsparcie dla aplikacji korzystających z uwierzytelniania OAuth lub OpenID. Ta obsługa jest oparta na heurystyce: jeśli bieżący IIdentity.Name zaczyna się od http:// lub https://, porównania nazw użytkowników zostaną wykonane przy użyciu porównania porządkowego, a nie domyślnego porównania OrdinalIgnoreCase.

Konfiguracja i rozszerzalność

Czasami deweloperzy mogą potrzebować ściślejszej kontroli nad zachowaniami generowania i walidacji anti-XSRF. Być może na przykład domyślne zachowanie pomocników MVC i Stron internetowych w przypadku automatycznego dodawania plików cookie HTTP do odpowiedzi jest niepożądane, a deweloper może chcieć zachować tokeny w innym miejscu. Istnieją dwa interfejsy API, które pomagają w tym:

AntiForgery.GetTokens(string oldCookieToken, out string newCookieToken, out string formToken);
AntiForgery.Validate(string cookieToken, string formToken);

Metoda GetTokens przyjmuje jako dane wejściowe istniejącego tokenu sesji weryfikacji żądania XSRF (który może mieć wartość null) i generuje jako dane wyjściowe nowego tokenu sesji weryfikacji żądania XSRF i tokenu pola. Tokeny są po prostu nieprzezroczyste ciągi bez dekoracji; wartość formToken nie zostanie opakowana w <tag wejściowy> . Wartość newCookieToken może mieć wartość null; jeśli tak się stanie, wartość oldCookieToken jest nadal prawidłowa i nie trzeba ustawiać żadnych nowych plików cookie odpowiedzi. Wywołujący GetTokens jest odpowiedzialny za utrwalanie wszelkich niezbędnych plików cookie odpowiedzi lub generowanie niezbędnych znaczników; sama metoda GetTokens nie zmieni odpowiedzi jako efekt uboczny. Metoda Validate pobiera tokeny sesji przychodzącej i pola i uruchamia nad nimi wyżej wymienioną logikę walidacji.

AntiForgeryConfig

Deweloper może skonfigurować system anti-XSRF z Application_Start. Konfiguracja jest programowa. Właściwości statycznego typu AntiForgeryConfig zostały opisane poniżej. Większość użytkowników korzystających z oświadczeń chce ustawić właściwość UniqueClaimTypeIdentifier.

Właściwość Opis
AdditionalDataProvider IAntiForgeryAdditionalDataProvider, który dostarcza dodatkowe dane podczas generowania tokenu i zużywa dodatkowe dane podczas walidacji tokenu. Wartość domyślna to null. Aby uzyskać więcej informacji, zobacz sekcję IAntiForgeryAdditionalDataProvider .
Cookiename Ciąg zawierający nazwę pliku cookie HTTP używanego do przechowywania tokenu sesji anti-XSRF. Jeśli ta wartość nie jest ustawiona, nazwa zostanie wygenerowana automatycznie na podstawie wdrożonej ścieżki wirtualnej aplikacji. Wartość domyślna to null.
Requiressl Wartość logiczna, która określa, czy tokeny anti-XSRF są wymagane do przesłania za pośrednictwem kanału zabezpieczonego za pomocą protokołu SSL. Jeśli ta wartość ma wartość true, wszystkie automatycznie wygenerowane pliki cookie będą miały ustawiony flagę "secure", a interfejsy API anti-XSRF będą zgłaszane w przypadku wywołania z żądania, które nie jest przesyłane za pośrednictwem protokołu SSL. Wartość domyślna to fałsz.
SuppressIdentityHeuristicChecks Wartość logiczna, która określa, czy system anty-XSRF powinien dezaktywować obsługę tożsamości opartych na oświadczeniach. Jeśli ta wartość ma wartość true, system przyjmie, że IIdentity.Name jest odpowiedni do użycia jako unikatowy identyfikator użytkownika i nie spróbuje wykonać specjalnej próby IClaimsIdentity lub ClClaimsIdentity zgodnie z opisem w sekcji uwierzytelniania opartego na oświadczeniach/WIF/ACS. Wartość domyślna to false.
UniqueClaimTypeIdentifier Ciąg wskazujący, który typ oświadczenia jest odpowiedni do użycia jako unikatowy identyfikator użytkownika. Jeśli ta wartość jest ustawiona, a bieżąca IIdentity jest oparta na oświadczeniach, system podejmie próbę wyodrębnienia oświadczenia typu określonego przez UniqueClaimTypeIdentifier, a odpowiednia wartość zostanie użyta zamiast nazwy użytkownika podczas generowania tokenu pola. Jeśli typ oświadczenia nie zostanie znaleziony, system zakończy się niepowodzeniem żądania. Wartość domyślna to null, która wskazuje, że system powinien używać krotki (dostawcy tożsamości, identyfikatora nazwy), jak opisano wcześniej zamiast nazwy użytkownika.

IAntiForgeryAdditionalDataProvider

Typ IAntiForgeryAdditionalDataProvider umożliwia deweloperom rozszerzenie zachowania systemu anti-XSRF przez zaokrąglenie dodatkowych danych w każdym tokenie. Metoda GetAdditionalData jest wywoływana za każdym razem, gdy jest generowany token pola, a wartość zwracana jest osadzona w wygenerowanym tokenie. Implementator może zwrócić znacznik czasu, nonce lub inną wartość, którą chce z tej metody.

Podobnie metoda ValidateAdditionalData jest wywoływana za każdym razem, gdy token pola jest weryfikowany, a ciąg "dodatkowe dane", który został osadzony w tokenie, jest przekazywany do metody. Procedura walidacji może zaimplementować limit czasu (sprawdzając bieżący czas względem czasu, który był przechowywany podczas tworzenia tokenu), procedurę sprawdzania lub inną żądaną logikę.

Decyzje projektowe i zagadnienia dotyczące zabezpieczeń

Token zabezpieczający łączący tokeny sesji i pól jest technicznie niezbędny tylko podczas próby ochrony anonimowych/nieuwierzytelnionych użytkowników przed atakami XSRF. Po uwierzytelnieniu użytkownika sam token uwierzytelniania (prawdopodobnie przesłany w postaci pliku cookie) może być używany jako połowa pary tokenów synchronizatora. Istnieją jednak prawidłowe scenariusze ochrony stron logowania trafionych przez nieuwierzytelnionych użytkowników, a logika anty-XSRF została uproszczona przez zawsze generowanie i weryfikowanie tokenu zabezpieczającego, nawet dla uwierzytelnionych użytkowników. Zapewnia również dodatkową ochronę w przypadku, gdy token pola jest kiedykolwiek naruszony przez osobę atakującą, ponieważ ustawienie lub zgadywanie tokenu sesji byłoby kolejnym przeszkodą dla atakującego do pokonania.

Deweloperzy powinni zachować ostrożność, gdy wiele aplikacji jest hostowanych w jednej domenie. Na przykład mimo że example1.cloudapp.net i example2.cloudapp.net są różnymi hostami, istnieje niejawna relacja zaufania między wszystkimi hostami w domenie *.cloudapp.net . Ta niejawna relacja zaufania umożliwia potencjalnie niezaufanym hostom wpływ na pliki cookie innych (zasady tego samego źródła, które zarządzają żądaniami AJAX, niekoniecznie mają zastosowanie do plików cookie HTTP). Środowisko uruchomieniowe usługi Web Stack ASP.NET zapewnia pewne środki zaradcze, ponieważ nazwa użytkownika jest osadzona w tokenie pola, więc nawet jeśli złośliwa poddomena może zastąpić token sesji, nie będzie mógł wygenerować prawidłowego tokenu pola dla użytkownika. Jednak w przypadku hostowania w takim środowisku wbudowane procedury anty-XSRF nadal nie mogą bronić przed przejęciem sesji lub zalogowaniem XSRF.

Procedury anty-XSRF obecnie nie bronią przed kliknięciem. Aplikacje, które chcą bronić się przed przejęciem kliknięć, mogą łatwo to zrobić, wysyłając nagłówek X-Frame-Options: SAMEORIGIN z każdą odpowiedzią. Ten nagłówek jest obsługiwany przez wszystkie najnowsze przeglądarki. Aby uzyskać więcej informacji, zobacz blog IE, blog SDL i OWASP. Środowisko uruchomieniowe usługi Web Stack ASP.NET może w przyszłości sprawić, że pomocnicy MVC i Web Pages anty-XSRF automatycznie ustawić ten nagłówek, aby aplikacje zostały automatycznie chronione przed tym atakiem.

Deweloperzy sieci Web powinni nadal zapewnić, że ich witryna nie jest podatna na ataki XSS. Ataki XSS są bardzo zaawansowane, a udany program wykorzystujący luki również w zabezpieczeniach ASP.NET Web Stack Runtime przed atakami XSRF.

Potwierdzenia

@LeviBroderick, który napisał większość kodu zabezpieczeń ASP.NET większość tych informacji.