1. CSRF 的原理是什么？

CSRF（跨站请求伪造）是一种利用用户已登录的会话身份，诱使其在目标网站执行非预期操作的攻击方式。其核心机制是：

• 用户登录受信任网站 A 并生成会话 Cookie。

• 用户未退出 A 的情况下，访问恶意网站 B。

• B 向 A 发送伪装请求（如转账、修改密码），浏览器自动携带 A 的 Cookie。

• A 服务器基于 Cookie 误认为是用户合法操作，执行请求。

关键点：攻击者不直接获取 Cookie，而是利用浏览器自动发送 Cookie 的特性。

2. CSRF 的危害有哪些？

1. 账户安全威胁

   • 以用户身份修改账户信息（如密码、绑定手机、邮箱），导致账户被劫持。

   • 冒充用户发起资金操作（如转账、消费、充值），造成财产损失。

   • 伪造用户发布内容（如恶意言论、垃圾信息），损害用户名誉或网站秩序。

2. 数据与隐私风险

   • 诱导用户执行数据导出、分享等操作，导致个人隐私（如聊天记录、通讯录）或敏感信息（如企业内部文档）泄露。

   • 篡改用户授权设置（如开放第三方应用权限），让攻击者间接获取更多数据访问权。

3. 企业级危害

   • 若被攻击的是管理员账户，可能导致整站配置被篡改（如修改网站内容、关闭安全防护）、数据库被恶意操作（如删除数据、植入恶意内容）。

   • 批量攻击普通用户可能引发信任危机，影响网站声誉（如社交平台被用于传播诈骗信息）。

4. 间接扩大攻击范围

   • 利用用户在多个网站的关联账号（如 OAuth 授权），通过 CSRF 攻击蔓延至其他平台，形成连锁危害。

3. CSRF 的利用方式、攻击流程及常见手段有哪些？

• 利用方式：

  • GET 请求：通过图片、链接等触发（如 <img src="http://bank.com/transfer?to=attacker">）。

  • POST 请求：通过隐藏表单自动提交（如恶意网站内嵌指向目标网站的表单）。

  • AJAX 请求：需突破 CORS 限制（如利用 CORS 配置漏洞）。

• 攻击流程：

  1. 攻击者构造恶意请求。

  2. 诱使用户在已登录状态下访问含恶意请求的页面。

  3. 浏览器自动携带 Cookie 发送请求到目标网站。

  4. 目标网站执行请求。

• 常见手段：钓鱼邮件、社交媒体链接、恶意广告、伪装成合法网站的恶意页面等。

4. CSRF 的触发方式有哪些？

• 自动触发：通过 <img>、<script>、<iframe> 等标签自动发送请求。

• 用户交互触发：诱导用户点击按钮或链接（如伪装成 “领取奖品” 的表单提交）。

• 跨域表单提交：HTML 表单默认允许跨域 POST 请求（需配合 CSRF 漏洞）。

5. CSRF 攻击的必要条件及局限性是什么？

（一）攻击成功的关键条件

1. 用户登录态：受害者在目标站点处于登录状态，Cookie 未过期。

2. 请求可伪造：目标站点存在可被利用的功能接口（如转账、修改信息）。

3. 来源未验证：服务器未校验请求来源（如 Referer、Token）。

（二）局限性（前提条件）

1. Referer 限制：若目标站点检查 Referer，需浏览器支持 Referer 欺骗。

2. 参数复杂性：攻击者需知晓请求参数的正确值（如转账金额、账户 ID）。

3. 用户交互：需诱使受害者主动访问恶意页面。

6. CSRF 和 XSS、XXE 的区别是什么？

7. CSRF 与 SSRF 的区别是什么？

8. 如何测试一个网站是否存在 CSRF 漏洞？

• 手工测试：

  1. 识别敏感操作（如修改密码、转账）。

  2. 构造不含 Token 的请求（或修改 Token 值），验证是否可执行。

  3. 检查响应头是否设置 SameSite 属性。

• 自动化工具：

  • Burp Suite：使用 CSRF POC 生成器验证。

  • OWASP ZAP：扫描 CSRF 漏洞。

• 验证关键点：

  • 请求是否依赖 Cookie 认证。

  • 是否使用 Token 或 Referer 校验。

  • SameSite 属性是否正确配置。

