Web漏洞—CSRF

Posted 2021-04-25 don9sec

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Web漏洞—CSRF相关的知识，希望对你有一定的参考价值。

什么是跨站请求伪造（CSRF）

CSRF（Cross-site request forgery）跨站请求伪造，缩写为CSRF，通过伪装来自受信任用户的请求来利用受信任的网站。

与跨站脚本（XSS）相比，XSS 利用的是用户对指定网站的信任，而CSRF 利用的是网站对用户网页浏览器的信任。

CSRF的工作原理

这是一种使已登录用户在不知情的情况下执行某种动作的攻击。因为攻击者看不到伪造请求的响应结果，所以CSRF攻击主要用来执行动作，而非窃取用户数据。

CSRF攻击可以从站外和站内发起。

从站内发起CSRF攻击，需要利用网站本身的业务，比如“自定义头像”功能，恶意用户指定自己的头像URL是一个修改用户信息的链接，当其他已登录用户浏览恶意用户头像时，会自动向这个链接发送修改信息请求。

固定布局
工具条上设置固定宽高
背景可以设置被包含
可以完美对齐背景图和文字
以及制作自己的模板

图片来自：https://portswigger.net

CSRF的分类

GET型CSRF

POST型CSRF

链接类型CSRF

GET型CSRF

GET型CSRF利用非常简单，只需要一个以GET的方式发起一个HTTP请求即可。

利用姿势大多数情况如下：

当用户访问到含有这个img的页面时，便会向http://evil.com/csrf.php?id=1 发起一次HTTP请求。

固定布局
工具条上设置固定宽高
背景可以设置被包含
可以完美对齐背景图和文字
以及制作自己的模板

案例—恶意url

在上面的截图中，我们可以在url中看见一个正常的改密码的请求：

http://127.0.0.1/DVWA1.9/vulnerabilities/csrf/?password_new=123qwe&password_conf=123qwe&Change=Change#

利用思路：

构造恶意链接->发送恶意链接->用户点击->密码被修改（用户不知情的情况下）

构造恶意链接：

http://127.0.0.1/DVWA1.9/vulnerabilities/csrf/?

password_new=csrf&password_conf=csrf&

Change=Change#

发给用户

固定布局
工具条上设置固定宽高
背景可以设置被包含
可以完美对齐背景图和文字
以及制作自己的模板

step1:构造恶意链接，并发送给用户

step2:用户点击链接，csrf攻击完成

在step2的截图中，你可以发现Passwords Changed 提示。这就完成了一次get型csrf攻击，细心的人或许会发现url的get请求如此明显，会有人傻兮兮地去点吗？

对于这个问题，其实有很多方法，比如生成短链接或者构造一些具有欺骗性的页面等等，这里只是为了演示效果，便于理解。

案例—恶意页面

用burp自带的CSRF PoC进行攻击

利用思路：

用CSRF PoC -> 生成html利用代码 -> 粘贴到本地生成csrf-poc.html -> 浏览器访问（密码成功被修改，csrf攻击完成）

step1:利用burpsuite自带的CSRF PoC

step2:生成一个csrf-poc源码

step3:复制到本地，提交请求

step4:Passwords Changed，csrf攻击完成

POST型CSRF

POST型CSRF 的利用姿势通常使用的是一个自动提交的表单，当用户访问具有该表单的页面后，表单就会自动提交，相当于模拟用户完成了一次 POST 请求，与GET型差不多。但是这种类型的CSRF危害没有GET型的大。

固定布局
工具条上设置固定宽高
背景可以设置被包含
可以完美对齐背景图和文字
以及制作自己的模板

链接型CSRF

链接型CSRF并不常见，比起前两种用户打开页面就中招的情况，这种需要用户点击链接才会触发，但本质上与前两种一样。

这种类型通常是在攻击者在发布的图片中嵌入恶意链接，或者以广告的形式诱导用户点击。

比如：

由于之前用户登录了网站 evil.com，并且保存登录状态，所以只要用户主动点击并跳转到上面的链接处，则csrf攻击成功。

CSRF的危害

密码重置

获取用户的隐私数据

与其他漏洞打组合拳增加攻击面

CSRF 蠕虫

购买商品

添加管理员

虚拟货币转账

盗取账号

. . . . . .

固定布局
工具条上设置固定宽高
背景可以设置被包含
可以完美对齐背景图和文字
以及制作自己的模板

CSRF的挖掘姿势

（1）对敏感操作进行抓包分析，比如修改信息、转账、添加信息等。通常HTTP请求头里都有一个Referer，这个需要特别去验证。用burp的repeater模块去重放：去掉referer，看结果是否有变化。如果没有变化意味着这里的Referer服务器端并未验证，那就证明有可能存在CSRF，继续下一步；

（2）查看数据包是否存在类似CSRF token的字段、常见的有参数有token、sid…等随机字符串），没有即可排除CSRF Token的验证。

（3）大多数情况，以上两个流程就差不多可以判断是否是存在CSRF了。但是需要注意下面这个特殊情况：某些操作对数据包的提交采用Ajax，此时数据包的HTTP请求头会自定义一个字段，这时就相当于存在referer，所以没法进行csrf攻击了。

以下是常出现CSRF漏洞的地方：

个人信息修改处

购物车

简历信息

订单处

......

CSRF的防御

通过CSRF-token来检测用户提交

验证Referer/Content-Type

避免全站通用的cookie，设置cookie的域