邏輯讓我崩潰之越權姿勢分享(續集)
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 最後
自己嘗試根據這兩篇文做了個流程圖，每個方式方法的最終歸屬看起來都還是迴歸到了常規越權，希望下次我還能發現不一樣的問題來分享。
