网络安全中级阶段学习笔记（五）：CSRF跨站请求伪造学习笔记（超全总结）

概念	定义	核心作用
Cookie	浏览器存储在本地的小型文本数据，由服务器下发并由浏览器自动携带	维持会话状态（如登录状态）、存储用户偏好
Session	服务器端存储的会话数据，通过SessionID与客户端Cookie关联	安全存储用户敏感信息（避免Cookie直接存敏感数据）
同源策略	浏览器核心安全策略，限制不同源的文档或脚本对当前文档的资源访问	防止恶意网站窃取用户Cookie、敏感数据

2. 同源策略详解

同源需满足「三个相同」：协议相同、域名相同、端口相同（默认端口80/443可省略）。

基准URL（http://www.store.com）	目标URL	是否同源	原因
http://www.store.com	http://www.store.com/order/page2.html	是	协议、域名、端口均相同
http://www.store.com	http://www.store.com/order2/other.html	是	路径不同不影响同源判断
http://www.store.com	http://www.store.com:81/order/page.html	否	端口不同（81≠80）
http://www.store.com	https://www.store.com/order/page.html	否	协议不同（https≠http）
http://www.store.com	http://en.store.com/order/page.html	否	域名不同（en.store.com≠www.store.com）

重点：带www与不带www的域名（如xyz.com与www.xyz.com）属于不同源，但实际应用中通常会配置映射到同一服务器，需注意安全风险。

二、CSRF核心原理

1. 定义

CSRF（Cross-site request forgery，跨站请求伪造），又称「一键攻击」，攻击者通过伪造用户的合法请求，利用浏览器自动携带的Cookie会话信息，以用户名义在信任的网站上执行非本意的操作。

2. 攻击核心逻辑

浏览器信任用户的Cookie，服务器信任携带合法Cookie的请求 → 攻击者无需获取Cookie，只需诱使用户在登录状态下触发伪造请求。

3. 攻击流程图

4. 攻击成立的两个必要条件

用户已登录信任网站A，且Cookie仍有效（未过期、未登出）；
用户在未登出A的情况下，主动访问了攻击者控制的恶意网站B，或点击了恶意链接。

5. CSRF攻击的特点

攻击者无法获取用户的Cookie，仅能「借用」Cookie的身份验证；
攻击仅能发送请求，无法获取服务器的响应结果（受同源策略限制）；
攻击依赖用户的主动触发（点击链接、访问页面等）。

三、CSRF攻击类型与实例

常见CSRF攻击分为GET型和POST型，核心区别在于请求的提交方式。

1. GET型CSRF（最常见、最简单）

核心原理

通过URL拼接参数构造恶意请求，利用img、a等标签自动/被动触发GET请求。

实战实例：修改密码攻击

目标漏洞URL（DVWA靶场）：

复制代码

http://xxx.xxx.xxx.xxx/dvwa/vulnerabilities/csrf/?password_new=123&password_conf=123&Change=Change#（GET请求直接修改密码）；

攻击者构造恶意HTML（伪装成「0元充值」链接）：

复制代码

<html>
<body>
<a href="http://xxx.xxx.xxx.xxx/dvwa/vulnerabilities/csrf/?password_new=123&password_conf=123&Change=Change#">0元充值</a>
</body>
</html>

攻击流程：

典型场景

银行转账（如http://www.mybank.com/Transfer.php?toBankId=118&money=1000）、关注用户、点赞等简单操作。

2. POST型CSRF（相对复杂，隐蔽性强）

核心原理

通过构造隐藏的表单，利用JavaScript自动提交POST请求，无需用户主动点击。

实战实例：银行转账攻击（绕过POST限制）

银行优化为POST转账表单：

html 复制代码

<form action="Transfer.php" method="POST">
<p>ToBankId: <input type="text" name="toBankId" /></p>
<p>Money: <input type="text" name="money" /></p>
<p><input type="submit" value="Transfer" /></p>
</form>

攻击者构造恶意HTML（自动提交POST请求）：

html 复制代码

<html>
<head>
<script type="text/javascript">
function steal() {
iframe= document.frames["steal"];
iframe.document.submit("transfer");
}
</script>
</head>
<body onload="steal()">
<iframe name="steal" display="none">
<form method="POST" name="transfer" action="http://www.myBank.com/Transfer.php">
<input type="hidden" name="toBankId" value="11">
<input type="hidden" name="money" value="1000">
</form>
</iframe>
</body>
</html>

攻击流程：用户登录银行 → 未登出访问恶意页面 → 页面加载时自动提交POST转账请求 → 资金被转走。

3. GET型与POST型对比表

类型	实现难度	隐蔽性	触发方式	典型载体
GET型	低	低（URL可见参数）	自动触发（img标签）或被动点击（a标签）	img、a、iframe
POST型	中	高（参数在请求体）	JavaScript自动提交表单	隐藏表单+JS脚本

4. 真实案例汇总

