我想知道最终用户如何检测恶意实施的 OAuth，无论是 2-legged 还是 3-legged。特别是我对消费者请求者恶意向用户呈现虚假资源提供者页面以输入凭据的情况感兴趣。通常，如果期望消费者将请求者转发到 Facebook，假设消费者做了什么，它会向用户呈现一个虚假的 Facebook 页面。这将允许消费者在未来欺骗用户的身份......
OAuth 在这方面有什么建议吗？
特别是我对浏览器环境中的用例感兴趣。
检测 OAuth 恶意实现
信息安全
Web应用程序
网页浏览器
oauth
2021-09-07 06:07:57
3个回答
OAuth RFC规定：
OAuth 使用令牌来表示资源所有者授予客户端的授权。通常，在验证资源所有者的身份（通常使用用户名和密码）之后，服务器应资源所有者的请求颁发令牌凭证。
服务器可以通过多种方式促进令牌凭证的供应。本节定义了一种这样的方式，使用 HTTP 重定向和资源所有者的用户代理。这种基于重定向的授权方法包括三个步骤：
- 客户端从服务器获取一组临时凭证（以标识符和共享密钥的形式）。临时凭证用于在整个授权过程中识别访问请求。
- 资源所有者授权服务器授予客户端的访问请求（由临时凭证标识）。
- 客户端使用临时凭证从服务器请求一组令牌凭证，这将使其能够访问资源所有者的受保护资源。
因此，要获得授权，客户端（使用您数据的站点）必须将您重定向到保存您的数据以进行注册的服务器。
在第 2.2 节中，RFC 声明：
服务器处理授权请求的方式，包括是否使用 TLS/SSL 等安全通道，超出了本规范的范围。但是，服务器必须首先验证资源所有者的身份。
但是我（作为资源所有者）绝对不会在不检查站点证书的情况下使用任何 OAuth 规范。
所以对于 OAuth 1.0，这不是强制性的。
该OAuth 2.0用户RFC仍然是一个草案，但据我所知，它需要TLS
10.9。端点真实性
为了防止中间人攻击和网络钓鱼攻击，授权服务器必须为发送到授权和令牌端点的任何请求实施并要求具有 [RFC2818] 定义的服务器身份验证的 TLS。客户端必须根据其对服务器身份认证的要求来验证授权服务器的 TLS 证书。
[...]
10.11[...] 为了降低网络钓鱼攻击的风险，授权服务器必须在用于最终用户交互的每个端点上使用 TLS
因此，身份验证依赖于最近在博客上讨论的 TLS 协议。
总而言之，我怀疑任何没有 TLS 的 OAuth 尝试都是恶意的。如果 SSL 证书未通过验证，当然也是一样的。
我的方法是打开一个新选项卡并确保我登录到我打算通过的任何服务进行身份验证，比如说 Facebook。然后，当新站点将我重定向到 Facebook 时，我只需单击某些内容即可同意，无需再次输入凭据。如果我收到一个表格来输入凭据，我就会知道出了点问题。
没有办法解决这个问题，因为这是一个典型的网络钓鱼示例，完全不需要OAuth在您的帖子中包含这个词就可以做到......
每个应用程序都可以将其用户重定向到一个虚假的“facebook”站点，并要求用户输入他的facebook凭据。唯一的补救措施是用户自己在“ facebook”上输入他的凭据时仔细查看浏览器中的 URL 。
至于 2-legged OAuth，您不必担心，因为这是最终用户（和浏览器）不参与的机器对机器通信......