真实面经题目 · 原创解析
CSRF 是跨站请求伪造，核心是攻击者诱导已登录用户的浏览器向目标站点发起请求，浏览器会自动携带目标站点的 Cookie，从而让服务端误以为请求来自用户本人。常见攻击包括隐藏表单提交、img 或链接触发 GET 请求、跨站 POST 和配合不安全 CORS 的接口调用；防御重点是 SameSite Cookie、CSRF Token、Origin/Referer 校验、避免 GET 改状态和敏感操作二次确认。
CSRF 的前提是目标站点使用 Cookie 等自动携带的凭证维持登录态，攻击者不需要读到响应，只要能让用户浏览器发出带凭证的请求即可。例如用户登录了银行站点，随后访问恶意页面，恶意页面自动提交一个转账表单，浏览器会带上银行站点 Cookie，服务端如果只看 Cookie 就可能执行操作。攻击形式包括 GET 型链接或 img 请求、POST 表单自动提交、隐藏 iframe、利用简单请求绕过预检，以及在 CORS 配置错误时发起更复杂请求。防御要组合使用：Cookie 设置 SameSite=Lax 或 Strict；服务端要求不可预测的 CSRF Token；校验 Origin 或 Referer；状态变更接口不用 GET；敏感操作做二次验证；同时注意 XSS 会削弱 Token 防线。
CSRF 利用的是浏览器自动携带凭证的行为。Cookie 属于目标站点，但请求可以从其他站点被触发；只要请求地址指向目标站点，浏览器就会根据 Cookie 的域、路径、SameSite、Secure 等规则决定是否携带。攻击者通常无法读取目标站点响应，但很多状态变更操作并不需要攻击者读取响应，只要服务端执行即可造成影响。
一次典型 CSRF 需要几个条件：用户已经在目标站点登录；目标站点用自动发送的 Cookie 或类似凭证识别身份；目标接口只依赖凭证而缺少请求来源或一次性校验；攻击者能够构造一个浏览器会发送的请求。它和 XSS 的区别在于，CSRF 不要求在目标站点执行脚本，而是借用户浏览器的登录态跨站发请求。
GET 型 CSRF 可以通过链接、img、script 等资源请求触发，危险在于接口把状态修改放在 GET 上。POST 型 CSRF 常用自动提交表单，因为普通表单可以跨站提交 application/x-www-form-urlencoded、multipart/form-data 或 text/plain 这类简单请求。更复杂的 JSON 请求通常受 CORS 和预检约束，但如果服务端 CORS 配置过宽并允许凭证，也可能扩大风险。
CSRF Token 的思路是让服务端要求一个攻击者无法预测、无法从第三方站点自然提交的值。同步 Token 模式由服务端生成并嵌入页面或接口返回，提交状态变更请求时带回；双提交 Cookie 模式则让请求参数或 header 中的 token 与 Cookie 中的 token 匹配。Token 必须和用户会话绑定、具备足够随机性，并在服务端校验失败时拒绝操作。
SameSite Cookie 能从浏览器层减少跨站请求携带 Cookie 的机会，Lax 对大多数普通跨站子请求有效，Strict 更严格但可能影响正常跳转体验；Origin 和 Referer 校验能确认请求来源，但要处理缺失、代理和隐私策略。状态变更接口应使用非 GET 方法，并配合 Token。敏感操作还可以要求重新输入密码、短信、硬件验证或业务确认，降低单次请求伪造的危害。
XSS 是攻击者脚本在目标站点上下文执行，能读写页面内容和调用接口；CSRF 是攻击者诱导用户浏览器发起跨站请求，通常读不到响应。前者是脚本执行问题，后者是请求身份被滥用问题。
GET 会被链接、img、预加载、爬虫、浏览器缓存等机制自然触发。如果 GET 能转账、删除、关注或改配置，攻击者构造一个 URL 就可能造成状态变化。
不能。Lax 能拦截多数跨站子请求携带 Cookie，但某些顶级导航场景、兼容策略、老浏览器或业务必须设置 SameSite=None 的场景仍有风险。重要接口仍应配合 Token 和来源校验。
如果使用 Cookie 登录态，服务端可以下发 CSRF Token，前端在非简单请求 header 中带回，服务端同时校验 Origin。Cookie 设置合理的 SameSite、Secure、HttpOnly。若使用 Authorization header 且 token 不会自动跨站携带，CSRF 风险会下降，但仍要防 XSS 和错误 CORS 配置。
