javascript CSRF攻击是什么_如何验证请求的来源？-js教程-PHP中文网

javascript CSRF攻击是什么_如何验证请求的来源？

夜晨

发布： 2025-12-16 22:41:02

原创

812人浏览过

JavaScript本身不发起CSRF攻击，而是作为载体诱使浏览器发送带Cookie的恶意请求；防护必须由服务端实现，如CSRF Token、SameSite Cookie或双重Token机制。

javascript csrf攻击是什么_如何验证请求的来源？

JavaScript CSRF（跨站请求伪造）攻击不是通过 JavaScript 直接发起的“CSRF 攻击”，而是指攻击者利用用户已登录的合法身份，在用户不知情时，诱使其浏览器向目标网站发送恶意请求——这些请求由浏览器自动携带 Cookie（含 session 信息），而前端 JavaScript 本身通常无法读取或伪造其他域的 Cookie。真正的问题在于：前端 JS 发起的跨域请求（如 fetch 或 XMLHttpRequest）若未受控，可能被诱导执行非预期操作（例如提交表单、调用 API），尤其当后端缺乏有效防护时。

CSRF 的本质是服务端信任了“来自用户浏览器的请求”，却未验证该请求是否由用户真实意愿触发

JavaScript 本身不“发起 CSRF”，但它常作为载体（比如嵌入恶意页面的脚本）触发浏览器发出带凭证的请求。关键点：

浏览器对同源请求自动携带 Cookie，JS 无需显式传 token；
跨域请求（如 POST 到 bank.com）若目标服务允许凭 Cookie 认证且无额外校验，就可能被滥用；
现代浏览器的 CORS 策略会阻止 JS 读取跨域响应，但不会阻止跨域请求发出（尤其是简单请求如 GET/POST + 普通 Content-Type）。

不能依赖 JavaScript 验证来源（Referer / Origin）

前端 JS 无法可靠获取或校验请求的真实来源：

document.referrer 可被禁用或伪造（如从本地文件打开、隐私模式、中间代理）；
JS 无法读取跨域响应头（如 Origin），也无法拦截自身发出的请求去检查 header；
试图在 JS 中判断 window.location.origin 并拼接请求？这只能约束“你写的代码”，无法防御别人仿写一个表单或 curl 请求。

真正的防护必须在服务端实现

验证请求来源和意图，是后端的责任。常用且有效的方案：

Zapier Agents

Zapier推出的Agents智能体，集成7000+应用程序

103

查看详情

立即学习“Java免费学习笔记（深入）”；

CSRF Token（推荐）：服务端为每个用户会话生成一次性或短期有效的随机 token，要求所有状态变更请求（POST/PUT/DELETE）必须携带该 token（通常放在 form hidden 字段或请求 header 如 X-CSRF-Token）。服务端比对 session 中存储的 token 是否匹配且未使用过。
SameSite Cookie 属性：设置关键 Cookie（如 sessionid）的 SameSite=Strict 或 SameSite=Lax，可阻止浏览器在跨站请求中自动携带该 Cookie，大幅降低 CSRF 风险（注意兼容性，老版本浏览器不支持）。
双重 Cookie/Token 模式（适合纯 API 场景）：前端 JS 从 cookie 读取一个 token（csrf_token），再将其作为 header（如 X-XSRF-Token）发送；服务端比对 header 中的值与 cookie 中的值是否一致（Angular 的默认机制）。注意：仅适用于 cookie 可被 JS 读取的场景，且需配合 HttpOnly=false —— 这会略微增加 XSS 风险，需确保 XSS 防护到位。
校验 Origin / Referer 请求头（辅助手段）：服务端检查 HTTP 请求头中的 Origin（优先）或 Referer，确认其属于白名单域名。这不是替代方案，因为 Origin 在某些请求中可能缺失（如 POST 表单跳转），且无法防御同域 XSS 引发的伪造。