CSRF跨站请求伪造

复习定位

CSRF与XSS相反——不需要在目标网站注入脚本——而是利用用户已在目标网站的身份认证状态。当用户登录了银行网站——浏览器自动带上了bank.com的Cookie——此时访问了一个攻击者的恶意网站——该网站<img src=http://bank.com/transfer?amount=10000&to=attack>出发——浏览器自动附加源站Cookie——服务器认为这是一笔合法转账。CSRF攻击的核心场景是利用用户会话中的身份，对用户没有意识到的页面进行隐蔽操作。

CSRF的基本流程

1. 用户Alice登录银行网站bank.com——浏览器保留了bank.com的session Cookie
2. Alice没有登出bank.com——打开了一个新标签页访问了evil.com
3. evil.com隐藏一个自动提交的表单 POST到 http://bank.com/transfer
   <form action=http://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>
4. 浏览器发送请求时自动附加bank.com的Cookie——服务器端验证session是有效的——执行转账
5. Alice在不知情中转了10000元给attacker

CSRF防御

CSRF Token——服务器在表单中嵌入一个随机生成的token——提交时验证token正确性——攻击者的恶意页面无法获取该token(同源策略阻止访问目标域内容)。Token常常由session存储或由服务器签名。

SameSite Cookie——设置Cookie的SameSite=Lax或SameSite=Strict属性——浏览器决定是否在跨站请求中发送该Cookie。Strict大多数跨站请求不发送——包括GET link点击(用户从evil.com点击链接至bank.com——Strict可能不发送Cookie)。Lax允许大多数safe方法(如GET)的跨站请求携带Cookie(但不允许POST)。SameSite是一种可靠的现代防御——但旧版浏览器需要另外的后备机制。

Referer/Origin头验证——请求头中的Referer(来源页面URL)和Origin(请求来源站点)字段代表从哪发起的请求——服务器可以检查Referer是否为允许的来源——如果不是(如evil.com)拒绝请求。该方案依赖客户端的正确发送——不能保证在所有浏览器配置下可靠。

二选一验证码——高风险操作(批量转账)要求用户输入一次性口令或二次确认——跨站的自动化请求无法完成。

CSRF与XSS的区别

特性	XSS	CSRF
攻击原理	向页面注入脚本窃取用户信息	利用用户Cookeie向站点发送伪造请求
是否需要目标站的漏洞	是——需要反射/存储/dom型的执行点	只需要目标站有状态更改的请求
用户交互	有时只需浏览被注入的页面	需要用户在目标站登录后访问恶意网站
防御核心	输出编码、CSP	CSRF Token、SameSite Cookie

复习检查

1. CSRF攻击的两个关键条件是——受害者已在攻击目标站点登录——受害者访问了攻击者控制的页面——攻击者在自己的页面中通过什么HTML标签或自动提交的表单向目标站点发出请求。

2. CSRF Token为什么不能通过Cookie传输——如果Token放在Cookie中——跨站的表单提交也会自动带上Cookie——攻击者同样可以伪造这个Token提交(从cookie中自动的提交)，防御失去了效果。

3. SameSite == Lax 和 SameSite == Strict的区别——如果是用户从外部页面(如从搜索引擎)链接点击进入目标站——Lax会发送Cookie吗(对于GET，Lax允许通过顶级站点跳转)——Strict不允许？

4. csrf token在每个表单中生成一个随机数——但当前用户的token可以在一个js变量中获取吗(同源站的XSS如果能读到token就会继续被XSS攻击——所以必须先防XSS再谈CSRF)——所以XSS能打败CSRF。

5. 为什么银行等金融系统的高风险操作(转账)只用CSRF Token还不充分——最终需要二次验证(手机验证码/确认二次)因为Token在XSS场景下可以被读取——双重Cookie通过验证从自请求也是从本站携带的Cookie和表单隐式字段来同时验证请求页来源。