Rdzeń ASP.NET

ASP.NET ochrony fałszerskości (XSRF/CSRF) w tym rdzeniu

Strona zaktualizowana :
Data utworzenia strony :

Środowiska

Visual Studio
  • Visual Studio 2019
Rdzeń ASP.NET
  • 3.0
  • 3.1

Co to jest fałszerstwo żądań między siedzibą witryny?

Fałszerstwo żądań między siedzibą witryny (CSRF/XSRF) jest przeznaczone dla tych, które są przetwarzane tylko w obrębie witryny będącej przedmiotem zainteresowania. Atak na lukę w zabezpieczeniach, która wykonuje taki proces aktualizacji z lokacji zewnętrznej.

Załóżmy na przykład, że masz możliwość publikowania komentarzy w witrynie. Normalnie, myślę, że będzie pisać, wprowadzając komentarz z witryny, Ten proces wysyłania jest najczęściej używany do przesyłania danych w docelowym adresie URL.

W związku z tym, jeśli wyślesz podobne dane do adresu URL od osoby innej niż witryna docelowa, To ten sam smakołyk, który opublikowałeś.

Jeśli tylko osoba atakująca to zrobi, nie byłoby zagrożeniem. Przerażające w CSRF jest to, że atakujący mogą budować fałszywe witryny lub osadzać ukryte adresy URL w witrynie. To miejsce, w którym ktoś inny nieumyślnie uzyskuje do niego dostęp i staje się osobą atakującą.

Nie będę się tu zagłębiać, więc dowiedz się więcej o fałszerstwach z prośbą o cross-site.

ASP.NET Core włącza ten zaradcz do ram.

Sprawdź fałszerstwo żądań między siedzibą firmy do pracy

Spróbuj sprawdzić, czy proces aktualizacji jest rzeczywiście wykonywany z zewnętrznych witryn lub narzędzi.

Index.cshtml tworzy formularz wejściowy, który wysyła wprowadzony tekst do serwera. Następnie umieść viewdata tak, aby serwer wyświetlał wiadomości, które zostały utworzone w celu dopasowania tekstu wejściowego.

Indeks.cshtml

@{
  ViewData["Title"] = "Home Page";
}

<div class="text-center">
  <h1 class="display-4">Welcome</h1>
  <p>Learn about <a href="https://docs.microsoft.com/aspnet/core">building Web apps with ASP.NET Core</a>.</p>
</div>

<form method="post">
  <input type="text" name="text" />
  <button type="submit">送信</button>
</form>

<p>@ViewData["Message"]</p>

HomeController.cs po stronie serwera przetwarza wysłany tekst i wyprowadza go do śledzenia programu Visual Studio. Ustaw ten sam tekst na ViewData, tak aby mógł być wyświetlany klientowi.

HomeController.cs

public class HomeController : Controller
{
  // 省略

  [HttpPost]
  public IActionResult Index(string text)
  {
    System.Diagnostics.Trace.WriteLine($"「{text}」が入力されました。");
    ViewData["Message"] = $"「{text}」が入力されました。";
    return View();
  }

  // 省略
}

Spróbuj wykonać funkcje, które właśnie utworzono w normalnych krokach. Po uruchomieniu debugowania i wyświetleniu ekranu wprowadź tekst i kliknij przycisk Prześlij.

Przetworzony tekst pojawi się na ekranie zgodnie z oczekiwaniami.

Ponieważ jest również dane wyjściowe do śledzenia, okno wyjściowe visual studio wyświetla również tekst. W rzeczywistości robimy takie rzeczy, jak rejestrowanie danych wejściowych w bazie danych, ale nie zamierzamy uprościć kodu tutaj.

Teraz spróbuj uzyskać dostęp do programu spoza witryny docelowej podczas debugowania i uruchamiania. Dla uproszczenia opublikuję post za pomocą narzędzia o nazwie Visual Studio Code. Jeśli możesz wysłać POST, możesz użyć innych narzędzi lub zbudować inny program witryny do ataku.

Po zainstalowaniu rozszerzenia o nazwie KLIENT REST w programie Visual Studio Code, Można użyć funkcji, która pozwala łatwo sprawdzić działanie interfejsu API REST tylko przez otwarcie pliku .http.

Podczas tworzenia pliku .http podobnego do następującego w pliku tekstowym, a następnie otwierania pliku w programie Visual Studio Code, Możesz wysłać GET lub POST, klikając wyślij żądanie.

