H5漏洞如何排查修复

本文目录导读：

1. 核心排查思路（自检清单）
2. 常见H5漏洞类型及修复方案
3. 自动排查工具（推荐）
4. 一个快速应急流程（适用于已经疑似被攻击）
5. 总结建议

关于H5（HTML5）漏洞的排查与修复，实际上是一个涵盖前端代码安全、业务逻辑安全以及第三方依赖安全的综合工程，作为AI，我无法直接扫描你的代码，但可以为你提供一套标准的、可操作的排查思路和修复方案。

核心排查思路（自检清单）

H5最常见的漏洞主要集中在以下几个方面,请按照以下顺序逐项检查你的代码或应用：

1. 数据入口检查（输入验证）

   • URL参数：location.search、location.hash 中的值是否直接用于DOM操作或请求发送。
   • 表单输入：<input>、<textarea>、<select> 的内容是否未经转义直接渲染。
   • 本地存储：localStorage、sessionStorage、IndexedDB 中的数据是否可信？是否被恶意修改？
   • 第三方数据源：WebSocket、postMessage 接收的数据是否进行了来源和内容校验？

2. 输出点检查（数据展示）

   • 直接HTML赋值：使用 innerHTML、outerHTML、document.write()、v-html（Vue）、dangerouslySetInnerHTML（React）的地方。
   • 动态执行JS：eval()、setTimeout/Interval（字符串形式）、new Function()
   • CSS注入：style 属性拼接、cssText 赋值。

3. 通信与存储检查

   • HTTPS协议：所有页面请求、API接口、WebSocket是否强制使用HTTPS？
   • Cookie安全：HttpOnly、Secure、SameSite 属性是否设置正确？
   • 本地存储敏感数据：是否存在密码、Token、身份证号等明文存储在 localStorage 中？

4. 第三方依赖检查

   • 使用的npm包、CDN库（如jQuery, Vue, React, lodash）是否有已知漏洞？版本是否过旧？
   • 使用了哪些外部统计、广告、埋点脚本？它们是否安全可信？

常见H5漏洞类型及修复方案

跨站脚本攻击（XSS）—— 最常见，危害最高

• 场景：用户评论、搜索框、URL参数中的恶意脚本被执行。
• 修复方案：
  • 首选方案：内容安全策略（CSP）
    • 在HTTP响应头或HTML的 <meta> 标签中设置CSP。
    • 示例：Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; 这将禁止内联脚本和未知来源的脚本。
  • 根本方案：输出编码
    • HTML上下文：使用库（如DOMPurify）或框架自带功能对 < > & " ' 进行HTML实体编码。
    • URL上下文：使用 encodeURIComponent() 对URL参数编码。
    • JS上下文：避免使用 innerHTML，改用 textContent；避免字符串拼接生成HTML。
  • 工具：DOMPurify（前端），后端输出前同样需要过滤。

跨站点请求伪造（CSRF）

• 场景：攻击者诱导用户点击链接，利用用户已登录的浏览器自动发起恶意请求（如转账、改密码）。
• 修复方案：
  • 验证Referer/Origin头：检查请求来源的域名。
  • 使用CSRF Token：每次请求添加后端生成的随机Token，后端验证。
  • SameSite Cookie：设置 Set-Cookie: ...; SameSite=Lax 或 SameSite=Strict，现代浏览器（Chrome 80+）默认对Cookies启用SameSite=Lax，这是最简便的防御措施。

点击劫持（Clickjacking）

• 场景：攻击者通过iframe嵌套你的页面，骗取用户点击。
• 修复方案：
  • 设置X-Frame-Options头：X-Frame-Options: DENY 或 X-Frame-Options: SAMEORIGIN，禁止或限制页面被iframe加载。
  • 使用CSP的frame-ancestors指令：Content-Security-Policy: frame-ancestors 'self'; 禁止被非同源网站iframe。

不安全的重定向与转发

• 场景：URL参数 redirect_url=attacker.com 未校验，导致跳转到钓鱼网站。
• 修复方案：
  • 白名单验证：只允许重定向到你自己的域名列表。
  • 参数化跳转：不要直接拼接URL，使用后端接口指定跳转目标。

本地存储泄露（LocalStorage/SessionStorage）

• 场景：将敏感信息（Token、用户资料）存储在客户端，被XSS窃取。
• 修复方案：
  • 永远不要存储HTTP-Only Cookie（这是正确的做法）。
  • 使用更安全的存储方式：
    • 使用 Web Worker 隔离数据访问。
    • 使用 IndexedDB 并加上访问控制（但依然易被XSS窃取）。
  • 根本方案：不要在客户端存储不可信或可推导出敏感操作的数据，Token应放在HttpOnly Cookie中，JWT应使用短期有效并绑定IP/User-Agent。

自动排查工具（推荐）

手动排查耗时且易遗漏,建议结合以下工具：

1. 浏览器开发者工具：
   • Application -> Local Storage / Session Storage / Cookies：查看存储了哪些敏感信息。
   • Network -> 查看请求Headers：检查Cookie的HttpOnly、Secure、SameSite属性。
2. 安全扫描工具：
   • OWASP ZAP（免费开源，适合深度扫描）：可模拟XSS、SQL注入、CSRF等攻击。
   • Burp Suite（专业版付费）：功能更强大，但学习成本高。
   • Snyk（用于npm依赖检测）：检查项目中过期的、带漏洞的npm包。
3. 静态代码分析工具：
   • ESLint 安全插件（如 eslint-plugin-security）：检测代码中的危险模式（如 eval、innerHTML）。
   • SonarQube：企业级代码质量与安全扫描。

一个快速应急流程（适用于已经疑似被攻击）

1. 立即隔离：紧急下线有问题的页面或功能；修改API密钥、Token；通知用户重置密码。
2. 定位证据：从服务器日志、错误监控（Sentry等）中查找异常请求（如包含 <script> 的请求）。
3. 修补漏洞：根据上述排查清单，对最可疑的输入输出点进行转义或过滤。
4. 加强防御：立刻启用CSP头部（可以先设置 report-only 模式，收集误报后再正式启用）。
5. 审计第三方：检查所有外部引入的JS、CSS、iframe是否有恶意篡改。

总结建议

• 深信不疑：永远不相信任何来自用户浏览器侧的数据（包括URL、表单、Cookie、LocalStorage）。
• 最小权限：代码中尽量使用 textContent 替代 innerHTML，使用 setAttribute 替代直接操作style。
• 分层防御：前端过滤（提升用户体验）+ 后端过滤（安全底线），CSP是前端的最后一道防线，必须开启。
• 持续监控：建立前端错误监控（如Sentry）和日志分析机制，及时发现异常。

如果你能提供具体的代码片段（如某个表单提交、URL处理逻辑），我可以给出更具针对性的修复建议。