9. CSRF 的防护措施有哪些？（含 5 大核心策略）

1. 同源验证（Origin/Referer 校验）：

   • 检查请求的来源域名是否与目标网站一致。

   • 局限性：Referer 可被伪造，且部分浏览器因隐私策略可能不发送 Referer。

2. CSRF Token：

   • 在表单或请求中嵌入随机 Token，服务器验证 Token 的有效性。

   • 特点：需与用户会话绑定，不可通过 Cookie 传递（防第三方读取）。

3. SameSite Cookie 属性：

   • Strict：完全禁止第三方请求携带本站 Cookie。

   • Lax：允许部分安全的跨站请求（如 GET 请求）。

   • None：需配合 Secure 属性，允许跨站请求（需 HTTPS）。

4. 双重 Cookie 验证：

   • 将用户会话 ID 同时存入 Cookie 和请求参数，服务器比对两者是否一致。

5. 验证码：

   • 关键操作强制用户交互（如登录、支付），阻断自动化 CSRF 攻击。

10. Cookie 的 HttpOnly、Secure、SameSite 参数作用是什么？

• HttpOnly：禁止 JavaScript 通过 document.cookie 访问 Cookie，防止 XSS 攻击窃取 Cookie（如会话 ID）。

• Secure：仅允许 Cookie 在 HTTPS 连接中传输，避免 HTTP 明文传输时被截获。

• SameSite：限制跨站请求携带 Cookie，防止 CSRF 攻击，分为：

  • Strict：完全禁止跨站请求携带 Cookie（如从 a.com 跳转到 b.com 时，b.com 的 Cookie 不被携带）。

  • Lax：仅允许部分跨站请求携带 Cookie（如 GET 方法的链接跳转、表单提交），限制 POST 等危险请求。

  • None：允许跨站请求携带 Cookie，但必须同时设置 Secure（仅 HTTPS 可用）。

11. Token 是如何防止 CSRF 的？

CSRF 漏洞的核心是攻击者利用用户的 “合法身份凭证”（如 Cookie）在用户不知情的情况下发起恶意请求。Token 防止 CSRF 的原理是：

• 服务器在用户会话中生成随机 Token（如 CSRF Token），并嵌入到前端表单或请求头中。

• 当用户发起请求时，前端需携带该 Token 提交给服务器。

• 服务器验证请求中的 Token 与用户会话中存储的 Token 是否一致：若一致则为合法请求；若不一致（攻击者无法获取用户的 Token，因此无法构造有效请求），则拒绝请求。

• 由于 Token 与用户会话强绑定且随机性高，攻击者无法伪造，从而阻断 CSRF 攻击。

12. CSRF Token 能否通过 Cookie 传递？为什么？

不能：

• 若 Token 存储在 Cookie 中，第三方网站可通过脚本读取（若存在 XSS 漏洞）。

• Token 需通过表单或 HTTP 头（如 X-CSRF-Token）传输，与用户会话绑定。

13. Token 测试要点有哪些？

• 生成逻辑：是否随机（无规律、不可预测），是否与用户身份强绑定（如关联用户 ID）。

• 传输安全：是否通过 HTTPS 传输（避免明文泄露），是否在 URL 中暴露（URL 可能被日志记录，增加泄露风险）。

• 验证严格性：

  • 是否验证签名（如 JWT 未验证签名则可伪造）；

  • 是否检查时效性（如过期 Token 是否被拒绝）；

  • 是否校验权限（如 Token 对应的用户是否有权限执行请求操作）。

• 复用性：是否允许重复使用（如一次性 Token 需用完即失效，避免重放攻击）。

• 销毁机制：用户注销或会话过期后，Token 是否立即失效（如从服务器黑名单中移除）。

• 泄露风险：是否在前端日志、本地存储（如 localStorage）中明文存储，是否可被 XSS 窃取。

14. Token 和 Referer 做横向对比，谁的安全等级高？

Token 的安全等级更高，原因如下：

• 作用场景：Token 是服务器生成的用于身份验证或防 CSRF 的凭证（如 JWT、CSRF Token），需通过严格验证（签名、时效性等）；Referer 是 HTTP 头字段，仅标识请求来源，用于简单的来源校验。

