前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >SSRF 到全账户接管 (ATO)

SSRF 到全账户接管 (ATO)

作者头像
Khan安全团队
发布2022-03-07 09:04:39
4800
发布2022-03-07 09:04:39
举报
文章被收录于专栏:Khan安全团队

在计算机安全中,服务器端请求伪造 (SSRF)是一种攻击类型,攻击者滥用服务器的功能,导致它访问或操纵该服务器领域中的信息,否则攻击者无法直接访问这些信息. —维基百科。重要的是要注意,尽管在野外很难找到它,但 SSRF 仍然是黑客中备受追捧的错误。

攻击

在深入研究了应用程序的各种功能之后,当我意识到 POST 请求的 Host 标头易受 SSRF 攻击时,我在密码重置功能中获得了成功。我怎么知道的?我将 Host 头中的地址替换为 burp collaborator 生成的地址,并在 HTTP 回调中获取了应用程序服务器的 IP。此外,我还能够根据响应时间枚举服务器的内部端口。除此之外,不可能进行诸如 RCE 之类的攻击。

现在提出这个错误的影响。我启动了我的 Ngork 服务器,为概念验证 (POC) 创建了一个测试帐户(我们称之为受害者)并启动了密码重置。拦截 POST 请求,我将 Host 标头中的 URL 替换为我的并转发请求(图 1)。

转发的请求导致受害者收到一封密码重置电子邮件,如图 2 所示。

图 2

然而,在这次攻击中,不是在单击“重置密码”链接后打开密码重置页面,而是将与受害者关联的 URL 令牌发送给攻击者(我😊),参见图 3。

图 3

有了我拥有的 URL 令牌,应用程序的 URL 和 URL 令牌的组合导致我获得了受害者的密码重置页面 - 导致完全帐户接管。

本文系转载,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文系转载前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 攻击
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档