ASP.NET XSRF/CSRF-beskyttelse (Request Forgery) i denne kerne

Miljø

Visual Studio

• Visual Studio 2019

ASP.NET kerne

• 3.0
• 3.1

Hvad er falskneri på tværs af websteder?

Forfalskning af anmodninger på tværs af websteder (CSRF/XSRF) er for dem, der kun behandles på det websted, der er af interesse. Et angreb på en sårbarhed, der udfører en sådan opdateringsproces fra et eksternt websted.

Antag f.eks., at du har mulighed for at skrive kommentarer på et websted. Normalt, jeg tror, du vil skrive ved at indtaste en kommentar fra webstedet, Denne send-proces bruges oftest til at kaste data på målwebadressen.

Hvis du sender lignende data til webadressen fra en anden end målwebstedet, Det er den samme behandler du sendt.

Hvis bare en hacker ville gøre dette, ville det ikke være en trussel. Det skræmmende ting om CSRF er, at angribere kan bygge falske websteder eller integrere skjulte webadresser på webstedet. Det er her, en anden utilsigtet får adgang til det og bliver en hacker.

Jeg vil ikke gå i dybden her, så kan du finde ud af mere om cross-site anmodning forfalskninger.

ASP.NET Core inkorporerer denne modforanstaltning i rammen.

Kontrollere forfalskning af anmodninger på tværs af websteder for at fungere

Prøv at se, om opdateringsprocessen rent faktisk udføres fra eksterne websteder eller værktøjer.

Index.cshtml opretter en inputformular, der sender den tekst, du har angivet, til serveren. Placer derefter viewdata, så serveren viser meddelelser, som du har oprettet for at matche inputteksten.

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

Serverside HomeController.cs behandler den sendte tekst og udskriver den til en Visual Studio-sporing. Angiv den samme tekst til ViewData, så den kan vises for klienten.

HomeController.cs

public class HomeController : Controller
{
  // 省略

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

  // 省略
}

Prøv at udføre den funktionalitet, du lige har oprettet i de normale trin. Når du kører fejlfinding, og skærmen vises, skal du indtaste teksten og klikke på knappen Send.

Den behandlede tekst vises på skærmen som forventet.

Da det også output til sporingen udskrives, viser outputvinduet i visual studio også tekst. Faktisk gør vi ting som at registrere inputdata i en database, men vi vil ikke forenkle koden her.

Prøv nu at få adgang til programmet uden for målwebstedet, mens du foretager fejlfinding og kørsel. For enkelhed, vil jeg sende et indlæg ved hjælp af et værktøj kaldet Visual Studio Code. Hvis du kan sende POST, kan du bruge andre værktøjer eller bygge et andet websted program til angrebet.

Når du installerer en udvidelse, der hedder REST Client i Visual Studio Code, Du kan bruge en funktion, der giver dig mulighed for nemt at kontrollere driften af REST API blot ved at åbne .http-filen.

NÃ¥r du opretter en .http-fil, der ligner fà ̧lgende i en tekstfil, og derefter ã¥bner filen i Visual Studio Code, Du kan sende GET eller POST ved at klikke på Send anmodning.

Hvis du opretter følgende POST-data, vil du blive sendt næsten den samme mængde data, som du skriver tekst på skærmen og trykker på send-knappen. (Localhost-portnummeret skal være det samme som udførelsesmiljøet).

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

Når du sender den, kan du se, at serveren modtager tekst og behandler den.

Visual Studio Code kan få resultaterne. Hvis du ser nærmere på resultatkoden, kan du se, at den værdi, der er angivet for ViewData, vises. (Den vises i Unicode, men teksten vises korrekt, hvis den vises i en webbrowser).

Adresse på sårbarheden i forbindelse med anmodning om falskneri på tværs af websteder

Som jeg nævnte i begyndelsen, ASP.NET Core indeholder foranstaltninger mod cross-site anmodning forfalskning inden for rammerne. En fælles foranstaltning er at udstede en unik token til kunden på forhånd på en skærm, der kræver post, osv. Du behøver ikke at acceptere behandling, medmindre du smider tokenet til serveren.

Selvfølgelig, hvis du får adgang til webadressen direkte fra et eksternt websted, token er ukendt og vil ikke acceptere behandling.

Først vil jeg gerne tale om udstedelse af tokens til klienten (HTML), men faktum er, at rammerne ikke er i stand til at gøre dette. Vil gå. Hvis du angiver en POST-metode i formularkoden, kan du integrere tokenparametre i HTML uden tilladelse.

I HTML nedenfor er det inputname="__RequestVerificationToken" type="hidden". Dette sendes til serveren sammen, når der trykkes på send-knappen. Af den måde, er det ikke vedlagt af GET metode.

På serversiden Startup.cs tjenester. AddControllersWithViews-metodeindstillinger. Filtrerer til AutomatiskValideringAntiforgeryTokenAttribute, alle handlinger Denne tokenkontrol føjes automatisk til (for at være nøjagtig kun HTTP-metoderne post, PUT, PATCH og DELETE).

Hvis du kun vil føje denne begrænsning til bestemte handlinger, ikke alle handlinger pr. controller, pr. handling Det er også muligt at indstille.

Hvis du derimod vil indføre begrænsninger for de fleste handlinger, men du vil ekskludere bestemte Hvis du indstiller attributten IgnoreAntiforgeryToken til controlleren og handlingen, er det 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());
  });
}

Lad os se, hvordan det virker. Først og fremmest er transmissionsprocessen sker fra skærmen normalt.

Resultaterne blev afspejlet på skærmen som forventet.

Det er også output til sporet.

Lad os prøve at få adgang til det udefra.

Adgang ed, men Bad Request blev returneret. Det er et andet resultat, end når du ikke tager forholdsregler. Det er underforstået, at det er bevogtet, fordi det ikke er output til sporet.

Resumé

Denne gang forsøgte jeg at gennemføre foranstaltninger mod cross-site anmodning forfalskninger. Det var meget let at gennemføre, fordi det allerede var indbygget i rammen.

Opbygning af et websted kræver meget mere sårbarhed end CSRF. Du kan kontrollere, hvad der er derude, eller du kan bruge værktøjer som OWASP til at kontrollere for sårbarheder i dit websted.