https://www.rfc-editor.org/rfc/rfc6749#section-4.1.1声明:
4.1.1。推荐的授权请求“状态”。客户端用于在请求和回调之间保持状态的不透明值。授权服务器在将用户代理重定向回客户端时包含此值。该参数应用于防止跨站点请求伪造,如第10.12节所述。
除了使用CSRF保护之外,在OAuth2授权请求中使用"state“参数(OAuth2)来识别授权流中的提供者回调中的用户是否安全?因此,使oauth2流“无状态”,并且不需要负载均衡器的“粘滞会话”。
当前,当用户启动OAuth2流(访问登录页面)时,我为他创建一个惟一的auth-request-id和state,并将其存储在Redis中,并在cookie中发送auth-request-id。
在回调请求中用户登录到提供者(Google或Facebook)后,我尝试从Redis中的auth-request-id cookie中查找用户会话,并验证会话是否存在,并且接收到的state与我发送的会话是否匹配(针对CSRF攻击)。
Wondering,我可以跳过创建 auth-request-id cookie并通过state**?*标识回调中的用户吗?**,如果在Redis中找不到匹配的state,则假设状态无效,并且所有Redis存储的state都有5分钟的终止时间。
发布于 2018-10-19 13:19:47
我相信你不能安全地做这件事。
恶意参与者可以使用您的应用程序自由获得重定向。现在,如果他设法使一个毫无戒心的受害者打开重定向地址,那么受害者将看到您的应用程序请求访问。如果他授予访问权,他将被重定向回你,如果你只使用状态来识别他,那么你只是将受害者资源分配给你的应用程序中的恶意参与者帐户。
https://security.stackexchange.com/questions/196023
复制相似问题