Account Takeover
授权问题
应尝试更改账户的电子邮件，并且必须检查确认过程。如果发现确认过程薄弱，则应将电子邮件更改为目标受害者的电子邮件并进行确认。
Unicode 规范化问题
目标受害者的账户
victim@gmail.com应使用 Unicode 创建一个账户 例如：
vićtim@gmail.com
正如在 这次演讲 中所解释的，之前的攻击也可以通过滥用第三方身份提供者来实现：
在第三方身份提供者中创建一个与受害者相似的电子邮件账户，使用某些 Unicode 字符（
vićtim@company.com）。第三方提供者不应验证电子邮件。
如果身份提供者验证电子邮件，您可以攻击域名部分，例如：
victim@ćompany.com，并注册该域名，希望身份提供者生成域名的 ASCII 版本，而受害者平台规范化域名。通过此身份提供者登录受害者平台，受害者平台应规范化 Unicode 字符并允许您访问受害者账户。
有关更多详细信息，请参阅关于 Unicode 规范化的文档：
Unicode Normalization重用重置令牌
如果目标系统允许重置链接被重用，应努力使用 gau、wayback 或 scan.io 等工具查找更多重置链接。
预账户接管
应使用受害者的电子邮件在平台上注册，并设置密码（应尝试确认，尽管缺乏对受害者电子邮件的访问可能使这变得不可能）。
应等待受害者使用 OAuth 注册并确认账户。
希望常规注册将被确认，从而允许访问受害者的账户。
CORS 配置错误导致账户接管
如果页面包含CORS 配置错误，您可能能够窃取用户的敏感信息以接管他的账户或使他更改身份验证信息以达到同样的目的：
CORS - Misconfigurations & BypassCSRF 导致账户接管
如果页面易受 CSRF 攻击，您可能能够使用户修改他的密码、电子邮件或身份验证，以便您可以访问它：
CSRF (Cross Site Request Forgery)XSS 导致账户接管
如果您在应用程序中发现 XSS，您可能能够窃取 cookies、本地存储或网页信息，从而使您能够接管账户：
XSS (Cross Site Scripting)同源 + Cookies
如果您发现有限的 XSS 或子域名接管，您可以操作 cookies（例如固定它们）以尝试妥协受害者账户：
Cookies Hacking攻击密码重置机制
Reset/Forgotten Password Bypass响应操控
如果身份验证响应可以简化为一个简单的布尔值，只需尝试将 false 改为 true，看看您是否获得任何访问权限。
OAuth 导致账户接管
OAuth to Account takeover主机头注入
在发起密码重置请求后，修改 Host 头。
将
X-Forwarded-For代理头更改为attacker.com。同时将 Host、Referrer 和 Origin 头更改为
attacker.com。在发起密码重置并选择重新发送邮件后，采用上述三种方法。
响应操控
代码操控：将状态代码更改为
200 OK。代码和主体操控：
将状态代码更改为
200 OK。将响应主体修改为
{"success":true}或空对象{}。
这些操控技术在使用 JSON 进行数据传输和接收的场景中有效。
更改当前会话的电子邮件
来自 这份报告：
攻击者请求将其电子邮件更改为新电子邮件。
攻击者收到确认更改电子邮件的链接。
攻击者将链接发送给受害者以便其点击。
受害者的电子邮件被更改为攻击者指示的电子邮件。
攻击者可以恢复密码并接管账户。
这也发生在 这份报告 中。
旧 Cookies
正如 在这篇文章中 所解释的，可以登录到一个账户，保存 cookies 作为已认证用户，注销，然后再次登录。 在新的登录中，尽管可能生成不同的 cookies，但旧的 cookies 又开始工作。
参考文献
Last updated
