frontend-interview-playbook

Appearance

XSS 与 CSRF：脚本注入和跨站请求伪造的边界 ​

问题背景 ​

这两个攻击常被并列提及，但一个针对页面执行上下文，一个针对用户身份上下文。

  • 这两个攻击常被并列提及，但一个针对页面执行上下文，一个针对用户身份上下文
  • XSS 关注攻击者把恶意脚本带入可信页面执行；CSRF 关注浏览器在用户已登录状态下被诱导发起跨站请求
  • 理解差异要从浏览器自动附带凭证和 DOM 执行环境两条线看
  • 存储在 localStorage 的 Token 不能自动被第三方站点带上，因此不易受传统 CSRF 影响，但更容易在 XSS 中被读取
  • XSS 的根源是把不可信输入当作可执行 HTML / JS / URL 使用，例如 innerHTML、危险模板、事件属性注入

指标、症状与判断信号 ​

  • 这两个攻击常被并列提及，但一个针对页面执行上下文，一个针对用户身份上下文
  • XSS 关注攻击者把恶意脚本带入可信页面执行；CSRF 关注浏览器在用户已登录状态下被诱导发起跨站请求
  • 理解差异要从浏览器自动附带凭证和 DOM 执行环境两条线看
  • 存储在 localStorage 的 Token 不能自动被第三方站点带上，因此不易受传统 CSRF 影响，但更容易在 XSS 中被读取
  • XSS 的根源是把不可信输入当作可执行 HTML / JS / URL 使用，例如 innerHTML、危险模板、事件属性注入

常见方案空间 ​

  • 真正拉开差距的部分通常在 稳定性治理、发布和回滚机制，因为这里最能体现规模、约束和经验判断
  • 有过线上问题或性能治理经历时，补充你如何定位 凭证存储、CSP 和运行时隔离、如何验证假设，以及如何收敛风险
  • 偏设计题需要补充未选方案的放弃原因，以及 稳定性治理、发布和回滚机制 最终如何影响方案落地
  • 这类问题更适合讲方案空间，而不是讲单点工具
  • 治理题最好按“发现问题 -> 定位归因 -> 实施动作 -> 验证结果 -> 持续追踪”的顺序去讲
  • 越偏线上治理，越要说明发布、回滚、灰度、告警和版本信息如何联动

取舍、闭环与治理代价 ​

  • 当你在项目里讨论“XSS 与 CSRF：脚本注入和跨站请求伪造的边界”时，通常不是只回答一个定义，而是要把 XSS、CSRF 和输入信任边界 讲清楚
  • XSS 与 CSRF：脚本注入和跨站请求伪造的边界 与“认证与存储：Cookie、Token、SessionStorage、LocalStorage 的安全边界”的关系和边界
  • XSS 与 CSRF：脚本注入和跨站请求伪造的边界 与“CSP 与沙箱：前端脚本执行边界如何收紧”的关系和边界
  • 把 XSS、CSRF 和输入信任边界 代入这个问题时，哪些前提必须先讲清楚
  • 可以结合你做过的系统说明 XSS 与 CSRF：脚本注入和跨站请求伪造的边界 在真实业务中的出现位置，例如它影响了哪条核心链路、哪类数据或哪种交互

落地路径与协作方式 ​

  • 治理题最好按“发现问题 -> 定位归因 -> 实施动作 -> 验证结果 -> 持续追踪”的顺序去讲
  • 跨团队协作时要补充责任边界、数据口径和回归标准
  • 越偏线上治理，越要说明发布、回滚、灰度、告警和版本信息如何联动

问答设计及延伸 ​

标准回答 ​

回答 XSS 与 CSRF：脚本注入和跨站请求伪造的边界 时，先定义要治理的症状，再给出方案空间和取舍依据，最后交代闭环如何落地以及结果如何验证。

追问拆解 ​

  • XSS 与 CSRF：脚本注入和跨站请求伪造的边界 与“认证与存储：Cookie、Token、SessionStorage、LocalStorage 的安全边界”分别落在治理闭环的哪一步
  • XSS 与 CSRF：脚本注入和跨站请求伪造的边界 与“CSP 与沙箱：前端脚本执行边界如何收紧”分别落在治理闭环的哪一步
  • 预算和人力受限时的保序优先级
  • 数据与用户感知冲突时的判定口径

容易失分的点 ​

  • 只报工具名，不讲问题背景和指标口径
  • 只讲发现问题，不讲如何验证和收敛
  • 把治理说成一次性动作，而不是持续机制

相关主题 ​