ASP.NET de protecție pentru falsificarea solicitării (XSRF/CSRF) în acest nucleu

Pagina actualizată : joi, 1 aprilie 2021

Data creării paginii : luni, 25 mai 2020

Mediu

Discutii pe forum Visual C

Discutii pe forum Visual C...

ASP.NET Core

Ce este cross-site-ul cerere forgeri?

Falsificarea cererii de pe amplasament (CSRF/XSRF) este pentru cele care sunt procesate numai în cadrul site-ului de interes. Un atac asupra unei vulnerabilități care efectuează un astfel de proces de actualizare de la un site extern.

De exemplu, să presupunem că aveți posibilitatea de a posta comentarii pe un site web. În mod normal, cred că veți posta prin introducerea unui comentariu de pe site-ul, Acest proces de trimitere este cel mai adesea utilizat pentru a arunca date la adresa URL țintă.

Prin urmare, dacă trimiteți date similare cu ADRESA URL de la o altă persoană decât site-ul țintă, E același tratament pe care l-ai postat.

Dacă un atacator ar face asta, nu ar fi o amenințare. Lucru înfricoșător despre CSRF este că atacatorii pot construi site-uri false sau embed URL-uri ascunse în site-ul. Este locul unde altcineva accesează neintenționat și devine un atacator.

Eu nu va intra în profunzime aici, așa că vă rugăm să aflați mai multe despre cross-site-ul cerere forgeri.

ASP.NET Core încorporează această contramăsură în cadru.

Verificați falsificarea solicitării la nivel inter-site la locul de muncă

Încercați să vedeți dacă procesul de actualizare este efectiv efectuat de la site-uri externe sau instrumente.

Index.cshtml creează un formular de intrare care trimite textul introdus pe server. Apoi plasați viewdata astfel încât serverul să afișeze mesajele pe care le-ați creat pentru a se potrivi cu textul de intrare.

Index.cshtml (în)

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

Server-side HomeController.cs procesează textul trimis și afișează-l la o urmă Visual Studio. Setați același text la ViewData astfel încât să poată fi afișat la client.

HomeController.cs

public class HomeController : Controller
{
  // 省略

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

  // 省略
}

Încercați să efectuați funcționalitatea pe care tocmai ați creat-o în pașii normali. Când executați depanareși apare ecranul, introduceți textul și faceți clic pe butonul Remitere.

Textul procesat apare pe ecran conform așteptărilor.

Deoarece este, de asemenea, de ieșire la urma, fereastra de ieșire studio vizual afișează, de asemenea, text. De fapt, facem lucruri ar fi înregistrarea datelor de intrare într-o bază de date, dar nu vom simplifica codul aici.

Acum, încercați să accesați programul din afara site-ului țintă în timp ce depanarea și rularea. Pentru simplitate, voi posta un post folosind un instrument numit Visual Studio Code. Dacă puteți trimite POST, puteți utiliza alte instrumente sau de a construi un alt program de site-ul pentru atac.

Când instalați o extensie numită REST Client în Visual Studio Code, Puteți utiliza o caracteristică care vă permite să verificați cu ușurință funcționarea REST API doar prin deschiderea fișierului .http.

Când creați un fișier .http similar cu următorul într-un fișier text, și apoi deschideți fișierul în Visual Studio Code, Puteți trimite GET sau POST făcând clic pe trimite cerere.

Dacă creați următoarele date POST, vi se vor trimite aproape aceeași cantitate de date pe măsură ce tastați text pe ecran și apăsați butonul de remitere. (Localhost port număr ar trebui să fie la fel ca mediul de executare.)

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

Când îl trimiteți, puteți vedea că serverul primește text și îl procesează.

Visual Studio Code poate obține rezultatele. Dacă aruncați o privire mai atentă la codul de rezultat, puteți vedea că se afișează valoarea setată pentru ViewData. (Se afișează în Unicode, dar textul este afișat corect dacă este vizualizat într-un browser Web.)

Adresa cross-site solicitare forgeri vulnerabilitate

După am menționat la început, ASP.NET Core încorporează măsuri împotriva falsificării cererii la nivel internațional în cadru. O măsură comună este de a emite un simbol unic pentru client în avans pe un ecran care necesită post, etc Nu trebuie să acceptați procesarea decât dacă aruncați simbolul pe server.

Desigur, dacă accesați URL-ul direct de pe un site extern, simbolul este necunoscut și nu va accepta procesarea.

În primul rând, aș dori să vorbesc despre emiterea de jetoane pentru client (HTML), dar faptul este că cadrul nu este în măsură să facă acest lucru. Va pleca. Dacă specificați o metodă POST în eticheta de formular, puteți încorpora parametrii simbolului în HTML fără permisiune.

În HTML de mai jos, este numele de intrare = "__RequestVerificationToken" tip = "ascunse". Acest lucru este trimis la server împreună atunci când butonul de trimitere este apăsat. Apropo, nu este anexată prin metoda GET.

Pe partea de server, Startup.cs servicii. Opțiuni metodă AddControllersWithViews. Filtre pentru a AutoValidateAntiforgeryTokenAttribute, toate acțiunile Această verificare simbol este adăugată automat la (pentru a fi exact numai metodele HTTP de POST, PUT, PATCH și DELETE).

Dacă doriți să adăugați această restricție numai la acțiuni specifice, nu la toate acțiunile, per controler, per acțiune De asemenea, este posibil să se stabilească.

În schimb, dacă doriți să impuneți restricții pentru majoritatea acțiunilor, dar doriți să excludeți anumite acțiuni, Dacă setați atributul IgnoreAntiforgeryToken controlerului și acțiune, este 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());
  });
}

Să vedem funcționează. Mai întâi de toate, procesul de transmisie se face de pe ecran în mod normal.

Rezultatele s-au reflectat pe ecran așa era de așteptat.

Este, de asemenea, de ieșire la urma.

Acum, să încercăm să-l accesez din exterior.

S-a făcut acces, dar s-a restititititat cererea. E un rezultat diferit de cel în care nu iei măsuri. Se înțelege că este păzită pentru că nu este de ieșire la urme.

Rezumat

De data aceasta am încercat să pună în aplicare măsuri împotriva cross-site-ul cerere forgeri. A fost foarte ușor de pus în aplicare, deoarece a fost deja construit în cadru.

Construirea unui site Web necesită o vulnerabilitate mult mai mare decât CSRF. Puteți verifica ce este acolo sau puteți utiliza instrumente precum OWASP pentru a căuta vulnerabilități în site-ul dvs.

Vedeți funcționează appsettings.json

Vedeți funcționează asp-validation-summary