身份认证绕过
添加或更改邮箱地址
如果添加新邮箱地址或更改现有邮箱地址的操作不需要密码确认，会话劫持、XSS 或 CSRF 可能导致账户接管。
Amazon Cognito 滥用
邮箱确认
使用确认链接绑定邮箱
尝试在账户 B 的会话中跟随账户 A 的确认链接。如果应用程序存在漏洞，它会将已验证的邮箱链接到账户 B。在这种情况下，攻击流程可能如下：
攻击者将
[email protected]链接到他们的账户。攻击者向受害者发送确认链接。
受害者在登录应用程序时从邮件中点击链接。
应用程序将
[email protected]链接到受害者账户。
参考：
多个邮箱确认
添加新邮箱的方法可以在单个请求中接受多个邮箱地址。但是，该方法可能仅基于一个邮箱创建一次性令牌，但将包含恢复链接的邮件一次性发送到所有传递的邮箱。例如，如果应用程序对此类攻击存在漏洞，在以下请求中：
PUT /user/profile HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/json
Content-Length: 57
{"email": ["[email protected]", "[email protected]"]}应用程序会向两个邮箱地址发送相同的确认链接。
您还可以尝试以下 payload：
[email protected]&[email protected]
[email protected],[email protected]
[email protected]|[email protected]
[email protected]%[email protected]
[email protected]%[email protected]
[email protected]%0a%0dcc:[email protected]
...另一个类似的情况是，当确认链接发送到错误的邮箱时存在业务逻辑漏洞。例如，如果应用程序向已添加的主邮箱发送确认链接，而不是未确认的邮箱。
参考：
跳过确认过程
如果应用程序允许您在没有邮箱确认过程的情况下创建用户，您可以尝试滥用此功能来获取具有预确认邮箱的新用户。这在以下情况下至少是可能的：
应用程序允许创建具有预定义已确认邮箱的机器人用户。
SCIM 预配功能。
通过易受攻击的服务进行 OAuth 认证，该服务允许使用未确认的账户进行认证。
参考：
使用未确认的邮箱
如果应用程序允许使用未确认的邮箱，请尝试在应用程序或其他应用程序/系统依赖邮箱地址的流程中滥用此行为。例如：
如果存在盲目信任易受攻击应用程序数据的应用程序/系统，您可以尝试滥用此信任。例如，如果应用程序可以用作 OAuth 授权服务器，请尝试使用具有未确认邮箱的账户通过 OAuth 向第三方应用程序进行身份验证，您可以在 OAuth 2.0 漏洞：滥用具有未确认邮箱的账户 中找到更多详细信息。
尝试使用未确认的邮箱来抢占可能被其他用户使用或应用程序内部使用的邮箱。在这种情况下，您可以阻止所有或特定用户的某些应用程序功能。
如果某些功能不应对未确认其邮箱的用户可用，请检查这些功能对他们是否真的不可用。此外，请确保 REST 和 GraphQL API 也遵守相同的策略。
使用 OTP 进行邮箱确认
弱确认令牌
确认令牌可能使用易受攻击的生成算法生成，这可能导致预测生成值的可能性。如果您成功预测令牌，您将能够为任何邮箱生成有效的确认令牌。
信息泄露
应用程序在执行操作时可能会在响应中返回未知数据。这些可以是请求的密码、生成的 OTP、具有额外权限的 cookie、用户数据、详细的错误消息等。检查服务器响应中是否存在此类数据。
OAuth 2.0
密码恢复
Host 头部投毒
应用程序可以使用 Host 头部值来生成密码恢复链接。如果应用程序易受 Host 头部投毒攻击，您可以影响链接并指定您的域名。结果，如果受害者从邮件中点击链接，恢复令牌将泄露到您的域名。
有几种方法可以实现 Host 头部投毒。
Host 头部替换
您可以尝试将 Host 头部替换为您的域名。易受攻击请求的示例：
POST /users/password HTTP/1.1
Host: attacker-website.com
Content-Type: application/json
Content-Length: 31
{"email": "[email protected]"}或绕过主机验证（参见 SSRF 相关文档）：
POST /users/password HTTP/1.1
Host: attacker-website.com/vulnerable-website.com
Content-Type: application/json
Content-Length: 31
{"email": "[email protected]"}参考：
覆盖 Host 头部
传递链中的组件，如代理，可以使用额外的 HTTP 头部传递客户端请求的原始主机：
您可以尝试使用这些头部来识别客户端在 Host 请求头部中请求的原始主机：
POST /users/password HTTP/1.1
Host: vulnerable-website.com
x-forwarded-host: attacker-website.com
x-host: attacker-website.com
x-original-host: attacker-website.com
Content-Type: application/json
Content-Length: 31
{"email": "[email protected]"}参考：
多个 Host 头部
您可以尝试指定多个 Host 头部。易受攻击请求的示例：
POST /users/password HTTP/1.1
Host: vulnerable-website.com
Host: attacker-website.com
Content-Type: application/json
Content-Length: 31
{"email": "[email protected]"}多个邮箱地址
密码恢复方法可以在一个请求中接受多个恢复邮箱。但是，该方法可以仅基于一个邮箱搜索账户来创建一次性令牌，但将包含恢复链接的邮件一次性发送到所有传递的邮箱。例如，如果应用程序对此类攻击存在漏洞，在以下请求中：
POST /users/password HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/json
Content-Length: 57
{"email": ["[email protected]", "[email protected]"]}应用程序会向两个邮箱地址发送相同的恢复链接。
您还可以尝试以下 payload：
[email protected]&[email protected]
[email protected],[email protected]
[email protected]|[email protected]
[email protected]%[email protected]
[email protected]%[email protected]
[email protected]%0a%0dcc:[email protected]
...参考：
账户和代码之间缺乏关联
尝试为您的账户请求一次性令牌，并使用它们来恢复受害者的账户：
POST /users/password/recovery HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/json
Content-Length: 72
{"email": "[email protected]","code": "<攻击者账户的代码>"}密码恢复不会终止之前创建的会话
成功的密码恢复应该终止之前创建的会话。如果这种情况没有发生，受害者将无法管理其账户的安全性。结果，攻击者将能够在较长时间内保持活动会话。
通过 Referer 头部泄露令牌
Referer HTTP 请求头部包含发出请求的页面的绝对或部分地址。Referer 头部允许服务器识别人们访问它的页面。此数据用于分析、日志记录、优化缓存等。
Referer 头部可以包含 origin、path 和 querystring，可能不包含 URL 片段（即 #section）或 username:password 信息。请求的 referrer 策略定义了可以包含的数据，参见 Referrer-Policy。
包含密码恢复的页面，应用程序通过邮件发送其链接，可以加载第三方脚本，例如分析，或包含指向第三方资源的链接，例如社交网络。如果在请求这些资源时将密码恢复链接传递到 Referer 头部中，一次性令牌会泄露到第三方资源，因为它被传递到 querystring。
参考：
弱恢复令牌
恢复令牌可能使用易受攻击的生成算法生成，这可能导致预测生成值的可能性。如果您成功预测令牌，您将能够为任何账户生成有效的恢复令牌。
手机和 OTP 认证
OTP 重发
如果应用程序没有对重发 OTP 设置速率限制，并且重发 OTP 会重置 OTP 输入尝试的速率限制，则应用程序易受 OTP 暴力破解攻击。
参考：
OTP 重用
如果应用程序允许使用已使用或重新生成的旧 OTP，任何 OTP 泄露（例如，泄露到日志或第三方服务）都将危及依赖 OTP 的功能。
会话固定
应用程序可以实现如下身份验证流程：
应用程序调用
/SessionCreate端点，传入用户的手机号码后端为用户创建会话并返回会话令牌，但在验证完成之前无法使用此会话进行操作
向用户发送包含验证码的短信
应用程序调用
/SessionVerify端点，传入会话令牌和通过短信接收的验证码一旦此请求成功完成，会话令牌变为有效，用户现在已登录
如果后续对 /SessionCreate 的调用返回与第一次相同的会话令牌，直到调用 /SessionVerify，您可以使用 /SessionCreate 端点来获取将在受害者身份验证后有效的会话令牌。
参考：
伪造认证请求的部分
如果在 OTP 检查期间应用程序额外使用某些参数，请尝试使用来自不同账户请求的值。该参数可以是 cookie、头部或请求参数。如果您在攻击者的 OTP 检查请求中使用受害者的参数值，您可以进入受害者账户或绕过双因子认证。
此外，尝试将攻击者的有效 OTP 值重新用作受害者的 OTP 值。如果应用程序不验证 OTP 是否属于攻击者，您将能够进入受害者账户或绕过双因子认证。
短期和长期 OTP
应用程序可以使用短期（少于5位）和/或长期 OTP。这种实现为暴力破解留下了许多方法，特别是在没有速率限制或速率限制较弱或可绕过的情况下。
速率限制
第三方登录或注册
实现第三方登录或注册的应用程序通常基于第三方应用程序发送的附加邮箱地址来识别用户。在这种情况下，您可以尝试使用链接到同一邮箱地址的两个不同的第三方应用程序进行登录或注册。有时这两个账户可以合并，您将通过您的第三方应用程序账户登录或注册来访问受害者的账户。
例如，假设受害者通过链接到 [email protected] 的 third-party-app1.com 登录或注册到 vulnerable-website.com。要利用此漏洞，请尝试以下流程：
在
third-party-app2.com创建账户并输入[email protected]邮箱地址（理想情况下不需要邮箱确认）尝试通过
third-party-app2.com在vulnerable-website.com登录或注册如果应用程序存在漏洞，您将能够访问受害者的账户
参考：
用户名和密码认证
暴力破解
如果应用程序没有对登录尝试设置速率限制，请尝试制作字典并暴力破解密码。
速率限制的一种实现使用用户名或邮箱作为尝试计数的标识符。尝试通过使用额外空格或大小写来绕过保护：
email=" [email protected]"
email="[email protected] "
email="[email protected]"
email="[email protected]"
...您可以使用以下链接：
WordList Compendium - 个人编写的单词列表和字典集合，包含用户、密码、目录、文件、漏洞、模糊测试、注入、工具单词列表等。
SecLists - 安全评估期间使用的多种类型列表的集合。
PWDB - 新一代密码大规模分析 - 从互联网10亿凭证泄露中提取的所有数据的集合。
bopscrk - 生成智能且强大的单词列表的工具。
BruteLoops - 协议不可知的在线密码猜测 API。
参考：
凭证填充
凭证填充 是搜索泄露的用户名和密码用于流行的在线服务，因为大多数用户在任何地方都"习惯于"使用相同的密码。
您可以使用以下列表：
资源：
默认凭证
尝试使用默认凭证登录管理面板、第三方服务、中间件等。
您可以使用以下列表：
缺乏密码长度限制
大多数应用程序存储用户密码的哈希值，不以明文存储密码。因此，应用程序在验证用户时对传递的密码进行哈希处理，并将哈希值与数据库中存储的哈希值进行比较。此外，通常使用具有可变计算成本的函数作为哈希函数，其计算复杂性远高于常见的哈希函数，如 sha256。因此，如果应用程序没有实现对密码长度的限制，这可以用于 DoS：对非常长的密码进行哈希处理可能是资源密集型的。
参考
最后更新于