ASP.NET Core

ASP.NET (XSRF/CSRF) védelem ebben a magban

Oldal frissítve :
Oldal létrehozásának dátuma :

Környezet

Vizuális stúdió
  • Visual Studio 2019
ASP.NET Core
  • 3.0
  • 3.1

Mi az a több telephelyre vonatkozó kérelem forgeri?

A helyszíni kérelmek hamisítása (CSRF/XSRF) azoknak szól, amelyeket csak az érdeklődési területen dolgoznak fel. Támadás egy olyan biztonsági rés ellen, amely külső helyről hajt végre ilyen frissítési folyamatot.

Tegyük fel például, hogy ön képes megjegyzéseket tenni egy webhelyen. Normális esetben, azt hiszem, akkor tegye meg a belépő egy megjegyzést az oldalon, Ezt a küldési folyamatot leggyakrabban arra használják, hogy adatokat dobjanak a cél URL-re.

Ezért ha a célwebhelytől eltérő személytől küld hasonló adatokat az URL-címre, Ugyanaz a bánásmód, amit te küldtél.

Ha csak egy támadó tenne ilyet, az nem jelentene fenyegetést. A CSRF-ben az az ijesztő, hogy a támadók hamis webhelyeket építhetnek, vagy rejtett URL-eket ágyazhatnak be az oldalon. Ez az a hely, ahol valaki véletlenül hozzáfér hozzá, és támadóvá válik.

Nem megyek a mélység be itt, ezért kérjük, tudjon meg többet a cross-site kérelmet forgeri.

ASP.NET Core beépíti ezt az ellenintézkedést a keretbe.

Ellenőrizze a több telephelyre vonatkozó kérelem hamisítását a munka érdekében

Próbálja meg megnézni, hogy a frissítési folyamat ténylegesen külső webhelyekről vagy eszközökről történik-e.

Az Index.cshtml létrehoz egy bemeneti űrlapot, amely elküldi a beírt szöveget a kiszolgálónak. Ezután helyezze el a nézetadatokat úgy, hogy a kiszolgáló a bemeneti szövegnek megfelelően létrehozott üzeneteket jelenítse meg.

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>

A kiszolgálóoldali HomeController.cs feldolgozza az elküldött szöveget, és kiírja azt egy Visual Studio-nyomkövetésre. Állítsa be ugyanazt a szöveget a ViewData nézetbe, hogy az megjeleníthető legyen az ügyfél számára.

HomeController.cs

public class HomeController : Controller
{
  // 省略

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

  // 省略
}

Próbálja meg végrehajtani az imént létrehozott funkciót a normál lépésekben. Amikor futtatja a hibakeresést, és megjelenik a képernyő, írja be a szöveget, és kattintson a Küldés gombra.

A feldolgozott szöveg a várt módon jelenik meg a képernyőn.

Mivel a nyomkövetésre is kimenet, a visual studio kimeneti ablaka szöveget is jelenít meg. Valójában olyan dolgokat teszünk, mint a bemeneti adatok regisztrálása egy adatbázisban, de itt nem fogjuk egyszerűsíteni a kódot.

Most próbálja meg elérni a programot a célwebhelyen kívülről, miközben hibakeresést és futtatást folytat. Az egyszerűség kedvéért, én utáni utáni segítségével nevű eszköz Visual Studio Code. Ha tud szkitel POST, akkor más eszközöket, vagy építeni egy másik site program a támadás.

Ha egy REST Client nevű bővítményt telepít a Visual Studio-kódba, A .http fájl megnyitásával egyszerűen ellenőrizheti a REST API működését.

Ha egy szövegfájlban az alábbiakhoz hasonló .http fájlt hoz létre, majd megnyitja a fájlt a Visual Studio-kódban, Get vagy POST küldéshez kattintson a küldési kérelemre.

Ha létrehozza a következő POST adatokat, akkor majdnem ugyanannyi adatot kap, mint a szöveget a képernyőn, és nyomja meg a küldés gombot. (A Localhost port számának meg kell egyeznie a végrehajtási környezettel.)

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

Amikor elküldi, láthatja, hogy a kiszolgáló fogadja és feldolgozza a szöveget.

A Visual Studio Code megkaphatja az eredményeket. Ha közelebbről szemügyre veszi az eredménykódot, láthatja, hogy a ViewData értékhalmaza megjelenik. (Unicode kódolással jelenik meg, de a szöveg megfelelően jelenik meg, ha webböngészőben tekinti meg.)

Webhelyközi kérelem hamisítási biztonsági résének kezelése

Amint azt már az elején említettem, ASP.NET Core a keretben intézkedéseket tartalmaz a helyszíni kérelmek hamisítása ellen. Egy közös intézkedés, hogy kiad egy egyedi jogkivonatot az ügyfél előre a képernyőn, amely előírja, posta, stb. Nem kell elfogadnia a feldolgozást, hacsak nem dobja a tokent a kiszolgálóra.

Természetesen, ha közvetlenül egy külső webhelyről éri el az URL-címet, a jogkivonat ismeretlen, és nem fogadja el a feldolgozást.

Először is, szeretnék beszélni jogkivonatok kibocsátásáról az ügyfélnek (HTML), de az a tény, hogy a keretrendszer nem képes erre. El fog menni. Ha post metódust ad meg az űrlapcímkében, a tokenparamétereket engedély nélkül beépítheti a HTML-be.

Az alábbi HTML-ben a bemeneti name="__RequestVerificationToken" type="hidden". A küldés gomb megnyomásakor a rendszer együtt küldi el a kiszolgálónak. By the way, ez nem csatolja a GET módszer.

A szerver oldalon Startup.cs szolgáltatásokat. AddControllersWithViews metódus beállításait. Szűrők AutoValidateAntiforgeryTokenAttribute, minden művelet Ez a tokenellenőrzés automatikusan hozzáadódik (hogy pontos legyek, csak a POST, PUT, PATCH és DELETE HTTP-módszerei).

Ha ezt a korlátozást csak bizonyos műveletekhez szeretné hozzáadni, nem minden művelethez, vezérlőnként, műveletenként Az is lehetséges, hogy állítsa be.

Ezzel szemben, ha a legtöbb műveletre korlátozásokat szeretne bevezetni, de ki szeretné zárni a konkrét Ha az IgnoreAntiforgeryToken attribútumot állítja be a vezérlőhöz és a művelethez, akkor rendben van.

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ássuk, hogy működik. Először is, az átviteli folyamat történik a képernyőn rendesen.

Az eredmények a várt módon tükröződtek a képernyőn.

Azt is kimeneta a nyomkövetés.

Most pedig próbáljunk meg kívülről hozzáférni.

Hozzáférés, de a hibás kérés tért vissza. Ez más eredmény, mint amikor nem mész. Magától értetődik, hogy őrzött, mert nem kimeneta a nyomra.

Összefoglaló

Ezúttal megpróbáltam végrehajtani intézkedések ellen cross-site kérelmet forgeri. Nagyon könnyű volt végrehajtani, mert már be épült a keretbe.

A webhely létrehozása sokkal több biztonsági rést igényel, mint a CSRF. Ellenőrizheti, hogy mi van odakint, vagy használhatja az oWASP-hoz hasonló eszközöket, hogy ellenőrizze a webhely biztonsági réseit.

Az appsettings.json működése
Az asp-validation-summary működése