ASP.NET nucli

Protecció de falsificació de sol·licitud de ASP.NET (XSRF/CSRF) en aquest nucli

Pàgina actualitzada :
Data de creació de la pàgina :

Medi ambient

Visual Studio
  • Visual Studio 2019
ASP.NET Core
  • 3,0
  • 3,1

Què és la petició de cross-site forgeri?

La falsificació de peticions de lloc (CSRF/XSRF) és per a aquells que es processen només dins del lloc d'interès. Un atac a una vulnerabilitat que realitza aquest procés d'actualització des d'un lloc extern.

Per exemple, suposem que teniu la possibilitat d'enviar comentaris en un lloc web. Normalment, penso que enviaré introduint un comentari des del lloc, Aquest procés d'enviament s'utilitza més sovint per llançar dades a l'URL de destinació.

Per tant, si envieu dades similars a l'URL d'una altra persona que no sigui el lloc de destinació, És el mateix tractar-lo enviat.

Si només un atacant faria això, no seria una amenaça. La cosa de por sobre CSRF és que els atacants poden construir llocs falsos o incrustar URLs ocults en el lloc. És on una altra persona l'accedeix sense voler i es converteix en un atacant.

No entraré en profunditat aquí, així que si us plau esbrinar més sobre la sol. licitud cross-site forgeri.

ASP.NET Core incorpora aquesta contramesura en el marc.

Comprovar la falsificació de peticions de lloc per treballar

Intenteu veure si el procés d'actualització es realitza de fet des de llocs o eines externs.

Index. cshtml crea un formulari d'entrada que envia el text que heu introduït al servidor. A continuació, col·loqueu viewdata perquè el servidor mostri els missatges que heu creat per coincidir amb el text d'entrada.

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>

El HomeController.cs del costat del servidor processa el text enviat i el produeix a un rastre d'estudi visual. Establiu el mateix text a ViewData perquè es mostri al client.

HomeController.cs

public class HomeController : Controller
{
  // 省略

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

  // 省略
}

Proveu de realitzar la funcionalitat que acaba de crear en els passos normals. Quan executeu la depuració i la pantalla apareix, introduïu el text i feu clic al botó envia.

El text processat apareix a la pantalla tal com estava esperat.

Com que també és sortida a la traça, la finestra de sortida de Visual Studio també mostra text. De fet, fem coses com registrar les dades d'entrada en una base de dades, però no anem a simplificar el codi aquí.

Ara, proveu d'accedir al programa des de fora del lloc de destinació mentre es depura i s'executa. Per simplicitat, enviaré un correu que utilitza una eina anomenada codi d'estudi visual. Si pot enviar correu, pot utilitzar unes altres eines o construir un altre programa de llocs per a l'atac.

Quan instal·leu una extensió anomenada Rest client en el codi de Visual Studio, Podeu utilitzar una característica que us permet comprovar fàcilment el funcionament de l'API REST només obrint el fitxer. http.

Quan creeu un fitxer. http similar al següent en un fitxer de text i, a continuació, obriu el fitxer al codi de Visual Studio, Podeu enviar-lo o publicar-lo fent clic a envia la sol·licitud.

Si creeu les dades de correu següents, se us enviarà gairebé la mateixa quantitat de dades a mesura que escriviu text a la pantalla i premeu el botó envia. (El número de Port localhost hauria de ser el mateix que l'entorn d'execució).

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

Quan l'envieu, podeu veure que el servidor rep el text i el processa.

El codi de Visual Studio pot obtenir els resultats. Si doneu un cop d'ull més al codi de resultats, podeu veure que es Mostra el valor definit per a ViewData. (Es mostra en Unicode, però el text es Mostra correctament si s'ha visualitzat en un navegador web).

Adreça de la Creu de lloc de la sol licitud de vulnerabilitat forgeri

Com he esmentat al principi, ASP.NET Core incorpora mesures contra la falsificació de peticions de llocs en el marc. Una mesura comuna és emetre una fitxa única al client per endavant en una pantalla que requereixi correu, etc. No heu d'acceptar el processament llevat que llenceu el testimoni al servidor.

Naturalment, si accedeix a l'URL directament d'un lloc extern, el testimoni és desconegut i no acceptarà processament.

En primer lloc, m'agradaria parlar sobre l'emissió de fitxes al client (HTML), però el fet és que el marc no és capaç de fer això. Anirà. Si especifiqueu un mètode de publicació a l'etiqueta del formulari, podeu incorporar paràmetres de testimoni a HTML sense permís.

En el codi HTML següent, és el nom d'entrada = "__RequestVerificationToken" type = "ocult". Aquest s'envia al servidor quan es prem el botó envia. Per cert, no és annexat pel mètode GET.

Al costat del servidor, Startup.cs serveis. Les opcions del mètode AddControllersWithViews. Filtres per Autovalidateantiforgerytokenattribute, totes les accions Aquesta comprovació de testimoni s'afegeix automàticament (per a ser exactes només els mètodes HTTP de POST, PUT, PATCH i DELETE).

Si voleu afegir aquesta restricció només a accions concretes, no totes les accions, per controlador, per acció També és possible establir.

Per contra, si voleu imposar restriccions a la majoria d'accions, però voleu excloure accions concretes, Si definiu l'atribut Ignoreantiforgerytoken al controlador i l'acció, està bé.

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());
  });
}

Anem a veure com funciona. En primer lloc, el procés de transmissió es realitza des de la pantalla amb normalitat.

Els resultats van ser reflectits a la pantalla com s'esperava.

També és sortida a la traça.

Ara, intentarem accedir-hi des de l'exterior.

Accés Ed, però mal petició va ser retornat. És un resultat diferent que quan vostè no està prenent mesures. S'entén que es protegeix perquè no és sortida a la traça.

Resum

Aquesta vegada intentava implementar mesures contra forgeri de petició de lloc. Va ser molt fàcil d'implementar perquè ja estava incorporat en el marc.

La construcció d'un lloc web requereix molt més vulnerabilitat que CSRF. Pots consultar el que hi ha fora, o pots utilitzar eines com OWASP per comprovar les vulnerabilitats del teu lloc web.

Veure com funciona appsettings.json
Veure com funciona l'asp-validation-summary