ASP.NET MVC 및 웹 페이지에서 XSRF/CSRF 방지

아티클
07/13/2023

사이트 간 요청 위조(XSRF 또는 CSRF라고도 함)는 악의적인 웹 사이트가 클라이언트 브라우저와 해당 브라우저에서 신뢰할 수 있는 웹 사이트 간의 상호 작용에 영향을 줄 수 있는 웹 호스팅 애플리케이션에 대한 공격입니다. 이러한 공격은 웹 브라우저가 웹 사이트에 대한 모든 요청과 함께 인증 토큰을 자동으로 보내기 때문에 가능합니다. 정식 예로는 ASP.NET의 폼 인증 티켓과 같은 인증 쿠키가 있습니다. 그러나 영구 인증 메커니즘(예: Windows 인증, 기본 등)을 사용하는 웹 사이트는 이러한 공격의 대상이 될 수 있습니다.

XSRF 공격은 피싱 공격과는 구분됩니다. 피싱 공격에는 피해자의 상호 작용이 필요합니다. 피싱 공격에서 악의적인 웹 사이트는 대상 웹 사이트를 모방하고 피해자는 공격자에게 중요한 정보를 제공하는 데 속습니다. XSRF 공격에서는 종종 피해자의 상호 작용이 필요하지 않습니다. 대신 공격자는 브라우저에 의존하여 모든 관련 쿠키를 대상 웹 사이트로 자동으로 보냅니다.

자세한 내용은 OWASP( Open Web Application Security Project) XSRF를 참조하세요.

공격 분석

XSRF 공격을 진행하려면 일부 온라인 뱅킹 거래를 수행하려는 사용자를 고려합니다. 이 사용자는 먼저 WoodgroveBank.com 방문하여 로그인합니다. 이때 응답 헤더에 인증 쿠키가 포함됩니다.

HTTP/1.1 200 OK
Date: Mon, 18 Jun 2012 21:22:33 GMT
X-AspNet-Version: 4.0.30319
Set-Cookie: .ASPXAUTH={authentication-token}; path=/; secure; HttpOnly;
{ Cache-Control, Content-Type, Location, Server and other keys/values not listed. }

인증 쿠키는 세션 쿠키이므로 브라우저 프로세스가 종료될 때 브라우저에서 자동으로 지워집니다. 그러나 그 때까지 브라우저는 WoodgroveBank.com 각 요청과 함께 쿠키를 자동으로 포함합니다. 이제 사용자는 $1000를 다른 계정으로 이체하려고 하므로 은행 사이트에서 양식을 작성하고 브라우저에서 이 요청을 서버에 만듭니다.

POST /DoTransfer HTTP/1.1
Host: WoodgroveBank.com
Content-Type: application/x-www-form-urlencoded
Cookie: .ASPXAUTH={authentication-token}
toAcct=12345&amount=1,000.00

이 작업에는 부작용이 있으므로(통화 거래를 시작함) 은행 사이트에서 이 작업을 시작하기 위해 HTTP POST를 요구하도록 선택했습니다. 서버는 요청에서 인증 토큰을 읽고, 현재 사용자의 계정 번호를 조회하고, 충분한 자금이 있는지 확인한 다음, 대상 계정으로 트랜잭션을 시작합니다.

그녀의 온라인 뱅킹이 완료되면 사용자는 은행 사이트에서 벗어나 웹의 다른 위치를 방문합니다. 이러한 사이트 중 하나인 fabrikam.com iframe 내에 포함된 페이지에 다음 태그가 <포함됩니다>.

<form id="theForm" action="https://WoodgroveBank.com/DoTransfer" method="post">
    <input type="hidden" name="toAcct" value="67890" />
    <input type="hidden" name="amount" value="250.00" />
</form>
<script type="text/javascript">
    document.getElementById('theForm').submit();
</script>

그러면 브라우저에서 이 요청을 수행합니다.

POST /DoTransfer HTTP/1.1
Host: WoodgroveBank.com
Content-Type: application/x-www-form-urlencoded
Cookie: .ASPXAUTH={authentication-token}
toAcct=67890&amount=250.00

공격자는 사용자에게 여전히 대상 웹 사이트에 대한 유효한 인증 토큰이 있을 수 있다는 사실을 악용하고 있으며, 브라우저가 대상 사이트에 HTTP POST를 자동으로 만들도록 Javascript의 작은 조각을 사용하고 있습니다. 인증 토큰이 여전히 유효한 경우 은행 사이트는 공격자가 선택한 계정으로 $250의 전송을 시작합니다.

