CSRF를 시뮬레이트하기 위해 악성 코드에 쿠키 또는 세션 정보를 포함시키지 않습니다. CSRF의 핵심은 실행되는 코드가 세션이나 쿠키 정보를 알지 못한다는 것입니다. 브라우저가 애플리케이션 요청에 브라우저를 포함한다고 가정합니다.
테스트하려면 POST 메서드와 txtFrom, txtTo 및 txtAmount 매개 변수를 btnSubmit 단추로 받아들이는 Transfer.aspx 페이지가 있고 계정 1에서 계정 2로 전송하려고한다고 가정합니다. 당신은 viewstate가 및 eventvalidation 값이 어떻게 될지 미리 알해야 할 것
<form action="http://www.mysite.com/Transfer.aspx" method="post">
<input type="hidden" name="txtFrom" value="1" />
<input type="hidden" name="txtTo" value="2" />
<input type="hidden" name="txtAmount" value="500" />
<input type="hidden" name="__VIEWSTATE" value="[PUT VIEWSTATE VALUE HERE]" />
<input type="hidden" name="__EVENTVALIDATION" value="[PUT EVENTVALIDATION VALUE HERE]" />
<input type="submit" name="btnSubmit" value="Go" />
</form>
, 그래서 당신이 제대로 로그인 할 때 당신은 당신의 페이지에서 것을 복사해야 것 : 뭔가처럼 악성 코드가 될 수있다 . 사용자 또는 세션에 관계없이 viewstate가 일정하다고 가정합니다.
이제 악성 페이지가 있습니다. 한 탭에 로그인 한 상태에서 다른 탭에서 열어서 제출하면, 취약한 경우 전송이 이루어집니다. 그 이유는 mysite.com에 속한 쿠키가 전송되기 때문입니다. 즉, 다른 탭에서 활성 상태 인 세션이 사용됩니다.
이 문제를 해결하려면 고유 한 세션 당 가치가 게시물에 포함되어야합니다. 이는 ViewStateUserKey를 사용하여 ASP.NET 세션 ID 또는 해시로 설정하면 가장 쉽게 수행 할 수 있습니다. 이렇게하면 __VIEWSTATE 값이 모든 세션과 고유하게됩니다. 즉, 아무도 __VIEWSTATE 값을 예측할 수 없으므로 더 이상 취약하지 않습니다.
이것은 CSRF 및 일반적으로 OWSASP에 관한 훌륭한 글입니다. http://www.troyhunt.com/2010/11/owasp-top-10-for-net-developers-part-5.html – Nickz