이 코어에서 ASP.NET 요청 위조(XSRF/CSRF) 보호

페이지 업데이트 : 2021년 4월 1일 목요일

페이지 생성 날짜 : 2020년 5월 25일 월요일

환경

Visual Studio

Visual Studio 2019

ASP.NET Core

사이트는

크로스 사이트 요청 위조 (CSRF/XSRF)는 본래 대상 사이트 내에서 처리 하는 것에 대해 외부 사이트에서 업데이트를 실행 되는 취약점을 말합니다.

예를 들어, Web 사이트에 의견을 게시 하는 기능이 있었다. 보통 해당 사이트에서 댓글을 입력 하 고 게시 하는 것 이라고 생각 합니다만, 이 전송 프로세스는 대부분의 경우, 해당 URL에 대 한 데이터를 던져 서 처리 하도록 되어 있습니다.

따라서 대상 사이트에서이 URL에 대해 유사한 데이터를 전송 하면 코멘트를 게시 하는 것과 같은 처리 될 수 있습니다.

공격자만이 행위를 할 경우 그다지 위협이 되지 않지만, CSRF 무서운 곳은 공격자가 스푸핑된 사이트를 구축 하 고, 숨겨진 URL을 사이트를 포함 해 서 다른 사람이 실수로 액세스 하는 공격자가 되어 버리는 곳입니다.

여기서는 자세히 설명 하지 않습니다 때문에 자세한 것은 사이트에 대해 알아 보세요.

ASP.NET Core에서는이 방지 기능을 프레임 워크에 통합 되어 있습니다.

사이트의 작동 여부 확인

실제로는 외부 사이트 및 도구 등의 업데이트 프로세스가 실행 되는지 확인 합니다.

Index.cshtml는 입력 된 텍스트를 서버에 전달 하는 입력 폼을 만듭니다. 그리고 서버가 입력 텍스트에 맞게 작성 한 메시지를 표시 하도록 ViewData를 배치 합니다.

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>

서버에 있는 HomeController.cs에 전달 된 텍스트를 처리 하 여 Visual Studio의 추적 출력에 반환 합니다. 동일한 원본을 ViewData로 설정 하 여 클라이언트에 표시 되도록 합니다.

HomeController.cs

public class HomeController : Controller
{
  // 省略

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

  // 省略
}

만든 기능을 전형적으로 단계에 실행 해 봅니다. 디버깅 실행 화면이 나타나면 텍스트를 입력 하 고 전송 단추를 클릭 합니다.

예상 대로 가공 된 텍스트가 화면에 표시 됩니다.

추적에 출력 되기 때문에, Visual Studio의 출력 창에 텍스트가 표시 됩니다. 실제로 입력 데이터를 데이터베이스에 등록 하는 등의 작업을 수행 하지만, 여기에서는 코드를 단순화 하기 위하여 생략 하 고 있습니다.

프로그램을 디버그 실행 한 상태에서 해당 사이트 외부에서 액세스 합니다. 이번에는 구현을 간소화 하기 위해 Visual Studio Code 라는 도구를 사용 하 여 POST 발송 합니다. POST 보낼 수 있다면, 다른 도구를 사용 하 고 공격에 대 한 다른 사이트 프로그램을 작성 해도 문제가 없습니다.

Visual Studio Code에는 REST Client 라는 확장 기능을 설치 하면 .Http 파일을 열기만 하면 쉽게 REST API의 동작 확인을 할 수 있는 기능을 사용할 수 있습니다.

텍스트 파일에 다음과 같은 .http 파일을 만들고 파일을 Visual Studio Code에서 열어 Send Request 를 클릭 하 여 GET 및 POST를 보낼 수 있습니다.

다음 POST 데이터를 화면에 텍스트를 입력 하 고 보내기 단추를 눌렀을 때와 거의 같은 데이터가 전송 됩니다. (Localhost 포트 번호는 실행 환경에 맞게)

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

전송 해 보면 서버쪽 텍스트를 받아서 처리 하는 것을 알 수 있습니다.

Visual Studio Code 쪽은 결과를 얻을 수 있지만, 결과 코드를 잘 살펴보면 ViewData로 설정 된 값이 표시 되는 것도 알 수 있습니다. (Unicode로 표시 되어 있지만, Web 브라우저에서 제대로 표시 됩니다)

크로스 사이트 요청 위조 취약점에 대응

처음에도 말했듯이 ASP.NET Core에는 사이트에 대 한 백신이 프레임 워크에 통합 되어 있습니다. 일반적인 방법으로는 POST 등의 필요한 화면에서 사전에 클라이언트 고유의 토큰을 발급 하 고 해당 서버에 던지지 않으면 처리를 허용 하는 방법입니다.

물론 외부 사이트에서 URL에 액세스 하는 경우 토큰을 알 수 없는 프로세스를 허용 하지 않습니다.

먼저 클라이언트 (HTML)에 토큰을 발급 하는 방법에 대해입니다만, 사실이 작업은 프레임 워크는 자동으로 실행 하 고 있습니다. Form 태그에서 POST 메서드를 사용 하 여 두면 저절로 토큰 매개 변수를 HTML에 포함 합니다.

아래 HTML에는 input name = "__RequestVerificationToken" type = "hidden" 의 내용입니다. 전송 단추를 눌렀을 때 서버에 보내집니다. 덧붙여 GET 메서드에 추가 되지 않습니다.

서버 쪽에 대해서는 Startup.cs의 services. AddControllersWithViews 메서드의 options. Filters에 AutoValidateAntiforgeryTokenAttribute 를 설정 하는 것 만으로 모든 작업 (정확히는 POST, PUT, DELETE, PATCH의 HTTP 메서드) 토큰 검사를 자동으로 추가 됩니다.

만약 모든 작업은 특정 작업에만이 제약 조건을 추가 하려는 경우 컨트롤러 당, 액션 당 설정할 수도 있습니다.

반대로 대부분의 행동에 제약을 끼워 넣고 특정 작업에 대 한 제외 하려는 경우 IgnoreAntiforgeryToken 특성을 컨트롤러 작업으로 설정 하면 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());
  });
}

작동을 확인 하자. 우선은 일반적으로 화면에서 전송 작업을 수행 합니다.

예상 대로 화면에 결과가 반영 되었습니다.

추적에 출력 되 고 있습니다.

외부에서 액세스 합니다.

접근은 하 고 있지만 Bad Request가 발생 했습니다. 대책 없는 때와는 다른 결과가 발생할 수 있습니다. 추적에 출력 되지 않기 때문에 보호 된 것을 알 수 있습니다.

요약

이번에는 사이트에 대 한 대책을 실시 하 여 보았습니다. 프레임 워크에 이미 포함 되어 있으므로 구현 하는 매우 쉬 웠 다.

Web 사이트 구축에는 CSRF 이외에도 아주 많은 취약점 조치 해야 하기 때문에 어떤 것이 있는지 살펴보고 OWASP와 같은 도구를 사용 하 여 내 사이트의 취약성을 확인할 수도 있습니다.

appsettings.json의 작동 방식 확인

아스프 유효성 검사 요약의 작동 방식 보기