비효율적인 완화

위의 시나리오에서 WoodgroveBank.com SSL을 통해 액세스되고 SSL 전용 인증 쿠키가 있다는 사실은 공격을 저지하기에 충분하지 않다는 점에 유의해야 합니다. 공격자는 양식> 요소에서 URI 스키마(https)를 <지정할 수 있으며, 해당 쿠키가 의도한 대상의 URI 체계와 일치하는 한 브라우저는 노출되지 않은 쿠키를 대상 사이트로 계속 보냅니다.

신뢰할 수 있는 사이트만 방문하면 온라인에서 안전하게 유지하는 데 도움이 되기 때문에 사용자가 신뢰할 수 없는 사이트를 방문해서는 안 된다고 주장할 수 있습니다. 이것에는 몇 가지 진실이 있지만 불행히도이 조언이 항상 실용적이지는 않습니다. 아마도 사용자는 ConsolidatedMessenger.com 로컬 뉴스 사이트를 "신뢰"하고 대신 해당 사이트를 방문하지만 해당 사이트에는 공격자가 fabrikam.com 실행 중인 동일한 코드 조각을 삽입할 수 있는 XSS 취약성이 있습니다.

들어오는 요청에 도메인을 참조하는 참조자 헤더 가 있는지 확인할 수 있습니다. 이렇게 하면 타사 도메인에서 무의식적으로 제출된 요청이 중지됩니다. 그러나 개인 정보 보호를 위해 브라우저의 참조자 헤더를 사용하지 않도록 설정하는 사람도 있으며, 공격자가 특정 안전하지 않은 소프트웨어가 설치된 경우 공격자가 해당 헤더를 스푸핑할 수 있습니다. 참조자 헤더를 확인하는 것은 XSRF 공격을 방지하는 안전한 접근 방법으로 간주되지 않습니다.

웹 스택 런타임 XSRF 완화

ASP.NET Web Stack 런타임은 동기화기 토큰 패턴 의 변형을 사용하여 XSRF 공격을 방어합니다. 동기화기 토큰 패턴의 일반적인 형태는 두 개의 XSRF 방지 토큰이 각 HTTP POST(인증 토큰 외에도)를 사용하여 서버에 제출된다는 것입니다. 한 토큰은 쿠키로, 다른 하나는 양식 값으로 제출됩니다. ASP.NET 런타임에서 생성된 토큰 값은 공격자가 결정적이거나 예측할 수 없습니다. 토큰이 제출되면 두 토큰이 비교 검사 전달하는 경우에만 서버에서 요청을 진행할 수 있습니다.

XSRF 요청 확인 세션 토큰 은 HTTP 쿠키로 저장되며 현재 페이로드에 다음 정보를 포함합니다.

임의의 128비트 식별자로 구성된 보안 토큰입니다.
다음 이미지는 인터넷 Explorer F12 개발자 도구와 함께 표시되는 XSRF 요청 확인 세션 토큰을 보여 줍니다. (현재 구현이며 변경될 가능성이 있는 대상입니다.)

내 ASP 점 NET M V C 애플리케이션 인덱스 페이지를 보여 주는 스크린샷. 네트워크 탭이 열려 있습니다.

필드 토큰은 로 <input type="hidden" /> 저장되며 페이로드에 다음 정보를 포함합니다.

로그인한 사용자의 사용자 이름(인증된 경우)입니다.
IAntiForgeryAdditionalDataProvider에서 제공하는 모든 추가 데이터입니다.

XSRF 방지 토큰의 페이로드는 암호화되고 서명되므로 도구를 사용하여 토큰을 검사할 때 사용자 이름을 볼 수 없습니다. 웹 애플리케이션이 ASP.NET 4.0을 대상으로 하는 경우 MachineKey.Encode 루틴에서 암호화 서비스를 제공합니다. 웹 애플리케이션이 ASP.NET 4.5 이상을 대상으로 하는 경우 더 나은 성능, 확장성 및 보안을 제공하는 MachineKey.Protect 루틴에서 암호화 서비스를 제공합니다. 자세한 내용은 다음 블로그 게시물을 참조하세요.

토큰 생성

XSRF 방지 토큰을 생성하려면 MVC 보기 또는 @AntiForgery.GetHtml() Razor 페이지에서 @Html.AntiForgeryToken 메서드를 호출합니다. 그러면 런타임에서 다음 단계를 수행합니다.

