一段代码上线之前，经过黑/白盒扫描之后，传统类型的漏洞几乎是已经绝迹了。我这个菜鸡想要在SRC活下去，必然是只能另谋出路

对什么应该保持敏感

• 以 type 等字段标识不同操作的

很多时候，单个接口就可以完成用户的增删改查操作，后端依据type等字段，做一层转发；例如type=1表示修改，type=2表示删除，通常可以修改操作的请求包的type值为2，导致越权删除问题。
同样的，不同的type也可能代表不同的数据类型。例如draft_tpye=1表示草稿，draft_type=2表示发布的文章；假设后端针对每种数据的更改都做好了权限校验，但是未考虑二者混淆的情况，通过变更该参数，就可能在发布草稿时对他人文章进行了删除操作

• json类型数据

存在一些购物场景，商品的种类往往是只能选中购买一种的。一般而言，通过传输一个www-form表单即可，类似于这样

goods_id=12345678&goods_num=3&goods_price=9.9&coupon_id=66666

通常遇到这样的情况，测试改价格为负数/小数或者极大值(整数溢出)，或者改一下优惠券的id就截止了
但是我们也会碰到如下的这种情况

{
	"type":1,
	"goods_list":[
		{
			"goods_id":123456,
			"goods_num":3,
			"goods_price":9.9,
			"coupon_id":666666

		}
	]
}

这样我们是不是也止步于之前的方法呢？不然：

{
	"type":1,
	"goods_list":[
		{
			"goods_id":123456,
			"goods_num":3,
			"goods_price":9.9,
			"coupon_id":666666

		},
		{
			"goods_id":123456,
			"goods_num":-3,
			"goods_price":9.9,
			"coupon_id":777777

		}
	]
}

这样更改很多时候都能生成异常的订单。可能是因为后端只考虑了数组中第一个值（good_list[0]）是否合法，而不是通过循环等方式检查所有值

同样的，当测试时发现关键性的参数包裹在json或者在 [] 之中时(看起来后端处理更麻烦)，不妨在其中增加几个参数值，往往就能发现越权问题
当然有的时候json格式的数据并不是直接作为整个post的请求体的，他可能经过一层url编码，转而存到www-form的参数中了，需要灵活变通；总之参数越多越复杂，越应该兴奋

加参数

在很多情况下，新增数据的操作一般是不会在传输参数中看到ID等字段的（例如新增联系人）。

那如何发现更多的参数（参数值）呢？

• 从响应中发现参数

从上面的图，大致也能猜出来，怎样可以导致越权了。在添加成功之后，发现响应中出现了类似ID的参数。尝试之后发现，通过在该请求中添加一个AccountId参数即可在对应账户中的添加上一个联系人。

这里由于漏洞已经修复了，所以......

• 收集同站/类似接口的参数

有时候一个参数可能在A接口未体现在请求包中，但是却可能在B接口中出现，所以此时搜集类似接口或者整个网站的请求参数以及响应参数(JS中当然也有)就很重要了
之前简单写了一个参数搜集的BURP插件

通过观察搜集到的参数的命名规则(驼峰UserName、蛇形user_name、串形user-name)，我们也能“猜”出来可能会用到的参数

删除参数试试？

• 删除整个参数
• 删除参数值
  有时，服务端会校验传入参数对应数据当前用户是否可以获取到，但并未考虑值为空的情况，导致删除参数(值)后会返回所有用户的信息
  

当然，以上讨论的增删改参数/参数值并不仅仅只是针对单个参数，有时候需要变更多个参数才能发现越权问题，这就需要对目标有一个整体的了解了。

tips：也可以尝试 参数污染

其他“越权”

流程越权

比如说忘记密码操作：验证账户及验证码、设置新密码
整个流程分为多步走，那么便可以尝试通过修改响应包来让绕过前一步，达到直接重置密码的目的
亦或者，也可以走完整个流程，然后重发最终修改密码的请求包，从而绕过发送验证码那一步

功能越权

VIP功能使用权限放在前端(客户端)校验，通过对比VIP与普通用户返回的数据包的不同，可通过修改普通用户返回包即可越权成为VIP用户

能不能用：

当发现此类功能点时，便可以尝试测试是否只是前端校验的问题

其他

要想挖掘到更多的越权/逻辑漏洞，需要对网站整体业务流程有一个把控，最好是把所有流程均走一遍