前言
在前面三篇 SQL注入系列文章中，我们基本掌握了 手工漏洞验证能力 + 工具高效辅助思维，建立了Web安全最核心的底层渗透逻辑。
本篇进入新的章节，新手容易在SRC挖到漏洞的领域：XSS跨站脚本攻击。
SQL注入的防护越来越严格，WAF基本全覆盖，新人很难有限出洞；但 XSS漏洞不少存在于企业官网、后台管理、搜索框、留言板、个人中心，是公益SRC、厂商SRC等相对来说高频、容易提交成功、容易积累成果的中低危漏洞。
本文秉承着不说废话的原则，把 三类XSS原理、触发条件、挖掘位置、手工Payload、过滤绕过、真实SRC审计思路 一次性讲透，靶场依旧选择我们的皮卡丘！pikachu的靶场演示
一、XSS核心本质（面试掌握+靶场验证逻辑）
XSS（Cross-Site Scripting）跨站脚本漏洞，本质是：
后端未过滤用户可控输入 → 前端直接渲染输出 → 攻击者可控JS代码被浏览器执行
和SQL注入类似，属于输入输出不信任漏洞，是Web安全中的经典漏洞类型。
核心危害（SRC报告话术）：劫持用户Cookie、钓鱼诱导、后台权限接管、页面篡改、挂黑页、恶意代码执行，可窃取用户敏感信息、劫持用户会话，严重威胁站点与用户安全。
靶场对照逻辑：Pikachu所有XSS关卡，均严格遵循该漏洞成因，无多余复杂环境，专注复现「输入可控-无过滤-前端执行」的核心链路。
二、三类XSS分类、实战区别+Pikachu靶场逐类复现
三类XSS是SRC提交、面试、渗透测试的核心考点，接下来博主结合原理特点+靶场实操逐一拆解，复现步骤零基础可直接照搬。
1. 反射型XSS（一次性）（危害较小src可能不收）
漏洞原理
用户提交参数 → 服务器接收 → 立即回显页面 → 执行JS → 关闭页面即失效
核心特点
-
无数据库存储，漏洞只有一次性生效
-
需要诱导用户点击恶意链接才能触发
-
高发位置：搜索框、跳转参数、页面标题、提示信息
Pikachu靶场实操复现（Reflected XSS）
靶场路径：Pikachu – XSS – 反射型xss(get)
1）场景说明：页面存在输入回显功能，用户输入的内容会直接展示在页面中，后端无任何过滤，是典型的反射型业务场景
2）基础探测Payload：<script>alert(1)</script>
这里发现长度超出了输入框的限制，首先我们观察到这只是前端的限制，所以我们可以选择在浏览器的开发者工具F12中修改前端限制代码（这个思路适用于许多需要绕过前端限制的地方），我们选中输入框，发现输入框进行了20个字符长度的限制，我们把限制改成100，然后再输入测试代码，发现弹窗成功，这样就进行了一次简单的前端限制绕过
3）漏洞验证：提交后页面直接弹窗，URL参数中携带恶意代码，关闭页面后漏洞失效，完美印证反射型XSS「一次性、无存储」的特点
4）漏洞利用（贴合SRC危害）：小伙伴们看到这可能会疑惑，你这就弹个弹窗有个卵用，虽然反射型xss确实危害没有那么大，但是还是有发掘价值的。既然我们构造的js代码可以利用，我们就可以构造一个恶意代码比如获取当前访问用户的cookie并发到攻击者自己的服务器上，把类似的恶意js代码拼接到网址中，然后把构造好的网址发给目标用户（结合社会工程学），就会产生危害。除了获取cookie还能盗取个人信息，或者诱导用户下载恶意文件，记录键盘输入，页面跳转等操作，具体要结合社会工程学和网站本身特性来构造（网上也有很多构造好的js代码）
5）我们可以看到除了GET型传参的xss皮卡丘靶场里还有一个POST型传参的xss，大家看过之前的两篇文章或者是对传参有一定了解的可能会想是不是要抓包，实则不然。post传参的xss利用条件比较苛刻，首先因为post型传参在实际测试中基本没办法在网址或者输入框等地方输入（pikachu靶场的post反射型xss这关登录之后就可以看到post的输入框，就可以进行xss），所以此时我们如果想利用到POST传参就需要自己构造一个前端页面，页面上携带我们写好的传给目标网站的恶意POST参数，在进行利用的时候，受害者需要已经登录目标网站，浏览器保存有效 Cookie（关键！），此时攻击者把这个恶意 html 文件发给受害者，诱导打开，页面加载瞬间自动发送 POST 请求，携带 XSS payload，服务器接收 POST 参数，把 payload 反射回页面返回给受害者浏览器，受害者浏览器渲染页面，执行恶意 JS（偷 Cookie / 钓鱼 / 执行操作）
2. 存储型XSS（永久性、SRC会收）
漏洞原理
用户输入内容 → 存入数据库 → 任何人访问页面都会触发JS执行
核心特点
-
永久存在页面与数据库中，持久化漏洞
-
无需诱导，任意用户访问页面自动触发
-
高发位置：留言板、评论、用户昵称、公告提交、反馈模块
SRC收录优先级：存储型 > 反射型
Pikachu靶场实操复现（Stored XSS）
靶场路径：Pikachu – XSS – 存储型xss
打开之后我们看到经典的留言板（存储型xss漏洞存在较多的地方）我们直接注入xss的测试代码
<img src=x onerror=alert('存储XSS成功')>
可以看到页面成功弹出了我们想要打印的信息，这样就算漏洞测试成功
那存储型和反射型的区别是什么呢，前面也提到过，存储型xss属于是持久性的xss，我们输入的xss测试代码不止停留在了前端，还传入了网站后端的数据库，也就是说在我们上传了恶意js代码之后任何人访问这个页面都会触发攻击造成信息泄露。
3. DOM型XSS（前端漏洞、难挖、大厂SRC高频）
-
纯前端JS逻辑漏洞，一些WAF拦截不到位
核心JS关键词（全局检索）
-
innerHTML / outerHTML
-
前端输出编码：统一使用HTML实体编码、JS编码、URL编码，转义特殊字符
复现验证思路：访问构造链接，页面成功弹窗；全程抓包无任何恶意请求发送至服务器，后端无日志，完全符合DOM XSS漏洞特征
我们输入测试代码后，点击What do you see，就可以看到我们的代码弹窗成功
' onclick=alert(1)//
DOM型XSS深入原理拆解（底层技术原理）
核心逻辑：Source（数据源） -> 传输/处理 -> Sink（危险函数）
DOM型XSS的本质是纯前端漏洞。后端只下发静态的 HTML+JS，漏洞的产生完全在于前端JS代码将“不可信的数据”写入了“危险的位置”。
1. Source（可控数据源）
攻击者能够控制的数据输入点，最常见的有：
-
location.search（URL的?后面的参数）
-
location.hash（URL的#后面的内容，不发给服务器）
-
location.href / document.referrer / window.name
-
postMessage（跨窗口通信）
-
localStorage / sessionStorage（存储型DOM XSS）
2. Sink（危险接收器）
前端JS将数据写入这些位置时，如果没有做安全处理，就会导致代码执行：
-
HTML相关：innerHTML、outerHTML、document.write、insertAdjacentHTML
-
JS执行：eval()、setTimeout()、setInterval()、new Function()
-
属性/URL：location.href = 'javascript:…'、src、href
3. 为什么Pikachu的Payload是 ' onclick=alert(1)// ？
结合Pikachu DOM型的源码（通常是 document.getElementById("a").innerHTML = "…"），当你的输入被塞进 innerHTML 时，浏览器会将其解析为HTML。
-
'：闭合原有的HTML属性值（就比如闭合了原有的 href="…" 中的引号）。
-
onclick=alert(1)：利用HTML解析器规则，属性名以 on 开头（如 onclick, onerror）会被浏览器绑定为事件处理器，属于JS执行环境。点击时触发。
-
//：JS注释符，把原本后面多余的引号、标签等代码注释掉，类似于我们之前学的SQL注入语句，防止语法错误导致弹窗失败。
-
核心总结：DOM型XSS的挖掘秘诀就是 “全局搜索Source，顺藤摸瓜找Sink”。在F12中搜索 location、innerHTML、eval 等关键词，找到数据流执行链。
四、零基础手工Payload体系（由简到繁+靶场逐一套用）
常用闭合Payload：
1. 注入在【双引号 HTML 属性】（value="这里输出你的输入"）
" onclick=alert(1)//
解析：" 闭合原有双引号，新增 onclick 事件，//注释后面剩余引号。 拼接后示例：<input value="" onclick=alert(1)//">
2. 注入在【单引号 HTML 属性】（Pikachu DOM 关卡，href='你的输入'）
' onclick=alert(1)//
解析：' 闭合前面单引号，注入事件，//注释后面多余单引号。 拼接后：<a href='' onclick=alert(1)//'>xxx</a>
3. 注入在【HTML 正文】（直接输出在页面标签之间，不用闭合引号）
不需要引号闭合，直接写标签 payload
<img src=x onerror=alert(1)>
4. 注入在【JS 代码块内部】（输入直接放在<script>var a="输入"</script>里面）
";alert(1);//
"; 闭合 JS 字符串，终止原有语句，执行 alert，//注释剩下代码
场景：WAF/前端拦截alert关键词
方案 A：confirm / prompt替代
<img src=x onerror=confirm(1)>
方案 B：window 对象调用 alert
<img src=x onerror=window['alert'](1)>
方案 C：Unicode 编码绕过
<img src=x onerror=\\u0061\\u006c\\u0065\\u0072\\u0074(1)>
场景：站点拦截小括号，禁止函数传参
JS模板字符串，反引号调用函数，不需要括号
<img src=x onerror=alert`1`>
原理：JS 标签模板语法 alert1`` 等价于 alert('1')，没有 ()，完美绕过括号过滤。
靶场（Pikachu）到真实SRC的差距
Pikachu是“无菌环境”，真实SRC是“战场”。新手很容易拿着 <script>alert(1)</script> 去真实站点测，被WAF拦截后怀疑人生。
1. WAF拦截与过滤
• 靶场：无过滤，原样回显。
• 真实SRC：常规的 <script>、alert、onerror 大概率被WAF和前端黑名单拦截。你需要掌握：大小写混写、Unicode编码、HTML实体编码、使用冷门标签（如 <svg>、<details>、<iframe>）、利用JS模板字符串（反引号）、拆分关键字等绕过技巧。
2. 输出上下文差异
• 靶场：通常在标签之间直接输出。
• 真实SRC：可能在HTML属性内、<script>标签内的JS变量中、JSON响应中。不同的输出点需要完全不同的闭合方式。直接拿靶场Payload去打真实环境，大概率是语法错误页面崩溃。
3. 浏览器安全机制
• 靶场：无防护。
• 真实SRC：现代浏览器有 HttpOnly（Cookie偷不到）、SameSite（跨站POST不自动带Cookie）、CSP（内容安全策略）（内联脚本直接禁止执行）。CSP存在的情况下，就算你注入了JS，浏览器也会拒绝执行。
4. SRC审核与危害证明
• 靶场：弹个窗就算通关。
• 真实SRC：只弹窗的XSS通常会被判为低危或忽略。你需要证明实际危害：
◦ 存储型XSS：证明能打到管理员后台（比如发一条留言，管理员一访问就触发）。
◦ 反射型XSS：构造出完整的利用链，比如利用XSS窃取用户Token、发起CSRF修改密码。
◦ DOM型XSS：必须证明恶意链接能稳定触发，且能执行任意JS（如document.cookie被HttpOnly挡住时，构造键盘记录或钓鱼弹窗）。
◦ SRC报告话术：“该漏洞可导致攻击者获取用户登录态，执行任意操作，建议定级中危/高危，修复方案如下……”
XSS修复建议（SRC报告结尾必备）
如果你在SRC提交漏洞，报告里附上修复建议，不仅会显得你专业，还能提高审核通过率和定级。
1. 首选方案：上下文输出编码（最核心）
不要试图过滤用户输入，而是根据数据输出的位置进行编码：
• HTML标签间：将 < > & " ' 转义为 HTML 实体（< > & " '）。
• HTML属性内：除上述字符外，还需对空格、换行等进行编码，确保闭合引号失效。
• JavaScript代码块内：使用JS Unicode编码或 JSON 序列化输出。
• URL参数：使用 encodeURIComponent() 进行URL编码。
2. DOM型XSS专项防御
• 避免使用 innerHTML、document.write、eval 等危险Sink。
• 优先使用安全的API：textContent、innerText、setAttribute。
• 如果必须插入HTML，使用第三方安全库如 DOMPurify 进行净化。
3. 内容安全策略（CSP）
• 配置 Content-Security-Policy 响应头，禁用 unsafe-inline 和 unsafe-eval。
• 例如：script-src 'self' https://trusted.cdn.com;
• CSP作为最后一道防线，即使XSS被注入，也能阻止恶意JS执行。
4. Cookie安全加固
• 为敏感Cookie设置 HttpOnly，禁止JS读取（防Cookie劫持）。
• 设置 SameSite=Lax 或 Strict，防止跨站POST型XSS自动携带Cookie。
5. 输入验证与过滤（辅助）
• 对输入格式进行严格的白名单校验（如手机号、邮箱格式）。
• 过滤 script、on* 等危险关键字（注意：这只是辅助，不能完全依赖，因为存在大量绕过）。
结语
Pikachu靶场完美适配本文全套XSS知识点，是SRC新手最优练习靶场，大家可以自己下去尝试一下pikachu中xss章节的其他关卡，靶场中除了xss和SQL注入以外还有许多漏洞类型还未涉及，接下来的博客中我会一一提到。
至此，我们完成了 Web安全三大基础核心：手工SQL注入 → 工具高阶注入 → XSS全体系学习（原理+靶场实操+绕过方案）
声明：本文所有内容仅用于本地靶场学习，未经授权不得对互联网任何真实网站进行渗透测试
