【软件安全】什么是XSS(Cross-Site Scripting,跨站脚本)?

Concept: XSS(Cross-Site Scripting,跨站脚本)


1) 概念解释 / Concept (Plain English + 中文)

EN: XSS (Cross-Site Scripting) is a web vulnerability where an attacker injects untrusted JavaScript into a page so that it runs in other users' browsers. With the victim's session, the script can steal cookies/tokens, hijack accounts, deface UI, or pivot to further attacks .
CN: XSS(跨站脚本) 是一种网页漏洞:攻击者把不可信的 JavaScript 注入页面,让它在其他用户的浏览器中执行。脚本继承受害者会话权限,可窃取 Cookie/令牌、劫持账号、篡改界面或发起进一步攻击。


2) XSS 的三种主要类型 / Three Main Types

  • Stored XSS(存储型)
    EN: Payload is stored on the server (e.g., DB, comments) and served to every viewer.
    CN: 载荷被保存到服务器(如数据库/评论),每个访问者都会中招。

  • Reflected XSS(反射型)
    EN: Payload comes from the request (URL/param), is reflected in the response and runs once when the victim clicks the crafted link.
    CN: 载荷来自请求(URL/参数),被原样反射到响应中,用户点击恶意链接时触发一次。

  • DOM-based XSS(基于 DOM)
    EN: The page's client-side JS reads untrusted data (e.g., location.hash) and writes it into the DOM without proper escaping , executing arbitrary code.
    CN: 页面前端脚本 从不可信来源(如 location.hash)读入数据并直接写入 DOM,因未正确转义而执行任意代码。


3) 运行原理 / How XSS Works (Essentials)

  1. Unsanitized input reaches a dangerous sink (HTML/JS/URL/attribute).
  2. Browser interprets the injected content as code (not text).
  3. Malicious code runs in the origin of the site (same cookies/session/storage).

常见危险输出场景 / Sinks:

  • HTML 内容上下文 :<div>UNTRUSTED</div>
  • HTML 属性上下文 :<img src="UNTRUSTED">、onclick="UNTRUSTED"
  • JS 字面量上下文 :var x = 'UNTRUSTED';
  • URL/链接上下文 :<a href="UNTRUSTED">
  • DOM API :innerHTML, document.write, insertAdjacentHTML 等

4) 影响与危害 / Impact

  • 读取/发送 Cookie、LocalStorage、CSRF Token
  • 伪造 UI、钓鱼框、键盘记录
  • 发起 CSRF-like 动作(在受害者会话下请求)
  • 作为内网渗透的跳板(对同源接口继续攻击)

5) 防御(四大主线,场景化) / Defenses (Four Pillars, Context-Aware)

  1. 输入验证(Input Validation):拒绝明显危险输入(黑名单不可靠,白名单/结构化校验更稳)。

  2. 上下文相关的输出编码(Output Encoding/Escaping):

    • HTML 文本 → HTML-escape (&lt; &gt; &amp; &quot;)
    • HTML 属性 → 属性编码
    • JS 字符串 → JS 字符串转义
    • URL → URL 编码
  3. 内容安全策略(CSP) :使用 Content-Security-Policy 限制脚本来源,禁止 unsafe-inline,结合 nonce/hash。

  4. 安全 Cookie 与框架自转义 :HttpOnly(阻 JS 读 Cookie)、SameSite,选用默认输出转义的模板/框架(如 React、Django 模板等),并避免 dangerouslySetInnerHTML / innerHTML 等直写。

小提示:XSS 防御="在合适的上下文做合适的编码"+"减少可执行脚本来源(CSP)"+"收紧会话凭据的可读性(HttpOnly)"。


6) 比喻 / Metaphor

EN: Think of your web page as a stage , and user input as props . Props must be checked and kept as props . If you mistakenly let props become scripts (actors giving commands), they can run the show.
CN: 把网页想成舞台 、用户输入是道具 。道具只能当道具,不能变剧本台词。一旦把道具当成脚本,演员就被"恶意台词"指挥了。


7) Multiple Choice(5 题选择,逐题解释对/错)

Q1. Which statement best defines XSS? / 哪个对 XSS 的定义最准确?

A. Server uploads malware to user's computer

B. Attacker injects SQL to read DB
C. Attacker injects JavaScript that runs in victim's browser ✅

D. Browser blocks all scripts by default

Why(对): XSS 的核心是浏览器执行攻击者注入的 JS 。
Why not(错): A=恶意软件投送;B=SQL 注入;D=不符合事实。


