XSS 为什么属于当前站点？
不可信内容被浏览器当作活动内容执行时，可能在页面所属的权限环境里运行。数据是从服务器返回还是在前端组合，都需要检查。[1]
098 / Web 与应用 / XSS
你想显示文字，浏览器看到了什么？
XSS 跨站脚本 · XSS
同样一段输入，放进正文、属性、链接或富文本，经过的解析规则并不一样。先确定输出位置，再选对处理方式。
开始探索 ↓7–10 分钟
动手实验 · 场景判断 · 实用检查
动手实验 · 场景判断 · 实用检查
恶意角色随留言进入页面，表现不可信内容变成活动代码的风险。图里的饼干是会话隐喻；HttpOnly 也不能消除所有 XSS 后果。
展开读图提示
读图提示
- 角色与机制
- 评论比喻不可信内容，飞出页面的小怪比喻在受害者浏览器中执行的恶意脚本。
- 风险在哪里
- 当内容被当作可执行代码解析，脚本就可能以该站点的上下文读取数据或代用户操作；并非所有 Cookie 都能被脚本读取。
- 防护与边界
- 按输出上下文编码，避免危险 DOM API；确需 HTML 时用可靠净化器，配合 CSP 与 HttpOnly Cookie 降低后果。
本课任务 / XSS 跨站脚本
区分显示数据与解释标记，按输出上下文保护浏览器边界。
- 比较四种输出位置
- 选用安全写入方式或相应处理
- 解释编码、净化与 CSP 的区别
亲手探索 / 不同条件，不同结果
先选输出位置，再检验你的防护方式。
检查正文、普通属性、URL 与预期富文本的处理策略。所有样本只作为文字展示，不会插入可执行 HTML；结果是上下文教学判断。
输出位置检查台
同一段内容，放在哪里，决定怎样处理
为读书会留言选择输出位置与处理策略，检查防护是否匹配业务需要。样本、模板与输出全是不可执行的文字。
尚未运行。先调整条件，再查看本地教学模型的结果。
再试一次：保留事件属性样本，把“只过滤 script”改为安全文本接收点；再选择富文本和净化。最后，把输出位置改为链接地址，看看为什么还需要协议校验。
随手查 / 把理解带回实际工作
理解机制之后，检查这些细节。
实验是简化模型。真实环境需要明确业务规则、验证失败路径，并持续维护配置与证据。
01 / 实用细节
普通文字使用安全文本入口
只想显示文字时，使用框架默认的文本渲染或 textContent 等适合的安全写入方式。不要为了方便把字符串送进 HTML 解析入口。[1][2]
02 / 实用细节
属性名称本身要受控制
固定且合适的普通属性与事件处理属性不是一回事。使用安全的属性名、正确引号和相应处理；不要让用户决定要写入哪个属性。[1]
03 / 实用细节
链接还需要协议与目标策略
把引号编码正确不代表链接目标安全。解析并限制允许的协议和目标，根据产品需求排除危险导航；编码并不等于 URL 验证。[1]
04 / 实用细节
需要富文本时使用成熟净化器
当产品确实要允许部分 HTML，选择维护中的净化方案与明确策略。净化后的内容若再被不安全地修改，可能重新引入危险；组件与库需持续更新。[1][2]
05 / 实用细节
避免把不可信值放进代码
动态脚本、事件处理器和其他危险上下文应优先重新设计，不能指望把一种 HTML 编码重复套用，就安全地进入所有解析器。[1]
06 / 实用细节
CSP 是额外防线
内容安全策略可限制部分执行路径，但配置缺口与浏览器差异需要验证。它应配合安全输出和净化，不能成为允许任意 HTML 注入的理由。[3]
从模拟，到验证
找一个获准的环境，实际检查一次。
勾选用于本页自查，不会自动标记整课已学会。练习与清单刷新后重置。
本页已检查 0 / 5 项
展示用户评论时，哪种方式更可靠？
能解释原因，再标记学会。
小测结果同步错题本；“已学会”沿用原有本地学习记录。
资料与依据
- OWASP · XSS Prevention ↗
上下文编码、安全入口、富文本净化与危险上下文
- MDN · Element.innerHTML ↗
HTML 解析入口与注入风险
- OWASP · Content Security Policy ↗
纵深防御与策略局限
本页场景、人物与数据均为教学示例。互动选择不会上传；收藏、已学会与错题沿用当前浏览器本地存储。来源正文核对日期：2026-10-08。