0x01 前言

上回书说道~说道哪儿忘了~我们接着再说说。
【PS: 这是自己在平时的测试中积累并值得分享的一些测试经验，可能不能将问题探究到多深入，希望文中的思路能有所用。】

0x02 “躲起来的”Form表单

1. 场景

就像小节标题提到的一样，留意那些“躲起来的”Form表单，很多场景下你是否遇到过点击触发一个功能请求，但是返回的是空白或者“无记录”的提示，请求中不包含任何用户参数，这个时候你留意了，是不是有什么东西是你遗漏掉了，遗漏了什么触发条件？

2. 案例

如图有一个这样的功能点，点击“信用卡”功能后，请求返回告诉你，该用户查询无记录。这个时候你要淡定了，So what？

接下来你要做的是什么？对接口进行请求构造Fuzz？客官且慢......怕是你需要再确认一下，那个躲在Form表单里的action是不是为你早就备好了。

让我们看图说话。这是点击“分期付款”功能时候的请求，查询到当前登陆用户没有下挂账户，但是留意到最下面的那个hidden起来的form表单了某？

让我们稍加修改，看看效果如何？看图说话。
将input框稍作修改，添加一个value，给前端添加一点可选择的账号的空隙余地。

再敲个回车，看看效果，看看是否后端已经对这个接口做了鉴权呢？是否可以……Bingo！

3. 多说几句

上面的案例需要注意几点：

是否存在隐藏的form表单；
后端是否对此接口的查询操作作了鉴权判断；

0x03 “犄角旮旯”的越权

1. 场景

”犄角旮旯“的越权，说起来是犄角旮旯，但其实有人测试的时候估计每个功能点都会触发一遍，所以你也会发现总有一些功能点光看按钮看不出个所以然。

2. 案例

有这么一个查询接口查询历史交易明细，图中所示：

选择查询之后，出现了几个按钮，“保存”、“打印”、“显示所有”、“保存所有”，一般情况说来“查看明细”、“查看详情”、“xx详情”等描述的功能点都对应着某一流水单号的记录情况，如果应用的处理方式不是在功能请求时全部返回所有订单数据的话，那么这一点是极有可能存在问题的点。

此处的“详情”功能处已经做了鉴权，无法通过修改流水单号查询他人信息。但问题点出在“显示所有”的功能点，应用的逻辑是在查询全部记录时，会为每个用户对应一个id号，那么此处可以直接批量去查他人的账户交易信息，并且可以保存下载。

如下图所示，查询所有数据时，请求中包含有FileName参数，为保存数据生成文档命名做准备。那剩下的只是遍历参数就好了。

3. 废话几句

案例中涉及到的点为一些看起来没有用但是真实存在漏洞的接口，所以案例2的结论就是注意那些看似无害的”犄角旮旯“。常见的几点如：查询、详情、明细、下载记录等等功能点。

0x03 鸡肋越权

1. 场景

说是鸡肋越权，是因为在测试的时用了自己准备的两个测试账号，同时因为需要涉及到cookie的替换等操作，有人可能会说：“这也太扯了，你都替换了cookie参数了，查看别人的信息那是肯定可以的啊！”，但其实如果我下面的案例与你想的多少有些不符，也正好咱们一起来讨论这个场景下的替换，是否算不算是越权呢。

2. 案例

此案例中涉及到的信息如下：

A和B两个测试账号，A为攻击者，B为受害者；
账户A未设置支付密码、B账户未知支付密码；

现同时登陆两个账号，获取cookie参数中的“mssc_sid”值。

之后对A账户进行操作，查看账户状态，显示未设置支付密码

随后进行设置密码，点击“设置密码”后，会首先发送请求校验当前cookie参数中的mssc_sid值，通过这个值来对当前用户身份进行识别。

注：
这里为什么要用一个未设置支付密码的账户A呢？因为“未设置支付密码账户”在设置密码时与“已设置支付密码账户”不同，不需要校验原交易密码，可以直接进行设置操作。

此过程中，拦截请求将此参数替换为B账户mssc_sid值，绕过原密码校验的同时，第一步“校验身份”会通过此账户识别为账户B，并进行到第二步，设置支付密码。

设置新的支付密码，有人会问，如果还有第二步，是不是也要同样的拦截请求并且修改mssc_sid参数，答案是当然不用了。虽然在这一步提交的请求包中mssc_sid参数值为A账户，后端以第一步校验的身份去设置密码，也就是设置B账户的交易密码会被修改，So，B账户支付密码被修改咯。

3. 小结

本案例问题点：

未校验用户身份唯一标识是否为当前登陆账户所属；
用户进行操作时，以第一次校验用户参数为准，未进行多次校验；

这个案例有点鸡肋，并不可以任意的去重置某一用户的支付密码，希望给你了一点提示，下次遇到同样的参数，可以测试是否存在和案例中一样的问题逻辑。或许，当你遇到同样的情景时，你的漏洞参数是有规律可循的。

0x04 再谈HPP

1. 场景

HPP简称“HTTP Parameter Pollution”，HTTP参数污染，此处指就是给相同参数赋上两个或两个以上的值，导致应用解析错误出现越权漏洞。话不多说，相信有很多人都知道这种类型问题。

2. 案例

此案例以修改账户别名为例，通过HPP的方式可以修改所有登陆账户的别名和手机号码。

在用户A登陆后，存在这样一个功能设置点，可以设置修改A账户的账户别名。便于用户在进行各类交易时操作，功能类似于电话本，方便查找使用。

问题出在修改这个功能点，当你设置A账户别名、手机号后，选择“确认修改“时，请求中包含一个PayeeId参数，对比两个不同的参数之后发现此处参数每个参数均代表唯一用户且在用户登陆状态下有效，另外我们可以看出，这个PayeeId编号前14位不变，后4位规律递增或随机的特征，OK，废话说多了，回到重点。

此处请求将别名设置为”1166661test“、手机号码设置为A账户手机号码，将B账户的PayeeId参数附带到当前账户PayeeId后，发现请求可以正常请求。

通过最直观的方式，登陆B账户查看别名设置情况，我们不难发现B账户的账户别名已经设置为”1166661test“，同时手机号码也改为了A账户的手机号码。

PS: 也许有人会问这个地方可以批量么？回答是当然可以，因为漏洞参数虽然是20位长度的字符串，但前14位不变，后四位就算不是递增，爆破的难度也不大。另如果结合此处的存储型XSS，可以将可利用程度提升。

3. 无废话可说

HPP已经有很多人知道的，所以没有什么特别要说明的，如果有人想要了解的话，自行去搜索吧，有很多很详细的解释。

0x05 最后

自己尝试根据这两篇文做了个流程图，每个方式方法的最终归属看起来都还是回归到了常规越权，希望下次我还能发现不一样的问题来分享。