Jeśli utworzysz następujące dane POST, zostanie wysłana prawie taka sama ilość danych, jak wpisujesz tekst na ekranie i naciśnij przycisk prześlij. (Numer portu localhost powinien być taki sam jak środowisko wykonywania).

RestTest.http://www.restTest.http

### Form で POST 送信
POST https://localhost:44372/home/index HTTP/1.1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="text"

なんらかのテキスト
------WebKitFormBoundary7MA4YWxkTrZu0gW--

Po wysłaniu go widać, że serwer odbiera tekst i przetwarza go.

Visual Studio Code można uzyskać wyniki. Jeśli przyjrzeć się bliżej kodu wynik, widać, że wartość ustawiona dla ViewData jest wyświetlany. (Jest on wyświetlany w Unicode, ale tekst jest wyświetlany poprawnie, jeśli jest wyświetlany w przeglądarce sieci Web.)

Usterka za fałszerstwo żądań między witrynami

Jak już wspomniałem na początku, ASP.NET Core włącza w ramach środki przeciwko fałszerskości wniosków o wzajemne wskazanie. Częstym środkiem jest wydanie unikatowego tokenu klientowi z wyprzedzeniem na ekranie, który wymaga postu itp. Nie musisz akceptować przetwarzania, chyba że zrzucisz token na serwer.

Oczywiście jeśli uzyskujesz dostęp do adresu URL bezpośrednio z witryny zewnętrznej, token jest nieznany i nie zaakceptuje przetwarzania.

Po pierwsze, chciałbym porozmawiać o wydawaniu tokenów do klienta (HTML), ale faktem jest, że ramy nie jest w stanie to zrobić. Pójdzie. Jeśli określisz metodę POST w tagu formularza, można włączyć parametry tokenu do kodu HTML bez uprawnień.

W html poniżej jest nazwa wejściowa = "__RequestVerificationToken" type="hidden". Jest to wysyłane do serwera razem po naciśnięciu przycisku wyślij. Nawiasem mówiąc, nie jest dołączany przez GET metody.

Po stronie serwera Startup.cs usługi. Opcje metody AddControllersWithViews. Filtry do AutoValidateAntiforgeryTokenAttribute, wszystkie akcje Ten czek tokenu jest automatycznie dodawany do (dokładnie tylko metody HTTP POST, PUT, PATCH i DELETE).

Jeśli chcesz dodać to ograniczenie tylko do określonych akcji, nie wszystkich akcji, na kontroler, na akcję Możliwe jest również ustawienie.

Z drugiej strony, jeśli chcesz nałożyć ograniczenia na większość działań, ale chcesz wykluczyć określone akcje, Jeśli ustawisz IgnoreAntiforgeryToken atrybut do kontrolera i akcji, jest OK.

Startup.cs

public void ConfigureServices(IServiceCollection services)
{
  services.AddControllersWithViews(options =>
  {
    // 全ての「POST, PUT, PATCH, DELETE」アクションに自動で ValidateAntiForgeryToken を付与。
    // 個別に除外したい場合は「IgnoreAntiforgeryToken」属性を指定すること
    // API では HTML 側にトークンを発行できないのでコントローラーに「IgnoreAntiforgeryToken」を指定する必要がある。
    options.Filters.Add(new Microsoft.AspNetCore.Mvc.AutoValidateAntiforgeryTokenAttribute());
  });
}

Zobaczmy, jak to działa. Przede wszystkim proces transmisji odbywa się normalnie z ekranu.

Wyniki zostały odzwierciedlone na ekranie zgodnie z oczekiwaniami.

Jest również dane wyjściowe do śledzenia.

Teraz spróbujmy uzyskać do niego dostęp z zewnątrz.

Dostęp do programu, ale zła prośba została zwrócona. To inny wynik niż wtedy, gdy nie podejmujesz działań. Rozumie się, że jest strzeżony, ponieważ nie jest wyprowadzany do śledzenia.

Krótki opis

Tym razem próbowałem wdrożyć środki przeciwko forgeri wniosek cross-site. Było to bardzo łatwe do wdrożenia, ponieważ zostało już wbudowane w ramy.

Tworzenie witryny sieci Web wymaga znacznie większej podatności niż csrf. Możesz sprawdzić, co tam jest, lub użyć narzędzi, takich jak OWASP, aby sprawdzić, czy nie ma luk w witrynie.

Zobacz, jak działa appsettings.json
Zobacz, jak działa podsumowanie walidacji asp