隐式流的安全风险是什么 [英] What are the security risks of Implicit flow

问题描述

隐式流被认为是不安全的.我知道两个问题:

Implicit flow is considered to be insecure. I'm aware of two problems:

1. 困惑的代理人.但是要克服它，您只需要检查是否已将access_token赋予您的应用程序.没什么大不了的.
2. XSS攻击.因此，如果我们的access_token通过XSS攻击被盗，则可以将其用于发出请求(属于我们最初请求的范围的一部分).它很烂，但是很难窃取access_token，因为很可能我们只有在登录页面上才拥有它，并且由于生命短暂而没有以应用程序状态存储(我想这就是Implicit工作流不支持刷新令牌的原因).

1. Confused deputy. But to overcome it you just need to check whether access_token was given to your application. Not a big deal.
2. XSS attack. So if our access_token was stolen via XSS attack, it can be used to make requests (that are part of the scope we originally requested). It sucks but it's hard to steal access_token as most likely we had it only on our login page and didn't store in app state as it's short-living (I guess that's why Implicit workflow does not support refresh tokens).

看起来还不错.还有我不知道的其他安全漏洞吗?

It doesn't look too bad. Are there any other security vulnerabilities that I'm not aware of?

推荐答案

正确的语句应该是

隐式流相对于代码流相对不安全.

如果攻击者想使用代码流从应用程序中窃取用户访问令牌，则攻击者必须闯入服务器网络并发现应用程序机密，或者将服务器到Google的网络流量(HTTPS)窃听到保留访问令牌.

If an attacker wants to steal user access tokens from an app using code flow, then the attacker has to break into the server network and either uncover the app secret or eavesdrop the network traffic from server to Google (which is HTTPS) to get an hold to the access token.

在隐式流中，访问令牌驻留在浏览器中.在这种情况下，攻击者还有许多其他可能性可以窃取令牌而不必破坏网络.

In the implict flow the access token resides in the browser. In this case there are many other possibilities for an attacker to steal tokens without having to compromise a network.

• XSS(正如您已经解释的那样)
• 困惑的代理问题(如您已经解释的那样)
• 会话固定问题(在用户B的会话中使用用户A的令牌. https://www. facebook.com/FacebookforDevelopers/videos/10152795636318553/)
• redirect_url参数操作
• (可能)带有引荐来源标头的令牌泄漏
• 各种网络钓鱼和社会工程学可能性，诱骗用户泄漏其访问令牌(比要求输入密码更容易)

• XSS (as you already explained)
• Confused deputy problem (as you already explained)
• Session fixation issues (using user A's token in user B's session. https://www.facebook.com/FacebookforDevelopers/videos/10152795636318553/ )
• redirect_url parameter manipulation
• (possible) token leakage with referrer header
• Various phishing and social engineering possibilities to trick the users to leak their access token (easier than asking for their password)

但是，正如您所说，如果您是安全意识强的开发人员，则可以轻松地缓解所有这些错误.但是，如果您实现隐式流程，那么仍然存在这些漏洞的机会.因此，如果不将令牌传递给浏览器并在服务器端组件中处理令牌(代码流)，则可能是一个好主意.

But as you said, it is straightforward to mitigate all those errors if you are a security aware developer. But still there is a chance for these vulnerabilities if you implement the implicit flow. Therefore it might be a good idea if you don't deliver the token to browser and handle the token in a server side component (code flow).

这篇关于隐式流的安全风险是什么的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！