현재 HTTP 요청에 XSRF 방지 세션 토큰(안티 XSRF 쿠키 __RequestVerificationToken)이 이미 포함되어 있으면 보안 토큰이 추출됩니다. HTTP 요청에 XSRF 방지 세션 토큰이 포함되어 있지 않거나 보안 토큰 추출에 실패하면 새 임의 XSRF 방지 토큰이 생성됩니다.
XSRF 방지 필드 토큰은 위의 단계(1)의 보안 토큰과 현재 로그인한 사용자의 ID를 사용하여 생성됩니다. (사용자 ID를 결정하는 방법에 대한 자세한 내용은 아래 의 특수 지원이 있는 시나리오 섹션을 참조하세요.) 또한 IAntiForgeryAdditionalDataProvider 가 구성된 경우 런타임은 GetAdditionalData 메서드를 호출하고 반환된 문자열을 필드 토큰에 포함합니다. 자세한 내용은 구성 및 확장성 섹션을 참조하세요.
1단계에서 새 XSRF 방지 토큰이 생성된 경우 이를 포함하도록 새 세션 토큰이 만들어지고 아웃바운드 HTTP 쿠키 컬렉션에 추가됩니다. 단계(2)의 필드 토큰은 요소에 <input type="hidden" /> 래핑되고 이 HTML 태그는 또는 AntiForgery.GetHtml()의 Html.AntiForgeryToken() 반환 값이 됩니다.

토큰 유효성 검사

들어오는 XSRF 방지 토큰의 유효성을 검사하기 위해 개발자는 MVC 작업 또는 컨트롤러에 ValidateAntiForgeryToken 특성을 포함하거나 Razor 페이지에서 호출 @AntiForgery.Validate() 합니다. 런타임은 다음 단계를 수행합니다.

들어오는 세션 토큰 및 필드 토큰은 읽고 각 토큰에서 추출된 XSRF 방지 토큰입니다. XSRF 방지 토큰은 생성 루틴의 2단계당 동일해야 합니다.
현재 사용자가 인증되면 사용자 이름이 필드 토큰에 저장된 사용자 이름과 비교됩니다. 사용자 이름이 일치해야 합니다.
IAntiForgeryAdditionalDataProvider가 구성된 경우 런타임은 ValidateAdditionalData 메서드를 호출합니다. 메서드는 부울 값 true를 반환해야 합니다.

유효성 검사가 성공하면 요청을 계속 진행할 수 있습니다. 유효성 검사에 실패하면 프레임워크는 HttpAntiForgeryException을 throw합니다.

오류 조건

ASP.NET Web Stack Runtime v2부터 유효성 검사 중에 throw되는 모든 HttpAntiForgeryException 에는 무엇이 잘못되었는지에 대한 자세한 정보가 포함됩니다. 현재 정의된 오류 조건은 다음과 같습니다.

세션 토큰 또는 양식 토큰이 요청에 없습니다.
세션 토큰 또는 양식 토큰은 읽을 수 없습니다. 가장 가능성이 높은 원인은 일치하지 않는 버전의 The ASP.NET Web Stack Runtime을 실행하는 팜 또는 Web.config machineKey> 요소가 컴퓨터 간에 다른 팜<입니다. Fiddler와 같은 도구를 사용하여 XSRF 방지 토큰을 변조하여 이 예외를 강제로 적용할 수 있습니다.
세션 토큰 및 필드 토큰이 교환되었습니다.
세션 토큰 및 필드 토큰에는 일치하지 않는 보안 토큰이 포함됩니다.
필드 토큰 내에 포함된 사용자 이름이 현재 로그인한 사용자의 사용자 이름과 일치하지 않습니다.
IAntiForgeryAdditionalDataProvider.ValidateAdditionalData 메서드는 false를 반환했습니다.

XSRF 방지 기능은 토큰 생성 또는 유효성 검사 중에 추가 검사를 수행할 수도 있으며, 이러한 검사 중에 실패하면 예외가 throw될 수 있습니다. 자세한 내용은 WIF/ACS/클레임 기반 인증및 구성 및 확장성 섹션을 참조하세요.

특별한 지원이 있는 시나리오

익명 인증