• 可靠性：Referer 可被篡改（部分浏览器允许通过特定方式修改，如旧版浏览器或特殊协议），且可能被浏览器省略（如 HTTPS 跳转 HTTP 时），无法作为核心安全依赖；Token 由服务器控制生成与验证逻辑，随机性强、验证严格，篡改或伪造难度极高。

• 局限性：Referer 仅能验证 “来源”，无法验证请求的合法性；Token 可直接关联用户身份或请求权限，安全性更全面。

15. 对 Referer 的验证，从什么角度去做？如何杜绝问题？

验证角度

• 来源域名校验：检查 Referer 是否属于可信域名（如自身域名或白名单域名），避免跨站请求。

• 路径合法性校验：验证 Referer 中的路径是否为可信路径（如 /login、/pay 等业务路径），防止恶意来源。

• 空 Referer 处理：部分场景下 Referer 可能为空（如直接输入 URL、HTTPS 跳转 HTTP），需明确是否允许空 Referer（通常仅允许可信场景，如首页访问）。

杜绝问题的措施

• 不依赖 Referer 作为唯一安全机制：Referer 可被篡改或省略，需结合 Token（如 CSRF Token）作为核心防护，Referer 仅作为辅助校验。

• 严格白名单校验：对 Referer 域名进行精确匹配（避免模糊匹配，如 *.example.com 可能被 example.com.attacker.com 绕过），且仅允许必要的可信域名。

• 处理边缘场景：明确规定空 Referer 的允许范围（如仅允许静态资源请求），对非预期的空 Referer 直接拒绝。

16. 如何绕过常见的 CSRF 防御措施？

• 绕过 Referer 校验：

  • 诱导用户从合法域名跳转（如通过短链接服务）。

  • 利用浏览器配置（如 Firefox 隐私模式下不发送 Referer）。

• 绕过 Token 验证：

  • 寻找 XSS 漏洞直接获取 Token。

  • 利用逻辑漏洞（如 Token 生成不随机或可预测）。

• 绕过 SameSite：

  • 若设置为 Lax，可利用 GET 请求攻击部分场景。

17. 如何绕过 Http-only？

HttpOnly 限制 JavaScript 访问 Cookie，但可通过其他漏洞组合绕过，常见方式：

• 本地文件包含（LFI）：若服务器存在 LFI 漏洞，攻击者可读取服务器上存储的会话文件（如 PHP 的 session.save_path 中的文件），获取包含 Cookie 的会话数据。

• 跨站脚本（XSS）+ 其他协议：利用旧版浏览器或插件漏洞（如 Flash 的 LocalConnection），通过非 JavaScript 方式读取 Cookie（现代浏览器已修复此类漏洞）。

• 中间人攻击（MITM）：若 Cookie 未设置 Secure，攻击者可通过 HTTP 中间人攻击截获传输中的 Cookie（与 HttpOnly 无关，但可间接获取）。

注意：现代浏览器对 HttpOnly 的保护机制较完善，纯前端绕过几乎不可能，需依赖服务器端其他漏洞。

18. CSRF 注入构造 payload 可以用什么方法？

• 构造隐藏表单：

  <form action="http://bank.com/transfer" method="POST">  
    <input type="hidden" name="to" value="attacker">  
    <input type="hidden" name="amount" value="1000">  
  </form>  
  <script>document.forms[0].submit();</script>  

• 利用图片 / 链接触发 GET 请求：

  <img src="http://bank.com/transfer?to=attacker&amount=1000">  

• 跨域表单提交：

  <form action="http://vulnerable-site.com/delete" method="POST">  
    <input type="hidden" name="id" value="123">  
  </form>  
  <script>document.forms[0].submit();</script>  

19. 如果让你设计一个 CSRF 防护方案，会考虑哪些因素？

• 多层防护：组合使用 Token、SameSite、Referer 校验，避免单一方案失效。

• 业务场景：对敏感操作（如支付）强制验证码。

• 兼容性：支持移动端和第三方集成场景（如 OAuth）。

• 性能开销：避免频繁生成 Token 影响用户体验。

• 监控与告警：记录异常请求，及时发现攻击尝试。