종속성 주입을 통해 AntiForgeryToken 생성
https://stackoverflow.com/questions/1702324
-
19-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
저는 회사 웹사이트의 보안을 개선하는 작업을 하고 있으며 쉽게 유지 관리할 수 있는 위조 시도를 방지하기 위한 토큰을 만들고 싶어서 생각해냈습니다.
public class AntiForgeryToken
{
private readonly string _referenceToken;
public AntiForgeryToken()
{
_referenceToken = Guid.NewGuid().ToString();
}
public string ReferenceToken
{
get { return _referenceToken; }
}
}
내 MasterPage의 기본 클래스에는 다음과 같은 속성으로 래핑된 HiddenField가 있습니다. ReferenceToken
protected virtual void Page_Load(object sender, EventArgs e)
{
if (!Page.IsPostBack)
{
InjectToken();
}
ValidateToken();
}
private void InjectToken()
{
var token = ObjectFactory.GetInstance<AntiForgeryToken>();
ReferenceToken = token.ReferenceToken;
}
private void ValidateToken()
{
var token = ObjectFactory.GetInstance<AntiForgeryToken>();
if (ReferenceToken.Equals(token.ReferenceToken, SC.InvariantCultureIgnoreCase))
return;
...do stuff for failed token
}
세션 내부에 토큰을 저장하는 StructureMap 핸들이 있으므로 사용자 세션별로 지속됩니다. 이 모든 것이 AntiForgery 구성표의 유효한 구현입니까?
편집하다: 내 질문에 약간의 혼란이 있는 것 같습니다. 예, ASP.NET MVC에 AntiForgeryToken 체계가 내장되어 있다는 것을 알고 있습니다. 이 질문은 명시적으로 이를 다시 만드는 방법에 대한 것입니다. 웹양식 CSRF 공격(Cross Site Request Forgery)의 사용을 방지합니다.나는 이것이 사용자 권리에 대한 적절한 승인의 필요성을 결코 제거하지 않는다는 것을 이해합니다.
@Neal과 @solairaja가 게시한 바로 그 링크를 불러오려고 했습니다. ASP.NET MVC의 AntiForgeryToken() 도우미를 사용하여 CSRF(교차 사이트 요청 위조) 방지.이 기사에서는 CSRF 공격이 무엇인지, 그리고 MVC가 이를 어떻게 중지하는지에 대해 자세히 설명합니다. 그러나 해당 솔루션은 웹 양식에 적용할 수 없기 때문에 자체적으로 구현하려고 했습니다.
@Neal의 응답을 본 후에는 GUID 생성을 대체할 MVC 도구에서 실제 소스 코드를 얻을 수 있다는 사실을 몰랐기 때문에 그것이 가장 받아들여질 수 있는 대답일 것이라고 생각합니다.하지만 다른 사람이 추가할 귀중한 정보가 있을 경우를 대비해 질문을 열어 두겠습니다.
해결책
크리스,
귀하의 접근 방식은 RNGCryptoserviceProvider에서 생성 된 Base64 인코딩 바이트 어레이를 사용하고 토큰을 페이지 (숨겨진 양식 필드)와 쿠키에 저장하는 것을 제외하고는 MVC의 방지 접근 방식을 다소 모방합니다. 더 많은 논리를 토큰 구현으로 옮기는 것이 좋습니다 (예 : 토큰 내부의 대부분의 검증 논리를 캡슐화).
MVC 구현 코드는 무료로 액세스 할 수 있습니다. http://aspnet.codeplex.com/sourcecontrol/changeset/view/23011?projectname=aspnet#391757 가능하다면 아마도 그것을 검토해야 할 것입니다. http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/ 분석 + 아이디어.
다른 팁
ASP.NET 웹 양식은 View State를 사용하는 경우 기본적으로 CSRF 공격을 기본적으로 사용하지 않습니다. 응용 프로그램에서 뷰 상태를 효과적으로 비활성화하지 않는 한, 당신은 가지고 있지 않은 문제를 해결하기 위해 코드를 추가하는 것입니다.
상태보기는 CSRF 공격을 방지합니다
.NET CSRF 가드 -OWASP
첫째, 나는 내가 묻어 야한다고 생각합니다 ... 당신은 "antiforgery"가 실제로 무엇을 의미합니까? 위조되는 것에 대해 무엇을 걱정하고 있습니까? 다음의 나머지 부분은 단지 마음에 떠오르는 일반적인 정보입니다 ...
내가 바꿀 한 가지는 Guid.NewGuid를 사용하지 않는 것입니다. 그것이 무작위인지 아닌지에 대한 논쟁이 있습니다. 따라서 보안 목적에 적합하지 않습니다. 즉, 나는 그것이 빠져 나가는 것이 매우 어려운 공격 일 것이라고 생각합니다.
임의의 토큰을 생성하는 데 더 나은 것이 필요한 GetBytes 방법에 대해서는 rngcryptoserviceprovider를 참조하십시오. 더 나은 무작위성 외에도 이것의 또 다른 장점은 원하는 크기를 만들 수 있다는 것입니다.
그래도 SSL 보다이 작업을 수행하고 있습니까? 우선, SSL은 중간 공격에서 사람에게 방어 번호 1입니다. 그것은 모든 필요에 대해 충분히 안전하지 않을 수도 있고 (그리고 다른 사람들이 그것에 대해 토론 할 수 있음), 그러한 것들에 대해 걱정한다면 다른 것이 없다면 출발점입니다. 그렇지 않다면, 먼저 응답하는 중간에 사람이 아닌 올바른 기계로부터 응답을 받고 있는지 어떻게 보장합니까? SSL이나 동등한 사람이 없다면, 토큰은 다른 어떤 것과 마찬가지로 쉽게 도난 당할 수 있습니다.
추가를 고려해야 할 또 다른 한 가지는 토큰이 한 번의 여행에만 좋고 다음 여행에서 고객에게 새로운 것을 생성하는 것입니다. 재사용을 시도하는 것은 실패합니다.
나는 할 것이다 ~ 아니다 그것이 당신이 생각하는 것이라면 SSL을 자신의 다른 것으로 바꾸십시오. 그래도 리플레이에 대해 걱정한다면, 한 번의 토큰 생성은 그것을 막는 한 가지 방법입니다. 동일한 양식 데이터를 두 번 제출하는 사용자가 걱정된다면 이것이해야 할 일입니다. 또한 걱정이된다면 전반적인 응용 프로그램 디자인을 고려할 것입니다. 클라이언트가 쇼핑 카트에서 품목 가격과 같은 민감한 정보를 보내도록 신뢰하지 않는 것과 같은 비즈니스 로직의 사운드 디자인으로 많은 재생 및 유사한 시나리오를 패배 할 수 있습니다.
ASP.NET 및 IIS 보안의 다양한 Microsoft Guidance (예 : Google ASP.NET 또는 IIS 보안 사이트 : Microsoft.com)를 시작점으로 확인하십시오. 많은 똑똑한 사람들이 우리를 위해 이미 많은 문제를 해결했습니다.
이 모든 것이 antiforgery 체계의 유효한 구현일까요?
내가 알 수있는 한, 페이지에 안내서를 삽입 한 다음 페이지가 돌아올 때 동일한 안내서를 찾는 것처럼 보입니다.
귀하의 요구 사항이 무엇인지 모르기 때문에 제도가 실제로 "유효한"경우 말할 수 없습니다. 그러나 몇 가지 사항을 지적 할 수 있습니다.
- Guid가 페이지에만 존재한다면 사용자가 한 컴퓨터의 페이지를 읽고 다른 시스템에서 양식을 제출하지 못하게하는 것은 무엇입니까? 아직 그렇지 않은 경우 쿠키 또는 세션 (쿠키를 사용하는 세션)과 연관시키는 것이 좋습니다.
- 안내서가 정적 숨겨진 정적으로 페이지에 기록 된 경우
<input>필드, 양식은 봇이 읽고 제출할 수 있습니다. 제출하기 전에 토큰을 처리하기 위해 페이지의 스크립트를 요구하여이를 해결할 수 있습니다. - ViewState를 사용하고 있습니까? 그렇다면 설정 만 고려할 수 있습니다
ViewStateUserKey클라이언트 당 고유 한 반복 가능한 가치로; 여기에 설명한 것과 비슷한 기능을 수행합니다.
Nick이 말했듯이, 나에게 당신이 주신 코드도 페이지에 안내서를 삽입 한 다음 페이지가 돌아올 때 동일한 안내서를 찾는 것처럼 보입니다. 구조 맵을 사용하여 세션에 저장할 때도 좋습니다.
그러나이 antiforgery 개념에는 몇 가지 내장 방법이 있습니다.
아래 링크를 먼저 참조하고 이해하십시오
지금,
다가오는 세부 사항 설명 및 방법론에 대해서는 아래 링크를 확인하십시오.
http://msdn.microsoft.com/en-us/library/system.web.mvc.htmlhelper_methods.aspx
고맙습니다 !!
그것은 모든 요청에 대해 카나리아를 생성하는 것처럼 보입니다.이제 사용자가 여러 탭을 열면 어떻게 될까요?:)
귀하의 접근 방식(및 ASP.NET MVC 구현)의 문제점은 이를 구현하는 것이 개발자에게 의존한다는 것입니다.이와 같은 보안은 옵트인(opt-in)이 아니라 옵트아웃(opt-out)되어야 합니다.내가 글을 썼을 때 AntiCSRF 모듈 대신 ASP.NET 페이지 수명 주기를 사용하게 되었는데, 이는 개발자가 CSRF 검사에서 페이지를 선택 해제하기를 원하지 않는 한 기본 코드를 변경하지 않음을 의미합니다.해당 사용자의 브라우저 세션이 지속되는 동안 지속되는 단일 토큰을 사용한다는 점에 유의하세요. 요청이 있을 때마다 실제로 토큰을 변경할 필요는 없습니다.
이제 나는 주로 다음 책에 대한 몇 가지 개념을 설명하기 위한 방법으로 모듈을 작성했습니다(여기에 광고 삽입). 이를 드러내고 웃다) 물론 다음을 사용할 수도 있습니다. ViewStateUserKey, 하지만 이는 선택 해제가 아닌 선택입니다.
보안의 첫 번째 규칙 : 자신의 보안을 굴리려고하지 마십시오
내가 당신의 설명을 이해할 때, 그것은 유효한 반대 방지 체계가 아닙니다. 모든 공격자는 우회해야합니다. 소스보기 토큰을 찾는 브라우저의 기능. 그런 다음 그 토큰을 게시하는 것을 기억하는 한 원하는 것을 게시 할 수 있으며 코드는 차이를 알지 못할 것입니다.
당신의 설명을 완전히 오해한다면 사과드립니다 ...
인증 된 사용자가 실제로 요청 된 수정을 수행하는 데 필요한 권한이 있음을 확인합니다.
예를 들어 웹 페이지 A "사용자 페이지 생성"이므로 인증 된 사용자가 새 사용자를 만들 수있는 권한이 있는지 확인합니다. 페이지는 "사용자 X 페이지 편집"이므로 인증 된 사용자가 사용자 X를 수정할 권한이 있는지 확인합니다. 아마도 자신이 사용자 X 또는 관리 사용자이기 때문일 수 있습니다.
즉, Guids를 사용하는 것은 그다지 안전하지 않습니다. 안내는 무작위성이 아니라 고유성을 위해 작성된 알고리즘을 기반으로 생성됩니다. Afaik 이름 기반, 시간 기반 및 무작위의 세 가지 유효한 알고리즘이 있습니다. 시스템에서 사용하는 안내 알고리즘 (미래 .NET 버전으로 변경 될 수 있음)이 시간 기반이라면 유효한 안내서를 추측하는 것은 그리 어렵지 않습니다.