案例	攻击方式	危害
京东商城刷关注	GET型CSRF，构造关注接口URL（`http://t.jd.com/product/followProduct.action?productId=xxx`）	恶意提升商品关注度
暴走漫画刷金币	POST型CSRF，构造打赏接口表单并自动提交	盗取用户虚拟货币
TP-Link路由器DNS劫持	GET型CSRF，构造路由器DNS配置修改请求（`http://192.168.1.1/userRpm/LanDhcpserverRpm.htm?dnsserver=攻击者IP`）	劫持用户所有网络请求，窃取敏感信息
百度Hi CSRF蠕虫	结合短消息CSRF漏洞与好友信息泄露漏洞，实现自我复制传播	大规模用户信息泄露，蠕虫指数级传播

四、CSRF进阶：跨域资源劫持

传统CSRF以「写操作」为主（如转账、改密码），进阶形式为「读操作」的跨域资源劫持，利用跨域机制窃取用户敏感数据，常见类型包括JSONP劫持、CORS劫持、OAuth劫持。

1. 跨域资源劫持核心原理

利用浏览器跨域机制的配置缺陷（如JSONP的开放性、CORS的宽松配置），突破同源策略限制，获取用户在信任网站上的敏感数据（如个人信息、授权码）。

2. 常见进阶攻击类型对比

类型	依赖机制	攻击条件	典型危害
JSONP劫持	JSONP跨域（script标签无跨域限制）	目标接口支持JSONP、无Referer校验、无Token验证	窃取用户个人信息（手机号、邮箱）
CORS劫持	CORS跨域资源共享机制	服务端配置缺陷（如ACAO为*、反射Origin、ACAC为true）	跨域读取用户敏感数据、携带Cookie发起攻击
OAuth劫持	OAuth 2.0授权协议	redirect_uri限制不严、存在URL跳转漏洞	窃取授权码、劫持用户账号（发微博、刷粉）

3. 关键知识点补充

（1）JSONP劫持核心流程

攻击者构造恶意页面，定义回调函数（如test(data)）；
通过script标签请求目标JSONP接口（如http://target.com/api?callback=test）；
用户登录目标网站后访问恶意页面，浏览器自动携带Cookie请求接口；
接口返回数据被回调函数捕获，攻击者获取敏感信息。

（2）CORS劫持关键配置缺陷

Access-Control-Allow-Origin（ACAO）设为*，且Access-Control-Allow-Credentials（ACAC）为true；
反射请求Origin作为ACAO值（如请求Origin为攻击者域名，响应ACAO也为该域名）；
Origin校验逻辑错误（前缀/后缀匹配漏洞，如允许example.com.attack.com）。

（3）OAuth劫持核心思路

利用redirect_uri限制不严的漏洞，将授权码引导至攻击者可控地址；或在目标网站嵌入恶意图片，通过Referer泄露授权码，最终获取access_token劫持用户账号。

五、CSRF防御措施（核心重点）

CSRF防御的核心思路是：让服务器能够区分请求是用户主动发起的，还是攻击者伪造的，优先从服务器端防御，客户端防御作为辅助。

1. 服务器端防御（最有效）

防御措施	核心原理	注意事项
Anti-CSRF Token（推荐）	服务器生成随机Token，嵌入表单/页面；请求时需携带Token，服务器验证有效性	1. Token需足够随机（如使用加密随机数）；2. 避免Token放在URL中（易泄露）；3. 防止XSS窃取Token
Referer Check（请求来源校验）	验证HTTP请求头的Referer字段，仅允许可信来源（如自身域名）的请求	1. 部分场景无Referer（如直接输入URL），需兼容；2. Referer可被篡改，仅作辅助防御
限制请求方法	敏感操作（转账、改密码）仅允许POST请求，禁用GET请求	POST并非绝对安全，仅增加攻击成本，需配合其他措施
二次验证（验证码/密码）	敏感操作需用户额外输入验证码或二次密码，强制用户交互	影响用户体验，仅适用于核心敏感操作（如大额转账、删除账号）

2. 客户端防御（辅助）

及时登出信任网站，避免长时间保持登录状态；
不随意点击不明链接、访问未知网站；
开启浏览器安全设置，禁用第三方Cookie（部分浏览器支持）。

3. 防御措施优先级

Anti-CSRF Token → 二次验证 → Referer Check + 限制请求方法 → 客户端安全习惯

六、核心总结

CSRF攻击的本质是「借用用户身份执行恶意操作」，核心依赖「浏览器自动携带Cookie」和「服务器信任Cookie验证」；防御的核心是「增加请求的不可伪造性」（如Token）和「验证请求的合法性」（如Referer、二次验证）。

学习重点：掌握GET/POST型CSRF的攻击流程、理解跨域机制对CSRF进阶攻击的影响、熟练应用Anti-CSRF Token等核心防御措施，结合靶场（DVWA、Pikachu、DoraBox）实战加深理解。