WEB安全
00-HTTP协议
01-前端基础【HTML】
02-前端基础【CSS】
03-后端基础【PHP速通】
04-后端基础【PHP面向对象】
05-MySQL基础操作
06-前后端联动【代码练习】
07-SQL注入
08-SQL注入 Labs
09-跨站脚本攻击【XSS】
09-XSS Labs
10-CSRF
11-SSRF
12-XML 外部实体注入【XXE】
13-代码执行漏洞
14-命令执行漏洞
15-文件包含漏洞
16-文件上传漏洞
17-反序列化漏洞
18-业务逻辑漏洞
19-未授权访问漏洞集合
20-跨源资源共享【CORS】
21-SSTI模板注入
22-并发漏洞
23-点击劫持【Clickjacking 】
24-请求走私
25-路径遍历
26-访问控制
27-身份验证漏洞
28-WebSocket
29-Web缓存中毒
30-HTTP 主机头攻击
31-信息泄露漏洞
32-原型污染
33-API概述
34-API分类类型
35-API交换格式
36-API身份验证
37-API常见漏洞
38-crAPI靶场
39-JWT
40-DVGA靶场
41-服务器端参数污染
42-API Labs
43-OAuth Labs
44-GraphQL API Labs
45-JWT Labs
46-小程序抓包
47-云存储
48-对象存储OSS
49-存储桶
50-存储桶漏洞
51-STS访问OSS
-
+
10-CSRF
浏览
2
 ## 什么是CSRF 跨站请求伪造(Cross-Site Request Forgery,简称CSRF),是一种网络安全漏洞,攻击者可以利用该漏洞诱导用户执行其无意执行的操作,利用用户**已认证身份**发起非预期操作的攻击方式。 核心原理是:攻击者诱导受害者在**已登录目标网站**的情况下,访问恶意页面或点击恶意链接,从而触发向目标网站的 “跨站请求”—— 由于浏览器会自动携带目标网站的身份凭证(如 Cookie),目标网站会误认为这是用户的 “主动操作”,进而执行攻击者预设的恶意行为。 ## 同源策略 同源策略(Same-Origin Policy, SOP)是浏览器的核心安全机制,用于限制一个网页文档或脚本如何与来自其他 “源” 的资源进行交互。 其核心目的是隔离不同源的内容,防止恶意网站通过跨域请求窃取敏感数据或执行未授权操作。 “源”(Origin)由三个要素唯一确定,只有当两个资源的这三个要素完全一致时,才被视为 “同源”: 1. 协议(Protocol):如 http、https、ftp(注意:http 和 https 属于不同协议,即使域名相同也不同源); 2. 域名(Domain):如 `www.example.com`、blog.example.com(注意:主域名相同但子域名不同,也属于不同源); 3. 端口(Port):如 80(HTTP 默认端口)、443(HTTPS 默认端口)、8080(自定义端口)(注意:即使协议和域名相同,端口不同也不同源)。 同源策略的核心限制范围,同源策略主要限制不同源的资源之间的交互,具体包括以下三类关键行为: 1. 限制 DOM 访问:不同源的网页无法直接操作对方的 DOM(文档对象模型); 2. 限制 AJAX/Fetch 请求:不同源的脚本无法通过 XMLHttpRequest 或 Fetch API 直接向其他源发送请求并获取响应; 3. 限制存储资源访问:不同源的网页无法访问对方存储在浏览器中的敏感数据。 ## 造成的影响 在成功的 CSRF 攻击中,攻击者会诱使受害用户无意中执行操作。例如,可能是更改其帐户的电子邮件地址、更改密码或进行资金转账。根据操作的性质,攻击者可能能够完全控制用户的帐户。如果受感染的用户在应用程序中拥有特权角色,那么攻击者可能能够完全控制应用程序的所有数据和功能。 ## 攻击流程 假设目标网站是某银行(bank.com),攻击者构造恶意网站(evil.com),攻击流程如下: 1、受害者登录目标网站。 受害者先登录 bank.com,银行服务器验证通过后,在受害者浏览器中种下身份凭证(如 Cookie:user=victim; session=abc123),用于后续请求的身份识别,此时受害者处于 “已登录” 状态。 2、攻击者诱导受害者访问恶意网站。 攻击者通过邮件、短信等方式,诱导受害者点击链接 evil.com/attack,受害者在仍登录 bank.com 的情况下,访问了该恶意网站。 3、恶意网站触发跨站请求。 恶意网站的页面中,隐藏着向bank.com发起的请求(可能是表单自动提交、图片加载、AJAX等),例如: ```html <!-- evil.com 中的恶意代码 --> <form action="https://bank.com/transfer" method="POST" id="hackForm"> <input type="hidden" name="to" value="attackerAccount"> <!-- 转账目标:攻击者账户 --> <input type="hidden" name="amount" value="10000"> <!-- 转账金额 --> </form> <script>document.getElementById('hackForm').submit();</script> ``` 当受害者访问 evil.com 时,这段代码会自动向 bank.com/transfer 发送 POST 请求。 4、浏览器自动携带身份凭证。 由于请求的目标是 bank.com,浏览器会自动将 bank.com 的 Cookie(包含受害者的登录凭证)附加到请求中,发送给银行服务器。 5、目标网站误判为用户主动操作。 银行服务器收到请求后,通过 Cookie 验证身份(确认是受害者),且请求参数完整(有收款账户和金额),便认为这是受害者的 “主动转账操作”,从而执行转账,将受害者账户中的 10000 元转给攻击者。 > **核心条件:** 受害者已登录目标网站; 攻击者能构造有效请求; 受害者被动触发跨站请求。 ## 防护措施 防护的核心思路是:**让服务器能够区分请求是 “用户主动发起” 还是 “恶意诱导触发”**。 > **1. CSRF Token** 核心是通过一个随机且不可预测的令牌验证请求的合法性。 原理:用户登录后,服务器在当前会话中生成一个随机、唯一的Token值,并且存储在服务器端(如Session)中;服务器在返回的页面(如表单页、前端页面)中,将Token嵌入到表单隐藏字段或者前端存储(如JavaScript变量)中;当用户提交请求时,前端必须将Token作为请求参数一起发送,服务器收到请求后,对比请求中的Token与服务器端存储的Token。 > **2. SameSite Cookie 属性(浏览器层面防护)** 通过设置 Cookie 的 SameSite 属性,限制浏览器在跨站请求中是否携带 Cookie,从根源上阻止 “跨站请求携带身份凭证”。 原理:SameSite 是 Cookie 的扩展属性,用于控制跨站请求时 Cookie 的发送策略,可选值有:**Strict**(完全禁止跨站请求携带 Cookie,例如,bank.com 的 Cookie 不会在 evil.com 发起的任何请求中被携带,无论请求类型。)、**Lax**(仅允许 “安全的跨站导航” 携带 Cookie,例如通过 \<a> 标签跳转、GET 表单提交等,禁止 POST、AJAX 等跨站请求携带。)。 > **3. 验证 Referer/Origin 请求头** 通过检查请求的来源(Referer 或 Origin 头),确认请求是否来自可信域名。 原理:浏览器在发送请求时,会自动在请求头中添加 Referer 或 Origin,标识请求的来源页面 URL,服务器可配置 “可信域名白名单”(如自身域名 bank.com),收到请求后检查 Referer 或 Origin。 Referer:包含完整的来源 URL(如 https://www.trust.com/page.html); Origin:仅包含协议和域名(如 https://www.trust.com),在跨站请求中更常用。 > **4. 敏感操作二次验证** 对于高风险操作(如转账、修改密码、删除数据),强制要求用户进行 “二次验证”,确保是用户主动意愿。 ## CSRF 与 XSS 很多人会混淆 CSRF 和 XSS,两者核心差异在于: XSS:利用漏洞在目标网站注入恶意脚本,直接**获取用户数据**(如 Cookie、账号密码)或操作当前页面 DOM; CSRF:不注入脚本,而是**利用用户已有的身份凭证**,诱导用户触发跨站请求,让目标网站执行非预期操作(如转账、删帖)。 简单说:XSS 是 “偷数据”,CSRF 是 “借身份做事”。 ## 实验 靶机地址:https://portswigger.net/web-security/csrf/lab-no-defenses 任务:制作一些使用 CSRF 攻击来更改查看者电子邮件地址的 HTML,并将其上传到漏洞服务器。 凭证登录帐户:wiener:peter。 1、访问靶机地址,并登录账户。  2、登录之后,观察到可以更改账户的邮箱地址,进行尝试后发现可以直接更改成功。   3、通过Burp制作CSRF的POC。 抓取更改邮箱地址的数据包。  在数据包的任意位置,点击鼠标右键,可以直接制作POC【注意:burp的专业版才有此功能】  4、对于这个靶机而言,官方提供了对于社区版burp的html模板。 ```html <form method="POST" action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email"> <input type="hidden" name="email" value="anything%40web-security-academy.net"> </form> <script> document.forms[0].submit(); </script> ``` 只需要将form标签中的action属性替换为当前的靶场 地址即可,也可以修改邮箱的value值。 在数据包的任意位置,点击鼠标右键,选择【Copy URL】,即可复制当前的URL。 ```html <form method="POST" action="https://0a21006c0448d9fa80fd03ff004d00b6.web-security-academy.net/my-account/change-email"> <input type="hidden" name="email" value="James%40normal-user.net"> </form> <script> document.forms[0].submit(); </script> ``` 5、点击靶机页面上方的漏洞服务器。  6、将制作好的POC,复制到Body中,点击【View exploit】。  邮箱地址更改成功。 
毛林
2026年11月15日 18:27
转发文档
收藏文档
上一篇
下一篇
评论(0)
登录
后可发表评论
还没有评论,来抢沙发~
手机扫码
复制链接
手机扫一扫转发分享
复制链接
Markdown文件
Word文档
PDF文档(打印)
分享
链接
类型
密码
更新密码
还没有评论,来抢沙发~