XSS 攻击原理与防护

前端Web攻击2026-01-29 01:11

举个简单例子

假设网站有一个评论功能，用户提交：


<script>alert('你被黑了')</script>

如果后台没有过滤就直接输出到页面：


<div>用户评论：<script>alert('你被黑了')</script></div>

访问这个页面的人，浏览器就会执行这段脚本。

XSS 攻击能干什么？

窃取用户 Cookie，然后伪造登录、执行任意 JS，跳转恶意网站、篡改页面、钓鱼欺诈，伪装成登录框、传播蠕虫，自动发帖等

XSS 的常见攻击场景分类

类型	说明	示例
存储型 XSS	恶意代码被写入数据库，从后端返回到用户页面	评论区注入 `<script>alert(1)</script>`
反射型 XSS	恶意代码通过 URL 直接反射到页面	URL 中加上 `?q=<script>`，被页面直接渲染
DOM 型 XSS	前端 JS 代码操作 DOM 时插入了不安全内容	`element.innerHTML = location.hash`
第三方资源 XSS	引入了未验证的 JS/CSS 文件	引入外部脚本后被污染执行

如何防御 XSS

场景	对策
前端直接插入 HTML	用 DOMPurify 清洗后再用 `dangerouslySetInnerHTML`
后端输出 HTML 页面（服务端渲染）	用模板引擎自动转义变量，EJS、Jinja2 等默认会 `< > &` 转义
富文本内容提交存储	前端不清洗，后端统一处理
展示 HTML 内容	插入前清洗 + CSP 防护
URL 参数参与页面渲染	永远不要拼接进 HTML，必须转义或 encode，如 `encodeURIComponent()`
innerHTML / insertAdjacentHTML	内容必须清洗
上传的 SVG 文件	后端解析/屏蔽 script 标签
引入第三方脚本	加上 Subresource Integrity (SRI) + CDN whitelist
CSP（内容安全策略）	设置 HTTP Header 限制 script 执行
iframe 中展示外部 HTML	加 `sandbox` 属性，`<iframe sandbox srcDoc="...">`

CSP（内容安全策略）

告诉浏览器哪些内容可以加载、哪些不能加载，防止 XSS 攻击。可以配置在网页 meta 标签里面，也可以配置在 Nginx 里面。


<meta http-equiv="Content-Security-Policy"
  content="
    default-src 'self';
    script-src 'self' https://*.nr-data.net;
    connect-src 'self' https://*.nr-data.net;
    img-src 'self' https://*.nr-data.net;
  ">


add_header Content-Security-Policy "
  default-src 'self';
  script-src 'self' https://*.nr-data.net;
  connect-src 'self' https://*.nr-data.net;
  img-src 'self' https://*.nr-data.net;
";