文章目录前言1. 业务流程中的安全管控2. WebApp中安全机制的实现3. CSRF的形成3.1 成因3.2 攻击原理与流程4. CSRF漏洞总结前言1. 业务流程中的安全管控毫无疑问你访问的大多数WebApp、移动App都需要你注册登录才能使用这里面有着商业、风控、合规等原因也有业务本身就需要的原因。就像你去银行取钱银行得先确认你是谁然后基于“你是谁”再判断你能不能进行取钱这个操作。总结一下这个过程身份认证看你的身份证会话管理持续面对面标识你已经认证过了为你办理业务访问控制你存钱的金额取钱最大金额当我们将这些由人操作的业务流程实现为一个计算机信息系统/网络应用时也必须提供相应的机制身份认证账号口令会话管理客户端会话ID唯一标识服务端会话数据结构访问控制权限ACL2. WebApp中安全机制的实现传统的鉴权机制的实现整个机制没有问题只有拥有账号密码的实体才能通过认证只有认证过后才拥有一个唯一的身份凭据session idsession ID 存储在Cookies中。问题在于浏览器对同一站点的cookie是自动携带的不管请求来源是哪里。3. CSRF的形成3.1 成因CSRF漏洞形成因素概括为3个层次第一层浏览器的 Cookie 机制Cookie 的设计初衷让无状态的 HTTP 协议维持状态 Cookie 的携带规则只要请求的目标域名匹配就自动携带 不管这个请求是谁触发的这意味着用户访问evil.com页面里如果有一个指向bank.com的请求浏览器会自动把bank.com的 Cookie 带上去。这不是浏览器的 bug而是设计如此。第二层服务端的信任边界模糊服务端收到一个请求 → 看到 Cookie 有效 → 认为是用户本人操作 → 执行 问题服务端缺少一个关键判断—— 这个请求真的是用户在我们的页面上主动发起的吗有可能是跨站发起的请求因为Cookie是自动携带的服务端只做了身份认证Authentication没有做请求来源验证Origin Validation第三层请求的可预测性攻击者必须能构造出目标站能理解和执行的请求 - 知道 URL如 /transfer - 知道参数名如 to, amount - 知道请求方法GET / POST 如果这些信息都可预测/可获取 → 攻击成立三个层次合在一起自动携带凭证浏览器机制 × 服务端不验证来源服务端缺陷 × 请求可被构造信息泄露 CSRF 攻击成立3.2 攻击原理与流程用户登录 bank.com → 浏览器获得 CookieSession ID ↓ 用户访问攻击者控制的 evil.com ↓ evil.com 页面中的恶意代码自动向 bank.com 发起请求 ↓ 浏览器自动携带 bank.com 的 Cookie ↓ bank.com 服务器认为是合法用户的操作 → 执行转账等操作4. CSRF漏洞总结维度核心要点本质服务端无法区分请求是用户主动发起还是被第三方借用根因浏览器自动携带 Cookie 服务端不验证请求来源测试核心站在攻击者视角构造一个能让用户浏览器自动发出的请求验证服务端是否执行