浅谈ASP.NET MVC 防止跨站请求伪造,CSRF攻击的实现方法
在HTTP POST请求中,我们多次在View和Controller中看下如下代码:
1.View中调用了Html.AntiForgeryToken()。
2.Controller中的方法添加了[ValidateAntiForgeryToken]注解。
这样看似一对的写法其实是为了避免引入跨站请求伪造(CSRF)攻击。
这种攻击形式大概在2001年才为人们所认知,2006年美国在线影片租赁网站Netflix爆出多个CSRF漏洞,2008年流行的视频网址YouTube受到CSRF攻击,同年墨西哥一家银行客户受到CSRF攻击,杀毒厂商McAfee也曾爆出CSRF攻击(引自wikipedia)。
之所以很多大型网址也遭遇CSRF攻击,是因为CSRF攻击本身的流程就比较长,很多开发人员可能在几年的时间都没遇到CSRF攻击,因此对CSRF的认知比较模糊,没有引起足够的重视。
CSRF攻击的模拟示例
我们这里将通过一个模拟的示例,讲解CSRF的攻击原理,然后再回过头来看下MVC提供的安全策略。
看似安全的银行转账页面
假设我们是银行的Web开发人员,现在需要编写一个转账页面,客户登录后在此输入对方的账号和转出的金额,即可实现转账:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
由于这个过程需要身份验证,所以我们为TransferMoney的两个操作方法都加上了注解[Authorize],以阻止匿名用户的访问。
如果直接访问http://localhost:55654/Home/TransferMoney,会跳转到登录页面:http://www.zuihaog.com/
登录后,来到转账页面,我们看下转账的视图代码:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
视图代码中有一个逻辑判断,根据ViewBag.ToAccount是否为空来显示不同内容:
1.ViewBag.ToAccount为空,则表明是页面访问。
2.ViewBag.ToAccount不为空,则为转账成功,需要显示转账成功的提示信息。
功能完成!看起来没有任何问题,但是这里却又一个CSRF漏洞,隐蔽而难于发现。
我是黑客,Show me the money
这里就有两个角色,银行的某个客户A,黑客B。
黑客B发现了银行的这个漏洞,就写了两个简单的页面,页面一(click_me_please.html):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
第一个页面仅包含了一个隐藏的iframe标签,指向第二个页面(click_me_please_iframe.html):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
第二个页面放置了一个form标签,并在里面放置了黑客自己的银行账号和转账金额,在页面打开时提交表单(body的onload属性)。
现在黑客把这两个页面放到公网:http://www.dkbjt123.com/