Q2. Stored vs Reflected XSS difference? / 存储与反射的差异?

A. Stored is in DB and affects many users; Reflected is from request & one-off ✅

B. Both require DB

C. Reflected persists in server

D. Stored only works with iframes

✅ A 正确
Why not: B/C/D 皆与定义不符或过度限定。


Q3. Which is MOST effective to stop DOM-based XSS? / 最能阻止 DOM 型 XSS 的是?

A. Only using HTTPS

B. Printing user input as is
C. Avoid innerHTML and use safe APIs; encode per context ✅

D. Disable CSS files

✅ C 正确 (避免危险 DOM sink,按上下文编码)
Why not: A=传输安全非 XSS 防线;B=最危险;D=无关。


Q4. Which header helps reduce XSS impact? / 哪个响应头能降低 XSS 影响?

A. Server:
B. Content-Security-Policy ✅

C. ETag

D. Accept-Encoding

✅ B 正确 (CSP 可限制脚本来源/内联执行)。
Why not: 其他与脚本执行无关。


A. Secure
B. HttpOnly ✅

C. Domain

D. Max-Age

✅ B 正确 (HttpOnly 禁止 JS 访问 Cookie)。
Why not: A=仅限 HTTPS 传输;C/D=域/寿命设置。


8) Short Answer(5 题简答,简洁好记)

S1. Explain DOM-based XSS in one or two lines. / 用一句话解释 DOM 型 XSS。

EN: Client-side JS reads untrusted data and writes it into the DOM as code.
CN: 前端脚本把不可信数据写进 DOM 当代码执行。


S2. Give one practical example of Reflected XSS. / 举一个反射型 XSS 的例子。

EN: A search page echoes ?q=<script>alert(1)</script> without encoding; clicking the crafted link executes alert.
CN: 搜索页直接回显 ?q=<script>alert(1)</script>,未编码即执行。


S3. Name four main XSS defenses. / 说出四个主要防御点。

EN: Input validation, context-aware output encoding , CSP, HttpOnly/SameSite cookies (plus safe frameworks).
CN: 输入验证、按上下文输出编码 、CSP、HttpOnly/SameSite(外加默认转义框架)。


S4. Why is context-aware encoding important? / 为何必须"按上下文编码"?

EN: The escaping rules differ in HTML text, attribute, JS string, and URL; wrong encoding leaves gaps.
CN: HTML/属性/JS/URL 的转义规则不同,用错就会留洞。


S5. How does CSP reduce XSS risk? / CSP 如何降低 XSS 风险?

EN: By allowing scripts only from trusted origins and blocking inline/eval; attackers' injected code can't load or execute.
CN: 限定可信脚本来源并禁止内联/eval,使注入脚本无法加载或执行。


9) 复盘速记 / Quick Recap

  • XSS = 让"输入"变"脚本":Stored(入库)、Reflected(回显)、DOM(前端拼装)。
  • 核心防线 :上下文编码 + 限制脚本执行(CSP) + 收紧会话读取(HttpOnly) + 减少危险 sink。
  • 调试方向:找"输入→输出"路径、定位 DOM sink、核对编码点与 CSP 生效情况。
相关推荐
回眸&啤酒鸭8 分钟前
【回眸】OpenSwarm 多智能体协作系统实战指南
大数据·前端·人工智能
用户693717500138417 分钟前
2026,程序员的时代拐点到了
android·前端·后端
大龄秃头程序员20 分钟前
一次 iBeacon + BLE 无感解锁方案的实现记录
前端
浮链序28 分钟前
怎么证明"你这个模型是偷我的"——把蒸馏变成取证工具
算法·安全·llm
小兔子35 分钟前
Python 的 GIL 与 free-threading:3.13 之后「去 GIL」走到哪一步了
前端
IT_陈寒41 分钟前
SpringBoot自动配置差点让我加班到凌晨
前端·人工智能·后端
袁哥大话安全2 小时前
巡隐WEBSHELL扫描软件
人工智能·安全·web
guslegend2 小时前
脚手架原理与本地调试:从 bin 软链接到 npm link
前端·npm·node.js·脚手架·前端工程化
小宋10212 小时前
A2UI从零实战:Agent安全生成交互界面与事件回传
javascript·人工智能·安全·交互
草根大哥2 小时前
04-推拉流安全:签名、Token 与防盗链
安全·成本·延迟·自建cdn·ppcdn