一段程式碼上線之前，經過黑/白盒掃描之後，傳統型別的漏洞幾乎是已經絕跡了。我這個菜雞想要在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使用者

能不能用：

當發現此類功能點時，便可以嘗試測試是否只是前端校驗的問題

其他

要想挖掘到更多的越權/邏輯漏洞，需要對網站整體業務流程有一個把控，最好是把所有流程均走一遍