ASP.NET la demande de contrefaçon (XSRF/CSRF) dans ce noyau

Page mise à jour : jeudi 1 avril 2021

Date de création de la page : lundi 25 mai 2020

Environnement

Studio visuel

Studio visuel 2019

ASP.NET cœur

Qu’est-ce que la demande transversale forgée?

La contrefaçon de demande croisée (CSRF/XSRF) s’adresse à celles qui ne sont traitées qu’à l’intérieur du site d’intérêt. Une attaque contre une vulnérabilité qui effectue un tel processus de mise à jour à partir d’un site externe.

Supposons, par exemple, que vous ayez la possibilité de publier des commentaires sur un site Web. Normalement, je pense que vous allez poster en entrant un commentaire du site, Ce processus d’envoi est le plus souvent utilisé pour jeter des données à l’URL cible.

Par conséquent, si vous envoyez des données similaires à l’URL de quelqu’un d’autre que le site cible, C’est la même gâterie que vous avez affichée.

Si seulement un attaquant le ferait, ce ne serait pas une menace. Ce qui est effrayant avec le CSRF, c’est que les attaquants peuvent construire de faux sites ou intégrer des URL cachées sur le site. C’est là que quelqu’un d’autre y accède involontairement et devient un attaquant.

Je n’irai pas en profondeur ici, alors s’il vous plaît en savoir plus sur cross-site demande forgeri.

ASP.NET Core intègre cette contre-mesure dans le cadre.

Vérifier la contrefaçon de demande de site transversal au travail

Essayez de voir si le processus de mise à jour est effectivement effectué à partir de sites ou d’outils externes.

Index.cshtml crée un formulaire d’entrée qui envoie le texte que vous avez entré sur le serveur. Placez ensuite les données de viewdata afin que le serveur affiche les messages que vous avez créés pour correspondre au texte d’entrée.

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>

Côté serveur, HomeController.cs traite le texte envoyé et le produit à une trace visual studio. Définissez le même texte sur ViewData afin qu’il puisse être affiché au client.

HomeController.cs

public class HomeController : Controller
{
  // 省略

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

  // 省略
}

Essayez d’effectuer la fonctionnalité que vous venez de créer dans les étapes normales. Lorsque vous exécutez le débogage et que l’écran s’affiche, entrez le texte et cliquez sur le bouton Soumettre.

Le texte traité apparaît à l’écran comme prévu.

Parce qu’il est également la sortie à la trace, la fenêtre de sortie studio visuel affiche également le texte. En fait, nous faisons des choses comme l’enregistrement des données d’entrée dans une base de données, mais nous n’allons pas simplifier le code ici.

Maintenant, essayez d’accéder au programme de l’extérieur du site cible tout en débogage et en cours d’exécution. Pour plus de simplicité, je vais poster un post à l’aide d’un outil appelé Code Visual Studio. Si vous pouvez envoyer POST, vous pouvez utiliser d’autres outils ou construire un autre programme de site pour l’attaque.

Lorsque vous installez une extension appelée REST Client dans Visual Studio Code, Vous pouvez utiliser une fonctionnalité qui vous permet de vérifier facilement le fonctionnement de l’API REST simplement en ouvrant le fichier .http.

Lorsque vous créez un fichier .http similaire à ce qui suit dans un fichier texte, puis ouvrez le fichier dans Visual Studio Code, Vous pouvez envoyer GET ou POST en cliquant sur la demande d’envoi.

Si vous créez les données POST suivantes, vous serez envoyé presque la même quantité de données que vous tapez du texte sur l’écran et appuyez sur le bouton soumettre. (Le numéro de port local devrait être le même que l’environnement d’exécution.)

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

Lorsque vous l’envoyez, vous pouvez voir que le serveur reçoit du texte et le traite.

Visual Studio Code peut obtenir les résultats. Si vous examinez de plus près le code de résultat, vous pouvez voir que l’ensemble de valeur de ViewData s’affiche. (Il est affiché dans Unicode, mais le texte est affiché correctement s’il est vu dans un navigateur Web.)

Adresse cross-site demande falsification vulnérabilité

Comme je l’ai mentionné au début, ASP.NET Core intègre des mesures contre la contrefaçon de demandes inter-sites dans le cadre. Une mesure commune consiste à émettre à l’avance un jeton unique au client sur un écran qui nécessite un poste, etc. Vous n’avez pas à accepter le traitement à moins que vous jetez le jeton au serveur.

Bien sûr, si vous accédez à l’URL directement à partir d’un site externe, le jeton est inconnu et n’acceptera pas le traitement.

Tout d’abord, je voudrais parler d’émettre des jetons au client (HTML), mais le fait est que le cadre n’est pas en mesure de le faire. Va partir. Si vous spécifiez une méthode POST dans l’étiquette de formulaire, vous pouvez incorporer des paramètres symboliques en HTML sans permission.

Dans le HTML ci-dessous, c’est le nom d’entrée "__RequestVerificationToken" type "caché". Ceci est envoyé au serveur ensemble lorsque le bouton d’envoi est appuyé. Soit dit en passant, il n’est pas annexé par la méthode GET.

Du côté du serveur, Startup.cs services. AjoutercontrollersAvec les options de méthode. Filtres à AutoValidateAntiforgeryTokenAttribute, toutes les actions Cette vérification symbolique est automatiquement ajoutée (pour être exactement seulement les méthodes HTTP de POST, PUT, PATCH, et DELETE).

Si vous souhaitez ajouter cette contrainte uniquement à des actions spécifiques, pas toutes les actions, par contrôleur, par action Il est également possible de définir.

Inversement, si vous voulez imposer des restrictions sur la plupart des actions, mais que vous voulez exclure des actions spécifiques, Si vous définissez l’attribut IgnoreAntiforgeryToken au contrôleur et à l’action, il est 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());
  });
}

Voyons comment ça marche. Tout d’abord, le processus de transmission se fait à partir de l’écran normalement.

Les résultats ont été reflétés sur l’écran comme prévu.

Il est également la sortie à la trace.

Essayons d’y accéder de l’extérieur.

Accès ed, mais Bad Request a été retourné. C’est un résultat différent de celui où vous ne prenez pas de mesures. Il est entendu qu’il est gardé parce qu’il n’est pas la sortie de la trace.

Résumé

Cette fois, j’ai essayé de mettre en œuvre des mesures contre la demande de cross-site forgeri. Il était très facile à mettre en œuvre parce qu’il était déjà intégré dans le cadre.

La construction d’un site Web exige beaucoup plus de vulnérabilité que le CSRF. Vous pouvez vérifier ce qui est là-bas, ou vous pouvez utiliser des outils comme OWASP pour vérifier les vulnérabilités dans votre site.

Découvrez comment fonctionne appsettings.json

Voir comment fonctionne asp-validation-résumé