XSRF 방지 시스템에는 익명 사용자에 대한 특별 지원이 포함되어 있습니다. 여기서 "anonymous"는 IIdentity.IsAuthenticated 속성이 false를 반환하는 사용자로 정의됩니다. 시나리오에는 로그인 페이지(사용자가 인증되기 전에)에 XSRF 보호를 제공하고 애플리케이션이 IIdentity 이외의 메커니즘을 사용하여 사용자를 식별하는 사용자 지정 인증 체계를 제공하는 것이 포함됩니다.

이러한 시나리오를 지원하려면 세션 및 필드 토큰이 128비트 임의로 생성된 불투명 식별자인 보안 토큰에 의해 조인된다는 점을 기억하세요. 이 보안 토큰은 사이트를 탐색할 때 개별 사용자의 세션을 추적하는 데 사용되므로 익명 식별자의 목적을 효과적으로 제공합니다. 빈 문자열은 위에서 설명한 생성 및 유효성 검사 루틴의 사용자 이름 대신 사용됩니다.

WIF/ACS/클레임 기반 인증

일반적으로 .NET Framework 기본 제공되는 IIdentity 클래스에는 IIdentity.Name 특정 애플리케이션 내에서 특정 사용자를 고유하게 식별하기에 충분한 속성이 있습니다. 예를 들어 FormsIdentity.Name 멤버 자격 데이터베이스에 저장된 사용자 이름(해당 데이터베이스에 따라 모든 애플리케이션에 대해 고유함)을 반환하고 , WindowsIdentity.Name 사용자의 도메인 정규화된 ID 등을 반환합니다. 이러한 시스템은 인증뿐만 아니라 애플리케이션에 대한 사용자도 식별 합니다.

반면에 클레임 기반 인증은 반드시 특정 사용자를 식별할 필요가 없습니다. 대신 ClaimsPrincipal 및 ClaimsIdentity 형식은 클레임 인스턴스 집합과 연결됩니다. 여기서 개별 클레임은 다른 모든 항목에 대해 "18세 이상" 또는 "관리자"일 수 있습니다. 사용자가 반드시 식별되지는 않았으므로 런타임은 ClaimsIdentity.Name 속성을 이 특정 사용자의 고유 식별자로 사용할 수 없습니다. 팀은 ClaimsIdentity.Namenull을 반환하거나, 친숙한(표시) 이름을 반환하거나, 그렇지 않으면 사용자의 고유 식별자로 사용하기에 적합하지 않은 문자열을 반환하는 실제 예제를 보았습니다.

클레임 기반 인증을 사용하는 많은 배포는 특히 AZURE ACS(Access Control Service)를 사용합니다. ACS를 사용하면 개발자가 개별 ID 공급자 (예: ADFS, Microsoft 계정 공급자, Yahoo!와 같은 OpenID 공급자 등)를 구성할 수 있으며 ID 공급자는 이름 식별자를 반환합니다. 이러한 이름 식별자는 이메일 주소와 같은 PII(개인 식별 정보)를 포함하거나 PPID(개인 식별자)처럼 익명화될 수 있습니다. 그럼에도 불구하고 튜플(ID 공급자, 이름 식별자)은 사이트를 탐색하는 동안 특정 사용자에게 적절한 추적 토큰으로 충분히 작동하므로 ASP.NET Web Stack Runtime은 XSRF 방지 필드 토큰을 생성하고 유효성을 검사할 때 사용자 이름 대신 튜플을 사용할 수 있습니다. ID 공급자 및 이름 식별자에 대한 특정 URI는 입니다.

https://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

자세한 내용은 이 ACS 문서 페이지를 참조하세요.

토큰을 생성하거나 유효성을 검사할 때 ASP.NET Web Stack Runtime은 런타임에 형식에 바인딩을 시도합니다.

Microsoft.IdentityModel.Claims.IClaimsIdentity, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 (WIF SDK의 경우)
System.Security.Claims.ClaimsIdentity (.NET 4.5의 경우).

이러한 형식이 있고 현재 사용자의 IIIIdentity 가 이러한 형식 중 하나를 구현하거나 서브클래싱하는 경우 XSRF 방지 기능은 토큰을 생성하고 유효성을 검사할 때 사용자 이름 대신 (ID 공급자, 이름 식별자) 튜플을 사용합니다. 이러한 튜플이 없으면 사용 중인 특정 클레임 기반 인증 메커니즘을 이해하도록 XSRF 방지 시스템을 구성하는 방법을 개발자에게 설명하는 오류와 함께 요청이 실패합니다. 자세한 내용은 구성 및 확장성 섹션을 참조하세요.

OAuth/OpenID 인증

