ASP.NET förfalskningsskydd (XSRF/CSRF) i den här kärnan

Sidan uppdaterad :
Datum för skapande av sida :

Miljö

Visuell studio
  • Visual Studio 2019
ASP.NET kärna
  • 3.0
  • 3.1

Vad är förfalskning av begäran på flera webbplatser?

Förfalskning av begäran på flera platser (CSRF/XSRF) är för dem som endast bearbetas inom den plats av intresse. En attack på ett säkerhetsproblem som utför en sådan uppdateringsprocess från en extern webbplats.

Anta till exempel att du har möjlighet att skriva kommentarer på en webbplats. Normalt tror jag att du kommer att skriva genom att ange en kommentar från webbplatsen, Den här sändningsprocessen används oftast för att kasta data på måladressen.

Om du skickar liknande data till webbadressen från någon annan än målwebbplatsen Det är samma behandling du postat.

Om bara en angripare skulle göra detta, skulle det inte vara ett hot. Det skrämmande med CSRF är att angripare kan bygga falska webbplatser eller bädda in dolda webbadresser på webbplatsen. Det är där någon annan oavsiktligt kommer åt den och blir en angripare.

Jag kommer inte att gå in på djupet här, så ta reda på mer om cross-site begäran forgeri.

ASP.NET Core införlivar denna motåtgärd i ramen.

Kontrollera förfalskning av begäran på flera webbplatser för att arbeta

Försök att se om uppdateringsprocessen verkligen utförs från externa webbplatser eller verktyg.

Index.cshtml skapar ett indataformulär som skickar texten du angav till servern. Placera sedan vydata så att servern visar meddelanden som du har skapat för att matcha indatatexten.

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>

Serversidan HomeController.cs bearbetar den skickade texten och matar ut den till en Visual Studio-spårning. Ange samma text till ViewData så att den kan visas för klienten.

HomeController.cs

public class HomeController : Controller
{
  // 省略

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

  // 省略
}

Försök att utföra de funktioner som du just skapade i de normala stegen. När du kör felsökning och skärmen visas anger du texten och klickar på skicka-knappen.

Den bearbetade texten visas som förväntat på skärmen.

Eftersom det också matas ut till spårningen visar utdatafönstret i den visuella studion också text. Faktum är att vi gör saker som att registrera indata i en databas, men vi kommer inte att förenkla koden här.

Försök nu komma åt programmet utanför målplatsen medan du felsöker och körs. För enkelhetens skull, jag lägger upp ett inlägg med hjälp av ett verktyg som heter Visual Studio Code. Om du kan skicka POST kan du använda andra verktyg eller bygga ett annat platsprogram för attacken.

När du installerar ett tillägg som heter REST-klient i Visual Studio-kod Du kan använda en funktion som gör att du enkelt kan kontrollera driften av REST API bara genom att öppna .http-filen.

När du skapar en HTTP-fil som liknar följande i en textfil och sedan öppnar filen i Visual Studio-kod Du kan skicka GET eller POST genom att klicka på skicka begäran.

Om du skapar följande POST-data kommer du att skickas nästan lika mycket data som du skriver text på skärmen och trycker på skicka-knappen. (Localhost-portnumret ska vara samma som körningsmiljön.)

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 skickar den kan du se att servern tar emot text och bearbetar den.

Visual Studio Code kan få resultaten. Om du tittar närmare på resultatkoden kan du se att värdet för ViewData visas. (Den visas i Unicode, men texten visas korrekt om den visas i en webbläsare.)

Åtgärda begäran om förfalskning på flera webbplatser

Som jag nämnde i början innehåller ASP.NET Core åtgärder mot begäran om förfalskning över flera webbplatser inom ramen. En vanlig åtgärd är att utfärda en unik token till klienten i förväg på en skärm som kräver inlägg, etc. Du behöver inte acceptera bearbetning om du inte kastar token till servern.

Om du öppnar webbadressen direkt från en extern webbplats är token okänd och accepterar inte bearbetning.

Först skulle jag vilja tala om att utfärda tokens till klienten (HTML), men faktum är att ramen inte kan göra detta. Kommer att gå. Om du anger en POST-metod i formulärtaggen kan du infoga tokenparametrar i HTML utan behörighet.

I HTML nedan är det indatanamnet="__RequestVerificationToken" type="hidden". Detta skickas till servern tillsammans när skicka-knappen trycks in. Förresten, det är inte bifogas av GET-metoden.

På serversidan Startup.cs tjänster. AddControllersWithViews metodalternativ. Filter till AutoValidateAntiforgeryTokenAttribute, alla åtgärder Den här tokenkontrollen läggs automatiskt till (för att endast vara exakt HTTP-metoderna för POST, PUT, PATCH och DELETE).

Om du bara vill lägga till det här villkoret för specifika åtgärder, inte alla åtgärder, per styrenhet, per åtgärd Det är också möjligt att ställa in.

Omvänt, om du vill införa begränsningar för de flesta åtgärder, men du vill utesluta specifika åtgärder, Om du ställer in attributet IgnoreAntiforgeryToken till styrenheten och åtgärden är 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());
  });
}

Låt oss se hur det fungerar. Först och främst görs överföringsprocessen från skärmen normalt.

Resultaten återspeglades på skärmen som förväntat.

Det är också utdata till spåret.

Nu ska vi försöka komma åt den från utsidan.

Åtkomst, men felaktig begäran returnerades. Det är ett annat resultat än när du inte vidtar åtgärder. Det är underförstått att det är bevakat eftersom det inte är utdata till spåret.

Sammanfattning

Den här gången försökte jag genomföra åtgärder mot cross-site begäran forgeri. Det var mycket lätt att genomföra eftersom det redan var inbyggt i ramen.

Att bygga en webbplats kräver mycket mer sårbarhet än CSRF. Du kan kontrollera vad som finns där ute, eller så kan du använda verktyg som OWASP för att söka efter sårbarheter på din webbplats.