挖洞经验分享：关于IDOR的几个奇怪案例分析(2)

很可能是因为，后端文件仍然是以“bookingId.pdf”的形式存储的，并且有一个中间件来负责将hdnBookingId解密为bookingId，或者说同时存储了一个订单的两种文件名称/格式，即同时存在“hdnBookingId.pdf”和“bookingId.pdf”。

接下来，我对该公司旗下的Android应用程序进行了分析，并且发现流量会被路由至一个终端节点处：

这对于黑客来说，绝对是一个宝藏。这是一个记录了所有节点的文档，当点击相应节点的超链接时，还会提供响应的JSON和XML样本Payload，以及节点返回的响应数据格式。检查完这些节点之后，我发现了一个可能会导致某些信息泄露的节点：

这里要求提供TransactionscreenID、UserName和Password这三个参数，但此时的我竟然有些束手无策测。

通过Android应用程序获取到订票信息后，便会触发这个节点，然后我们就可以查看到获取订票细节所需的参数值了：

节点会以HTML Table的格式返回乘客的信息，而不是之前的PDF格式：

现在，我们可以再看看之前的文档了。还记得ProcessType参数吗？我们可以直接将URL地址中的最后一个参数改成1或者其他值：

将“3”传递给ProcessType参数，将会触发异常，并允许我们查看到底层代码。

在查看文档时，我还发现了另一个可能会泄露敏感信息的节点：

向这个节点请求数据，将会返回用户的个人身份识别信息PII。只要你在这家公司的网站上订过票，那你的数据就可以通过这样的方式来获取到。