마지막으로, XSRF 방지 기능은 OAuth 또는 OpenID 인증을 사용하는 애플리케이션을 특별히 지원합니다. 이 지원은 추론 기반입니다. 현재 IIdentity.Name http:// 또는 https:// 시작하는 경우 사용자 이름 비교는 기본 OrdinalIgnoreCase 비교자가 아닌 서수 비교자를 사용하여 수행됩니다.

구성 및 확장성

경우에 따라 개발자는 XSRF 방지 생성 및 유효성 검사 동작에 대한 보다 엄격한 제어를 원할 수 있습니다. 예를 들어 응답에 HTTP 쿠키를 자동으로 추가하는 MVC 및 웹 페이지 도우미의 기본 동작은 바람직하지 않으며 개발자는 토큰을 다른 곳에 유지할 수 있습니다. 이를 지원하는 두 가지 API가 있습니다.

AntiForgery.GetTokens(string oldCookieToken, out string newCookieToken, out string formToken);
AntiForgery.Validate(string cookieToken, string formToken);

GetTokens 메서드는 기존 XSRF 요청 확인 세션 토큰(null일 수 있음)을 입력으로 사용하고 새 XSRF 요청 확인 세션 토큰 및 필드 토큰을 출력으로 생성합니다. 토큰은 장식이 없는 불투명 문자열일 뿐입니다. formToken 값은 instance 입력> 태그에 <래핑되지 않습니다. newCookieToken 값은 null일 수 있습니다. 이 경우 oldCookieToken 값은 여전히 유효하며 새 응답 쿠키를 설정할 필요가 없습니다. GetTokens의 호출자는 필요한 응답 쿠키를 유지하거나 필요한 태그를 생성해야 합니다. GetTokens 메서드 자체는 응답을 부작용으로 변경하지 않습니다. Validate 메서드는 들어오는 세션 및 필드 토큰을 가져와 앞에서 언급한 유효성 검사 논리를 실행합니다.

AntiForgeryConfig

개발자는 Application_Start XSRF 방지 시스템을 구성할 수 있습니다. 구성은 프로그래밍 방식입니다. 정적 AntiForgeryConfig 형식의 속성은 아래에 설명되어 있습니다. 클레임을 사용하는 대부분의 사용자는 UniqueClaimTypeIdentifier 속성을 설정하려고 합니다.

속성	설명
AdditionalDataProvider	토큰 생성 중에 추가 데이터를 제공하고 토큰 유효성 검사 중에 추가 데이터를 사용하는 IAntiForgeryAdditionalDataProvider 입니다. 기본값은 null입니다. 자세한 내용은 IAntiForgeryAdditionalDataProvider 섹션을 참조하세요.
CookieName	XSRF 방지 세션 토큰을 저장하는 데 사용되는 HTTP 쿠키의 이름을 제공하는 문자열입니다. 이 값을 설정하지 않으면 애플리케이션의 배포된 가상 경로에 따라 이름이 자동으로 생성됩니다. 기본값은 null입니다.
RequireSsl	SSL 보안 채널을 통해 XSRF 방지 토큰을 제출해야 하는지 여부를 지정하는 부울입니다. 이 값이 true이면 자동으로 생성된 쿠키에는 "보안" 플래그가 설정되고 SSL을 통해 제출되지 않은 요청 내에서 호출된 경우 XSRF 방지 API가 throw됩니다. 기본 값은 false입니다.
SuppressIdentityHeuristicChecks	XSRF 방지 시스템이 클레임 기반 ID에 대한 지원을 비활성화해야 하는지 여부를 지정하는 부울입니다. 이 값이 true이면 시스템은 IIdentity.Name 고유한 사용자별 식별자로 사용하기에 적절하다고 가정하고 WIF/ACS/클레임 기반 인증 섹션에 설명된 대로 특수한 경우 IClaimsIdentity 또는 ClClaimsIdentity를 시도하지 않습니다. 기본값은 `false`입니다.
UniqueClaimTypeIdentifier	고유한 사용자별 식별자로 사용하기에 적합한 클레임 유형을 나타내는 문자열입니다. 이 값이 설정되고 현재 IIdentity 가 클레임 기반인 경우 시스템은 UniqueClaimTypeIdentifier에 지정된 형식의 클레임을 추출하려고 시도하고 필드 토큰을 생성할 때 해당 값이 사용자의 사용자 이름 대신 사용됩니다. 클레임 유형을 찾을 수 없으면 시스템에서 요청에 실패합니다. 기본값은 null이며, 이는 시스템에서 사용자의 사용자 이름 대신 이전에 설명한 대로 (ID 공급자, 이름 식별자) 튜플을 사용해야 임을 나타냅니다.

