17370845950

XSS是JavaScript中最常被触发、最容易忽略且后果最直接的安全风险，防御核心是确保不可信数据不变成可执行代码，需按输出上下文（HTML/JS/URL）采用对应转义或净化方案。

JavaScript 安全风险里，XSS（跨站脚本攻击）不是“之一”，而是**最常被触发、最容易被忽略、后果最直接的那一个**。它不依赖服务器漏洞，只要前端把用户输入原样塞进页面，就可能中招——Cookie 被偷、会话被劫持、页面被篡改，全在几毫秒内发生。

为什么 innerHTML 是 XSS 的“快捷入口”？

因为 innerHTML 把字符串当 HTML 解析执行，而不是当纯文本显示。哪怕只是渲染一条用户评论、URL 参数里的 name、或者搜索框回显内容，只要没处理， 就能跑起来。

• ❌ 错误写法：

  element.innerHTML = '' + userInput + ''

• ✅ 正确写法（纯文本场景）：

  element.textContent = userInput

  —— 浏览器自动转义，连 都显示为文字
• ✅ 正确写法（必须渲染 HTML 的场景）：用 DOMPurify 净化，不是自己写正则过滤：

  import DOMPurify from 'dompurify';
  element.innerHTML = DOMPurify.sanitize(dirtyHTML);

不同上下文要用不同的转义方式

“转义”不是万能的，关键在匹配输出位置。把 URL 参数直接拼进 location.href，HTML 实体转义毫无用处；同理，在 JS 字符串里插用户数据，只做 HTML 转义也挡不住 ");alert(1)// 这类攻击。

• 插入 HTML 内容（如 innerHTML）→ 用 HTML 实体转义：& → &， → zuojiankuohaophpcn
• 插入 JS 字符串（如 var msg = "xxx"）→ 用 JavaScript 字符串转义：\、"、'、` 都要加反斜杠或 Unicode 编码
• 插入 URL 查询参数（如 location.search = '?q=' + userInput）→ 必须用 encodeURIComponent()，不能用 encodeURI()（后者不编码 / ? : @ & = + $ , #）

CSP 不是可选配置，而是最后一道保险

即使代码写得再小心，一个未更新的第三方库、一次 CDN 资源劫持，都可能绕过所有前端逻辑。这时候 Content-Security-Policy 就起作用了：它由服务端通过 HTTP 响应头下发，告诉浏览器“只允许从哪些来源加载脚本”。

• 基础策略示例（禁止内联脚本和 eval）：

  Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; object-src 'none'; base-uri 'self';

• 关键点：script-src 'self' 会阻止所有 标签和内联事件（如 onclick），但不会影响 textContent 或 setAttribute
• ⚠️ 注意：CSP 无法修复已存在的 DOM 型 XSS（比如 document.write(location.hash)），它只是让恶意脚本“加载不了”或“执行不了”

富文本场景最容易翻车，别信“白名单过滤”

很多团队以为只要允许

就安全了，结果攻击者用 、 或绕过正则的嵌套注释直接触发执行。

立即学习“Java免费学习笔记（深入）”；

• ❌ 自己写正则清洗 HTML → 极易被绕过，且维护成本高
• ❌ 用 innerHTML + 白名单字符串替换 → 属性顺序、大小写、编码变体都能绕过
• ✅ 唯一推荐方案：用 DOMPurify（经 OWASP 认证）并开启强制属性清理：

  DOMPurify.sanitize(dirty, { 
    ALLOWED_TAGS: ['p', 'strong', 'a'],
    ALLOWED_ATTR: ['href'],
    FORBID_CONTENTS: ['script', 'object', 'embed']
  });

XSS 防御的核心从来不是“怎么拦住攻击者”，而是“不让不可信数据变成可执行代码”。这要求你每写一行插入 DOM 的代码时，都下意识问一句：它现在是文本？还是 HTML？还是 JS 字符串？还是 URL？——上下文错了，再严格的过滤也白搭。