【问题标题】:How to prevent the following CSRF attack on Oauth2?如何防止 Oauth2 发生以下 CSRF 攻击?
【发布时间】:2016-10-19 11:09:11
【问题描述】:
  • 受害者在 Oauth2 授权代码流中通过授权服务器上的系统浏览器进行身份验证,并由授权服务器发出会话 cookie
  • 受害者被诱骗点击攻击者网站上的链接,该链接通过受害者浏览器向 Oauth2 授权服务器发起 Oauth2 授权请求,并带有攻击者 Oauth2 客户端的客户端 ID 和重定向 URI
  • 授权服务器不需要对受害者进行身份验证,因为授权服务器已经发布了会话 cookie,而只需要求受害者授予攻击者客户端访问权限——在这种情况下,假设受害者这样做
  • 授权服务器会将受害者浏览器重定向到攻击者重定向 URI(假定指向 Web 应用程序),并带有受害者的授权码的授权响应
  • 攻击者现在拥有受害者的授权码,他或她可以交换刷新和访问令牌

除了受害者不接受授予攻击者客户端访问权限之外,针对此问题的最佳预防措施是什么? 我的意思是,普通的互联网用户通常会在平常的日子里点击接受很多东西而不会考虑太多。

【问题讨论】:

  • 你知道有Information Security Stack Exchange这个事实吗?
  • 我认为应用程序安全作为一个介于安全和编码之间的多学科领域,可能更属于 StackOverflow。信息安全堆栈交换上讨论的信息安全是一个更广泛的领域,很多人不是开发人员。他们在不同的层面上处理问题,有时更多的是从理论的角度。所以简而言之我认为这确实是一个编程问题。

标签: security oauth2


【解决方案1】:

为此,攻击者必须向身份验证提供程序注册他的客户端,这在企业设置中是不可能的。此外,由于未注册重定向 URI,AP 不应将用户重定向回攻击者。

对于任何人都可以注册客户端的公共 AP,这确实是一个问题,但这也是某种意义上的重点。如果用户授权攻击者的应用程序,那么攻击者的应用程序将具有访问权限。由于在这方面它与普通应用程序没有什么不同,因此用户必须小心(虽然您是对的,但大多数用户只会单击“确定”即可)。

例如,AP 仍然可以根据用户报告维护一个黑名单,但这是一个薄弱的控制。 AP 可以做的最好的事情可能是为用户提供足够的信息和警告,将 OK 按钮延迟几秒钟以尝试让他们阅读,等等。

【讨论】:

    猜你喜欢
    • 2021-06-26
    • 1970-01-01
    • 2015-09-28
    • 1970-01-01
    • 2019-04-25
    • 2018-01-08
    • 2011-03-12
    • 2017-09-24
    • 1970-01-01
    相关资源
    最近更新 更多