OAuth2.0授权码模式中State参数的用途及防CSRF原理咨询

一、为什么随机State能防范CSRF攻击？ #

先明确CSRF攻击的核心逻辑：攻击者诱导已登录授权服务器的用户点击恶意链接发起授权请求，此时用户浏览器会自动带上授权服务器的Cookie，授权服务器会误以为是用户主动发起的请求，进而把授权码发送到攻击者预设的回调地址。

State参数的防护逻辑很直接：

• 客户端发起授权请求前，生成一个随机唯一的字符串（State），把它存在用户本地的Session或浏览器本地存储里。
• 同时将这个State作为参数拼入授权请求URL，发送给授权服务器。
• 授权服务器处理完授权请求后，会把这个原封不动的State和授权码一起返回给客户端的回调地址。
• 客户端收到回调后，会把返回的State和自己之前存在本地的State做对比：只有两者完全一致，才继续处理授权码；不一致直接拒绝请求。

攻击者绕不开这个机制的原因是：CSRF攻击只能利用用户浏览器自动携带Cookie，但攻击者无法读取用户本地存储的State值。他构造的恶意授权请求里的State，要么是自己瞎编的，要么是从别的用户请求里偷来的，根本匹配不上当前用户本地存储的那个State。客户端对比失败后就会直接丢弃请求，攻击者自然拿不到有效的授权码。

二、如果请求中途被攻击者拦截，拿到State怎么办？ #

这种情况不用慌，核心原因有两个：

1. State和用户Session绑定：你存在本地的State是和当前用户的Session一一对应的，攻击者拿到的只是一个孤立的字符串，他没有办法获取用户的Session凭证（比如Session ID对应的Cookie）。就算他拿着这个State去访问客户端的回调接口，客户端也找不到对应Session里存储的State，对比必然失败。
2. 回调触发场景受限：授权服务器的回调是发送到用户的浏览器，再由用户浏览器转发给客户端的。攻击者拦截到State后，没法模拟用户的浏览器环境发起有效的回调请求——他的请求不会带上用户的Session，客户端根本不承认这个请求的合法性。

简单说，单独的State字符串毫无用处，必须和用户当前的Session绑定才能生效，而攻击者拿不到用户的Session，就算拿到State也白搭。

内容的提问来源于stack exchange，提问作者Ramprasad Thakur