IAntiForgeryAdditionalDataProvider

IAntiForgeryAdditionalDataProvider 형식을 사용하면 개발자가 각 토큰에서 추가 데이터를 라운드트립하여 XSRF 방지 시스템의 동작을 확장할 수 있습니다. GetAdditionalData 메서드는 필드 토큰이 생성될 때마다 호출되며 반환 값은 생성된 토큰에 포함됩니다. 구현자는 타임스탬프, nonce 또는 이 메서드에서 원하는 다른 값을 반환할 수 있습니다.

마찬가지로 필드 토큰의 유효성을 검사할 때마다 ValidateAdditionalData 메서드가 호출되고 토큰 내에 포함된 "추가 데이터" 문자열이 메서드에 전달됩니다. 유효성 검사 루틴은 시간 제한을 구현할 수 있습니다(토큰을 만들 때 저장된 시간에 대해 현재 시간을 확인), nonce 검사 루틴 또는 기타 원하는 논리를 확인할 수 있습니다.

디자인 결정 및 보안 고려 사항

세션 및 필드 토큰을 연결하는 보안 토큰은 기술적으로 XSRF 공격으로부터 익명/인증되지 않은 사용자를 보호하려고 할 때만 필요합니다. 사용자가 인증되면 인증 토큰 자체(아마도 쿠키 형식으로 제출됨)를 동기화 장치 토큰 쌍의 절반으로 사용할 수 있습니다. 그러나 인증되지 않은 사용자가 적중한 로그인 페이지를 보호하기 위한 유효한 시나리오가 있으며, 인증된 사용자에 대해서도 항상 보안 토큰을 생성하고 유효성을 검사하여 XSRF 방지 논리를 더 간단하게 만들었습니다. 또한 세션 토큰을 설정하거나 추측하는 것이 공격자가 극복해야 할 또 다른 장애물이기 때문에 필드 토큰이 공격자에 의해 손상되는 경우 몇 가지 추가 보호를 제공합니다.

개발자는 여러 애플리케이션이 단일 도메인에서 호스트되는 경우 주의해야 합니다. 예를 들어 example1.cloudapp.net 및 example2.cloudapp.net 호스트가 다르더라도 *.cloudapp.net 도메인 아래의 모든 호스트 간에 암시적 트러스트 관계가 있습니다. 이 암시적 트러스트 관계를 사용하면 신뢰할 수 없는 호스트가 서로의 쿠키에 영향을 줄 수 있습니다 (AJAX 요청을 제어하는 동일한 원본 정책이 반드시 HTTP 쿠키에 적용되지는 않음). ASP.NET Web Stack Runtime은 사용자 이름이 필드 토큰에 포함되어 있다는 몇 가지 완화를 제공하므로 악의적인 하위 도메인이 세션 토큰을 덮어쓸 수 있더라도 사용자에게 유효한 필드 토큰을 생성할 수 없습니다. 그러나 이러한 환경에서 호스트되는 경우 기본 제공 XSRF 방지 루틴은 여전히 세션 하이재킹 또는 로그인 XSRF를 방어할 수 없습니다.

XSRF 방지 루틴은 현재 클릭재킹을 방어하지 않습니다. 클릭재킹을 방지하려는 애플리케이션은 각 응답과 함께 X-Frame-Options: SAMEORIGIN 헤더를 전송하여 쉽게 방어할 수 있습니다. 이 헤더는 모든 최근 브라우저에서 지원됩니다. 자세한 내용은 IE 블로그, SDL 블로그 및 OWASP를 참조하세요. ASP.NET 웹 스택 런타임은 향후 릴리스에서 MVC 및 웹 페이지 안티 XSRF 도우미가 이 헤더를 자동으로 설정하여 애플리케이션이 이 공격으로부터 자동으로 보호되도록 할 수 있습니다.

웹 개발자는 사이트가 XSS 공격에 취약하지 않은지 계속 확인해야 합니다. XSS 공격은 매우 강력하며, 성공적인 익스플로잇은 XSRF 공격에 대한 ASP.NET Web Stack 런타임 방어도 중단합니다.

승인

@LeviBroderick ASP.NET 보안 코드의 대부분을 이 정보의 대부분을 작성했습니다.

다음을 통해 공유