是的。转账的确是需要身份验证，现在的问题是你登录了银行系统，已经完成了身份验证，并且在浏览器新的Tab中打开了黑客的链接，我们来看下到底发生了什么：
这里有三个HTTP请求，第一个就是[逗你玩]页面，第二个是里面的IFrame页面，第三个是IFrame加载完毕后发起的POST请求，也就是具体的转账页面。因为IFrame是隐藏的，所以用户并不知道发生了什么。
我们来具体看下第三个请求：
明显这次转账是成功的，并且Cookie中带上了用户身份验证信息，所有后台根本不知道这次请求是来自黑客的页面，转账成功的返回内容：
如何阻止CSRF攻击
从上面的实例我们可以看出，CSRF源于表单身份验证的实现机制。
由于HTTP本身是无状态的，也就是说每一次请求对于Web服务器来说都是全新的，服务器不知道之前请求的任何状态，而身份验证需要我们在第二次访问时知道是否登录的状态（不可能每次请求都验证账号密码），这本身就是一种矛盾！
解决这个矛盾的办法就是Cookie，Cookie可以在浏览器中保存少量信息，所以Forms Authentication就用Cookie来保存加密过的身份信息。而Cookie中保存的全部值在每次HTTP请求中（不管是GET还是POST，也不管是静态资源还是动态资源）都会被发送到服务器，这也就给CSRF以可乘之机。
所以，CSRF的根源在于服务器可以从Cookie中获知身份验证信息，而无法得知本次HTTP请求是否真的是用户发起的。
Referer验证
Referer是HTTP请求头信息中的一部分，每当浏览器向服务器发送请求时，都会附带上Referer信息，表明当前发起请求的页面地址。
一个正常的转账请求，我们可以看到Referer和浏览器地址栏是一致的：
我们再来看下刚才的黑客页面：
可以看到Referer的内容和当前发起请求的页面地址一样，注意对比：
1.浏览器网址：click_me_please.html
2.HTTP请求地址：Home/TransferMoney
3.Referer：click_me_please_iframe.html，注意这个是发起请求的页面，而不一定就是浏览器地址栏显示的网址。
基于这个原理，我们可以简单的对转账的POST请求进行Referer验证：
[HttpPost] [Authorize] public ActionResult TransferMoney(string ToAccount, int Money) { if(Request.Url.Host != Request.UrlReferrer.Host) { throw new Exception("Referrer validate fail!"); } // 这里放置转账业务代码 ViewBag.ToAccount = ToAccount; ViewBag.Money = Money; return View(); }
此时访问，恶意转账失败：
MVC默认支持的CSRF验证
MVC默认提供的CSRF验证方式更加彻底，它通过验证当前请求是否真的来自用户的操作。
在视图页面，表单内部增加对Html.AntiForgeryToken函数的调用：
@if (ViewBag.ToAccount == null) { using (Html.BeginForm()) { @Html.AntiForgeryToken() <input type="text" /> <input type="text" /> <input type="submit" value="转账" /> } } else { @:您已经向账号 [@ViewBag.ToAccount] 转入 [@ViewBag.Money] 元！ }
这会在表单标签里面和Cookie中分别生成一个名为__RequestVerificationToken 的Token：
然后添加[ValidateAntiForgeryToken]注解到控制器方法中：
[HttpPost] [Authorize] [ValidateAntiForgeryToken] public ActionResult TransferMoney(string ToAccount, int Money) { // 这里放置转账业务代码 ViewBag.ToAccount = ToAccount; ViewBag.Money = Money; return View(); }
在服务器端，会验证这两个Token是否一致（不是相等），如果不一致就会报错。
下面手工修改表单中这个隐藏字段的值，来看下错误提示：
类似的道理，运行黑客页面，恶意转账失败：
