同源策略如何防范CSRF

wen 网络安全 2026-06-29 28

同源策略如何防范CSRF：浏览器安全机制深度解析

目录导读

什么是同源策略与CSRF攻击？
同源策略如何阻断CSRF的核心原理
同源策略的局限性（为何仍需额外防护）
实战场景：同源策略如何阻止恶意请求
常见问答：解答你对同源策略与CSRF的疑惑
构建多层次防御体系

什么是同源策略与CSRF攻击？

同源策略（Same-Origin Policy）是浏览器最核心的安全机制之一，它规定：只有协议、域名、端口完全相同的网页，才能相互访问对方的资源。https://example.com:443 下的脚本无法读取 https://evil.com 的页面数据。

同源策略如何防范CSRF

CSRF（跨站请求伪造）则是攻击者诱导用户在不知情下，向目标网站发送恶意请求的攻击方式，用户登录银行网站后，访问恶意页面,该页面自动发起转账请求。

同源策略被视为防范CSRF的第一道天然屏障，但它并非万能——关键在于理解它如何“限制”而非“完全阻挡”跨站请求。

同源策略如何阻断CSRF的核心原理

同源策略防范CSRF的机制主要体现在请求读取限制上，而非请求发送限制,具体分为三个层面：

阻止跨域读取响应数据

同源策略禁止网页脚本读取跨域请求的响应内容。

攻击者页面通过 fetch('https://bank.com/api/transfer') 发送了请求。
虽然请求会发出，但浏览器会拒绝脚本读取响应中的 set-cookie 头或响应体数据。
因此攻击者无法利用用户Cookie的自动携带特性（Cookie SameSite=Lax/Strict 场景下）完成敏感操作，因为他们看不到操作结果,也无法通过响应获取攻击所需的信息。

阻止跨域写入Cookie

同源策略严格限制跨域文档之间的Cookie访问：

来自 evil.com 的脚本无法读取或修改 bank.com 的Cookie。
即使Cookie携带在请求中，攻击者也无法通过JavaScript获取Cookie值,从而无法伪造用户身份令牌。

阻止DOM访问跨域页面

同源策略禁止跨域窗口之间通过 window.open、iframe 等交互：

攻击者页面无法通过 document.cookie 读取银行页面的Cookie。
无法通过 document.getElementById 获取银行页面中的隐藏表单数据。

关键点：同源策略真正“防”的是攻击者获取受害者的密文信息（如Cookie、CSRF Token），如果没有同源策略,攻击者可以直接读取用户的会话凭证并伪造请求。

同源策略的局限性（为何仍需额外防护）

虽然同源策略很强，但它无法完全阻挡CSRF,原因有三：

请求本身会被发出（不限制发送）：浏览器会默认携带同站Cookie到目标服务器，即使响应无法被攻击者读取，请求本身已经到达服务器并执行操作（例如转账、改密），同源策略只限制“读”，不限制“写”。
简单的GET/POST请求可被直接触发：
- 攻击者可使用 <img>、<form> 等HTML标签发起GET或POST请求,这些请求不依赖JavaScript。
- img 标签的 src 属性或表单的 action 属性可指向任意URL,且浏览器会自动附加Cookie。
SameSite Cookie的默认行为变化：2021年后，Chrome等浏览器将默认SameSite设为Lax（部分跨场景发送），但仍有遗留场景（如POST表单）会发送Cookie。Lax模式下，当请求由“顶级导航”触发时（如点击链接）,Cookie仍会携带。

同源策略是防御CSRF的基石，但必须结合CSRF Token、SameSite Cookie、Referer校验等方法形成多层次防护。

实战场景：同源策略如何阻止恶意请求

场景1：攻击者通过JS脚本发送跨域请求

<!-- evil.com 页面 -->
<script>
  fetch('https://bank.com/api/transfer?to=hacker&amount=1000', {
    credentials: 'include' // 携带Cookie
  }).then(response => {
    console.log(response); // 同源策略阻止读取响应体
  });
</script>

结果：请求会发送到服务器，但浏览器因同源策略阻止获取响应数据，攻击者无法知晓转账是否成功，也无法获取新的CSRF Token。

场景2：攻击者利用HTML标签发起请求

<img src="https://bank.com/api/delete?account=123">

结果：同源策略无法阻止此类请求！因为 <img> 标签的GET请求遵循跨域资源嵌入规则（允许加载图片、脚本等资源），服务器必须依赖其他机制（如Token校验）防御。

场景3：SameSite Cookie与同源策略的协同

假设 bank.com 的Cookie设置为 SameSite=Strict：

任何来自 evil.com 的跨站请求都不会携带Cookie。
即使 <img> 标签发起请求，由于无Cookie,服务器会拒绝执行操作。
这体现了“同源策略+SameSite”的组合优势。

常见问答：解答你对同源策略与CSRF的疑惑

Q1：同源策略能完全阻止CSRF吗？ 不能，它只能阻止攻击者读取跨站请求的响应，但无法阻止请求本身发送，CSRF的核心是利用用户已登录状态直接执行操作，而非获取数据,因此必须配合Token等机制。

Q2：为什么浏览器不同源策略更严格？ 设计时优先考虑了Web内容的开放性与兼容性，允许跨域加载资源（如图片、CSS）是互联网的基础功能，而“写入攻击”无法完全通过浏览器层阻断,需要服务器端配合。

Q3：如果攻击者使用HTTP而非HTTPS，同源策略是否失效？ 不会，同源策略判断的是协议是否一致。http://evil.com 与 https://bank.com 协议不同，属于不同源,同样受限制。

Q4：现代浏览器如何通过SameSite强化同源策略？ SameSite=Lax 允许GET请求携带Cookie（常见于链接跳转），但阻止POST表单跨站点发送Cookie；Strict 则完全禁止跨站Cookie,这大幅缩小了CSRF的攻击面。

构建多层次防御体系

同源策略是浏览器安全的第一道防线，它通过限制跨域读写使CSRF攻击更困难，但单靠它不够——现代Web应用应结合：

SameSite Cookie（至少Lax模式）
CSRF Token（动态生成、每次请求携带）
Referer/Origin头校验（部分场景有效）
关键操作二次验证（如短信验证码）

理解同源策略的“防读取不防发送”特性，才能科学设计安全方案。安全是系统工程，没有银弹,但同源策略绝对是其中最重要的一块基石。