admin 管理员组文章数量: 1086019
2024年4月19日发(作者：shell编程难度)
CSRF漏洞攻击原理及防御方案
作者
一.CSRF介绍
CSRF（Cross-siterequestforgery）全称“跨站请求伪造”，也被称为“OneClickAttack”
或者“SessionRiding”，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起
来像跨站脚本（XSS），但它与XSS非常不同。XSS利用站点内的信任用户，而CSRF则通过
伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往更加难以防
范。
可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义进行某些非法操作。CSRF能够
使用你的账户发送邮件，获取你的敏感信息，甚至盗走你的账户。
二.CSRF的危害
1、篡改目标网站上的用户数据；
2、盗取用户隐私数据；
3、作为其他攻击向量的辅助攻击手法；
4、传播CSRF蠕虫。
三.CSRF攻击原理及过程
美创科技安全实验室
如上图所示，CSRF攻击攻击原理及过程如下：
1.用户打开浏览器，访问受信任银行网站A，输入用户名和密码请求登录网站；
2.在用户信息通过验证后，网站产生Cookie信息并返回给浏览器，此时用户登录网站成功，可
以正常发送请求到网站；
3.用户未退出银行网站之前，在同一浏览器中，打开一个TAB页访问其他网站B；
4.这时候网站B已被黑客注入诱导信息，假如是一张图片,图片地址指向黑客构造的恶意url，
该url能完成黑客想干的某件事，比如修改用户的密码；
5.多数情况下，浏览器接收到这个url请求会失败，因为它要求用户的认证信息。但是，如果
用户还未退出网站A，或者当时恰巧刚访问网站A不久，他的浏览器与网站A之间的session尚
未过期，浏览器的cookie之中含有用户的认证信息。这时，悲剧发生了，这个url请求就会得
到响应，黑客就能以用户的权限修改密码，且用户毫不知情。
CSRF攻击的本质原因：
CSRF攻击是源于WEB的隐式身份验证机制！WEB的身份验证机制虽然可以保证一个请求是来
自于某个用户的浏览器，但却无法保证该请求是用户批准发送的！
四.CSRF的特点
➢攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生。
➢攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据。
➢整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”。
➢跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。部分请求方式可以
直接嵌入在第三方论坛、文章中，难以进行追踪。
CSRF通常是跨域的，因为外域通常更容易被攻击者掌控。但是如果本域下有容易被利用的功能，
比如可以发图和链接的论坛和评论区，攻击可以直接在本域下进行，而且这种攻击更加危险。
五.CSRF漏洞利用
利用DVWA靶场进行CSRF漏洞演练：
修改密码为123456，点击change，网页url中暴露出要修改的密码，并且能够发现url的构
造如下：
127.0.0.1/dwva/vulnerabilities/csrf/?password_new=admin&password_conf=ad
min&Change=Change#
为此，我们可以利用漏洞，构造链接：
127.0.0.1/DVWA/vulnerabilities/csrf/?password_new=111&password_conf=111
&Change=Change
诱导受害者点击这个页面，当受害者进入这个页面时，就已经受到了csrf的攻击。
当他重新登录时会发现用自己修改的密码（123456）登录不上
用攻击方设定的密码（111）就可以成功登陆。
六.CSRF防御方案
1.检验HTTPReferer来源
2.在请求地址中添加token并验证
3.在HTTP头中自定义属性并验证
4.设置验证码
5.尽量使用POST接口，限制GET接口
下面就分别对这5种策略进行详细介绍：
①检验HTTPReferer来源：
根据HTTP协议，在HTTP头中有一个字段叫Referer，它记录了该HTTP请求的来源地址。
大多数情况下，当浏览器发起一个HTTP请求，其中的Referer标识了请求是从哪里发起的。如
果HTTP头里包含有Referer的时候，我们可以区分请求是同域下还是跨站发起的，因为Referer
标明了发起请求的URL。网站也可以通过判断有问题的请求是否是同域下发起的来防御CSRF
攻击。
但是即使这样，验证HTTPReferer字段这种方式也存在安全隐患：
1.对于某些浏览器，比如IE6或FF2，目前已经有一些方法可以篡改Referer值
2.用户自己可以设置浏览器使其在发送请求时不再提供Referer
②在请求地址中添加token并验证
CSRF攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信
息都是存在于cookie中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的
cookie来通过安全验证。要抵御CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且
该信息不存在于cookie之中。可以在HTTP请求中以参数的形式加入一个随机产生的token，
并在服务器端建立一个拦截器来验证这个token，如果请求中没有token或者token内容不
正确，则认为可能是CSRF攻击而拒绝该请求。
这种方法要比检查Referer要安全一些，token可以在用户登陆后产生并放于session之中，
然后在每次请求时把token从session中拿出，与请求中的token进行比对。
③在HTTP头中自定义属性并验证
这种方法也是使用token并进行验证，和上一种方法不同的是，这里并不是把token以参数
的形式置于HTTP请求之中，而是把它放到HTTP头中自定义的属性里。通过
XMLHttpRequest这个类，可以一次性给所有该类请求加上csrftoken这个HTTP头属性，
并把token值放入其中。这样解决了上种方法在请求中加入token的不便，同时，通过
XMLHttpRequest请求的地址不会被记录到浏览器的地址栏，也不用担心token会透过
Referer泄露到其他网站中去。
④验证码
在发送请求前先需要输入基于服务端判断的验证码，强制用户必须与应用进行交互，才能完成最
终请求。在通常情况下，验证码能很好遏制CSRF攻击。
但是出于用户体验考虑，网站不能给所有的操作都加上验证码。因此验证码只能作为一种辅助手
段，不能作为主要解决方案。
⑤尽量使用POST接口，限制GET接口
GET接口太容易被拿来做CSRF攻击，只要构造一个链接，便可以进行CSRF攻击。接口最好限
制为POST使用，降低攻击风险。
当然POST并不是万无一失，攻击者只要构造一个form就可以，但需要在第三方页面做，这样
就增加暴露的可能性。
版权声明：本文标题：CSRF漏洞攻击原理及防御方案 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://roclinux.cn/b/1713493278a637429.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论