今天，我们决定讨论信息安全主题。我们发布了Kunal pandey文章的翻译版本，检测漏洞并努力工作！
介绍
用户的个人数据（PII）盗窃对我们来说已经司空见惯。攻击者找到了许多方法来获取个人数据，例如，通过使用XSS和IDOR漏洞，API端点公开等等。
可以通过简单地观察API端点的行为来测试本文中描述的方案。在下面的示例中，通过调用API，任何用户的个人信息都可以存储在其他API端点中。
说明
在邀请我的HackerOne Bug Bounty平台上的一个私有程序中，有人建议测试商店的门户，即卖方工作的区域。在这里，商店员工可以向任何客户发送“下订单”邀请。为了获得他们所需的信息，卖方通过电子邮件或使用QR码将此请求发送给客户。
在收到带有付款邀请的链接后，买方将转到：payment-na.examle.com/0811ebf4-d7d0-ba31-9ce68648a5a9并填写所需的数据。
截获请求后，Burp Suite会发现包含输入数据的POST API端点。
请求
POST /na/customer/client/v1/session/002420e4-e031-47aa-8d94-6f7c40c248c7 HTTP/1.1
Host: payments-na.example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json;charset=utf-8
X-Cdc-Client: 2.15.45
Content-Length: 125
Origin: https://payments-na.example.com
DNT: 1
Connection: close
Referer: https://payments-na.example.com
{"browser_prefilled":[],"customer_details":{"country":"US"..............},"skipped_fields":[],"user_submitted":true,"action":"continueAddressUnverified"}
回答
填写表格后，操作完成。做完了！
在对Payments-na.example.com/na/customer/client/v1/session/002420e4-e031-47aa-8d94-6f7c40c248c7的POST方法中，所有信息都已保存，付款已经完成。
手术阶段
用户或攻击者可能会在门户的另一部分中，与上述方法一样，可以使用“下订单”功能，并收到以下付款链接：payment-na.examle.com/fa5daba4-5d50-8f80 –9eb1-ebia3ea6d665。
在这种情况下，只需填写表格，在Burp Suite中拦截请求，接收对Payment-na.example.com/na/customer/client/v1/session/xxxx的POST请求，下载生成的API端点并将其他请求丢弃到我们没有发送给他们。
收到的API端点：payment-na.example.com/na/customer/client/v1/session/96afd42f-4281-4529-9b8c-3ba70b0f000b。
为了进行进一步的测试，也可以在浏览器中使用GET方法来使用此端点。下面是生成的API端点的屏幕截图：
如我们所见，尚未添加任何信息，也未指定任何参数。
现在，我们将检索此API链接，并将其发送给已填写订单详细信息的其他用户。一旦受害者单击此API链接，存储在此处的先前提交的所有个人数据（/ na /客户/客户/ v1 /会话/ 002420e4-e031-47aa-8d94-6f7c40c248c7）将被复制到指定的端点API：/ na /客户/客户/ v1 /会话/ 96afd42f-4281–4529–9b8c-3ba70b0f000b。
受害者单击我们发送给您的API链接后，所有用户的个人数据将被复制到此端点。
从受害者的角度：
攻击者只需以隐身模式访问此API端点就足够了，并且复制了受害者的数据（电子邮件，地址等）。
受害者的个人数据：
这样，攻击者只需创建新的会话API端点并将其发送给其他用户，即可获取任何客户端的个人数据。
处理错误
门户开发团队删除了GET方法，将其绑定到POST方法，并将授权令牌标头添加到上述POST方法请求中，每次它将在服务器上进行身份验证。
这消除了重复上述情况的可能性-通过API复制用户的个人数据的攻击。
关键点
1.此类攻击的场景可能有所不同，我的例子只是其中之一。请注意这些漏洞，并尝试更深入地挖掘以创建类似的场景：攻击者还可以如何攻击您。
2.在所描述的示例中，攻击者的API已向受害者的API端点进行了身份验证，因为没有对授权令牌标头进行验证。这允许服务器将客户的个人数据复制到另一个API端点。
活动过程：
7月22日：我向门户团队报告了此漏洞。
7月23日：团队对该报告进行了审核，严重性设置为“中”。
7月23日：获得了500美元的奖励。
7月27日：问题已解决，报告已编写。