XSS 和 CSRF 是什么？怎么防御？

详细解析#

XSS 的三种类型#

XSS 的危害：窃取 Cookie 或 Token；以用户身份发请求、执行操作；篡改页面，比如伪造登录框骗取密码。

XSS 的防御#

• 按输出位置转义：输出到 HTML 内容中，转义 <、>、& 等字符；输出到 HTML 属性中，还要转义引号；放进 JS 代码或 URL 中的数据，按各自的规则编码（如 URL 参数用 encodeURIComponent）
• 不用 HTML 方式渲染不可信内容：避免 innerHTML、v-html、dangerouslySetInnerHTML；确实要渲染富文本时，先用 DOMPurify 等库过滤
• 校验 URL 协议：用户提供的链接只允许 http:、https:，防止 javascript: 链接
• CSP：通过 Content-Security-Policy 响应头限制脚本来源。例如 script-src 'self' 只允许加载同源脚本，内联脚本和 eval 都会被禁止，注入的内联脚本也就无法执行
• HttpOnly：敏感 Cookie 设置 HttpOnly，脚本读不到

const el = document.getElementById('greeting')
const userName = new URLSearchParams(location.search).get('name')

// ❌ 当作 HTML 插入：?name=<img src=x onerror=alert(1)> 会执行脚本
el.innerHTML = `你好，${userName}`

// ✅ 当作纯文本插入，标签会原样显示出来
el.textContent = `你好，${userName}`

// ✅ 用户提供的链接只允许 http 和 https 协议
function safeUrl(input) {
  try {
    const url = new URL(input, location.origin)
    return ['http:', 'https:'].includes(url.protocol) ? url.href : 'about:blank'
  } catch {
    return 'about:blank'
  }
}

CSRF 的过程#

1. 用户登录了 bank.com，浏览器保存了它的 Cookie
2. 用户被诱导打开 evil.com，页面里藏着一个自动提交的表单，目标是 bank.com 的转账接口
3. 如果 Cookie 没有 SameSite 限制，浏览器向 bank.com 发请求时会自动带上它，服务端以为是用户本人在操作

<!-- evil.com 上的页面：一打开就自动提交 -->
<form action="https://bank.com/transfer" method="POST">
  <input type="hidden" name="to" value="attacker">
  <input type="hidden" name="amount" value="10000">
</form>
<script>document.forms[0].submit()</script>

攻击者全程拿不到 Cookie，也看不到响应，只是"借用"了用户的身份。

CSRF 的防御#

• SameSite Cookie：
  • Strict：跨站请求一律不带 Cookie
  • Lax：只在跨站的顶级导航 GET 请求中携带，比如从其他网站点链接跳过来
  • None：允许跨站携带，但必须同时设置 Secure
  • Chrome 对没有设置 SameSite 的 Cookie 默认按 Lax 处理
• CSRF Token：服务端生成随机 Token 下发给页面，提交时放在表单字段或请求头里带回，由服务端校验。攻击者的页面受同源策略限制，读不到这个 Token
• 校验来源：服务端检查 Origin 或 Referer 请求头，拒绝来自其他站点的请求
• 关键操作二次确认：转账、改密码等操作要求输入密码或验证码
• 有副作用的操作不用 GET：Lax 仍然允许跨站的 GET 跳转携带 Cookie，一个链接就能触发攻击

对比#

面试官可能追问#

易错点#

• HttpOnly 只能防止 Cookie 被脚本读走，挡不住 XSS 脚本直接在页面里以用户身份发请求
• SameSite 防的是跨站请求，同一站点下的不同子域名之间不受限制；如果某个子域名存在 XSS，SameSite 挡不住
• 页面存在 XSS 时，CSRF Token 也会失效，因为脚本可以直接从页面里读到 Token