挖掘邏輯漏洞

支付邏輯漏洞

【預防思路】php

訂單須要多重效驗，以下圖所演示。
前端

帳戶惡意攻擊

越權訪問漏洞

水平越權

水平越權指的是攻擊者嘗試訪問與他擁有相同權限的用戶的資源，怎麼理解呢？好比某系統中有我的資料這個功能，A帳號和B帳號均可以訪問這個功能，可是A帳號的我的信息和B帳號的我的信息不一樣，能夠理解爲A帳號和B帳號我的資料這個功能上具有水平權限的劃分。此時，A帳號經過攻擊手段訪問了B帳號的我的資料，這就是水平越權漏洞。web

系統中全部具有水平權限劃分的功能，都存在水平越權的風險，如下是常出現的水平越權的功能的幾種場景：算法

1. 基於用戶身份ID安全

在使用某個功能時經過用戶提交的身份ID（用戶ID、帳號、手機號、證件號等用戶惟一標識）來訪問或操做對應的數據。服務器

舉個栗子：cookie

①某航空公司存在水平越權漏洞，提交訂單後抓取數據包。

②能夠發現請求中有蠻多ID信息，一般狀況下，咱們通常會挨個測試，是否存在越權漏洞，其中passenger1d1是伺機人，contactId聯繫人。

③經測試可發現這兩個參數修改後，可查看到其餘伺機人的身份證及聯繫人信息。

2. 基於對象IDsession

在使用某個功能時經過用戶提交的對象ID（如訂單號、記錄號）來訪問或操做對應的數據。app

舉個栗子：svg

①某系統存在水平越權漏洞。

②抓取訂單提交的數據包，發現有一個oid很可疑。

③嘗試進行測試發現，可遍歷訂單號，查看他人待付款訂單信息。

3.基於文件名

在使用某個功能時經過文件名直接訪問文件，最多見於用戶上傳文件的場景。

舉個栗子：

①某系統存在水平越權漏洞。

②遍歷fileid能夠下載到數十萬的資質文件：http://**.**.**.**/sFile-image.action?fileid=9316

越權訪問：http://**.**.**.**/sFile-image.action?fileid=39316

垂直越權

垂直越權指的是一個低級別攻擊者嘗試訪問高級別用戶的資源。好比說某個系統分爲普通用戶和管理員，管理員有系統管理功能，而普通用戶沒有，那咱們就能夠理解管理功能具有垂直權限劃分，若是普通用戶能利用某種攻擊手段訪問到管理功能，那咱們就稱之爲垂直越權。

垂直越權主要如下兩種攻擊場景：

1.未認證帳戶訪問無需認證後能訪問該功能

舉個栗子：

①某站點後臺僅使用js跳轉來限制未受權的用戶訪問。

②去掉js能夠成功訪問後臺，且能夠進行操做。

2. 不具有某個功能權限的帳戶認證後成功訪問該功能

舉個栗子：

①使用default用戶名和密碼：useradmin / admin!@#$%^登陸系統。

②成功登陸後臺。

③依次點擊「對象管理——>用戶管理——>編輯‘useradmin’——>獲得URL：.../cgi-bin/webif/Objset-users.sh?edituser=edituser&id=5」

④修改參數id爲：id=4，成功垂直越權telecomadmin。

⑤查看源碼，可讀取telecomadmin密碼：telecomadmin34224223，至此已得到最高管理員權限，能夠徹底對該設備進行操做。

⑥由下圖可判斷出telecomadmini爲高權限用戶。

Cookie設計缺陷

弱會話ID

用戶的cookie數據加密應嚴格使用標準加密算法，並注意密鑰管理。但有一些廠商爲了圖方便，沒有對用戶的cookie作太多的加密工做，僅僅是單純的作一個靜態加密就完事了。我以前就碰到一個，能夠爲你們還原一下當時的場景。

當時我看到cookie中有個access token參數，看到value後面是兩個等號，習慣性的給丟去base64解碼裏面，發現解出來後是個人用戶名。所以只要知道一我的的用戶名就能夠僞造對方的cookie，登錄他人帳戶。

有些web對於cookie的生成過於單一或者簡單，致使黑客能夠對Cookie的效驗值進行一個枚舉，以下圖所示：

根據上圖，咱們能夠分析出，這家網站對於cookie的效驗只單純的採用了一組數字，而且數值爲常量，不會改變，這樣很是容易遭到黑客的枚舉。甚至有一些網站作的更簡單，直接以用戶名，郵箱號或者用戶ID等來做爲cookie的判斷標準。

身份認證未及時更新

通常來講，當你們更改密碼之後，以前的cookie值是不可以繼續使用的，須要用戶從新登錄帳號。Black Hat對本身的APP安全好像頗有信心，因此在用戶更改密碼後，以前的cookie值還能一直使用。WTF?！沒錯，就是這樣。解釋清楚一點就是，假設A的帳號被B盜取了，而且登錄在B的手機上。這個時候，A重置了本身的Black Hat帳號的密碼。可是隻要B不退出A的帳號，B就能夠一直查看A的Balck 帳號全部信息。我繼續用一張圖片演示一下。

更多會話ID的漏洞，請訪問：Web安全-會話ID漏洞。

任意密碼重置

短信驗證碼回傳

【原理】經過手機找回密碼，響應包中包含短信驗證碼

【案例】某網站選擇用手機找回密碼：
　　點擊發送按鈕，攔截回包，能夠查看到短信驗證碼，以下圖所示：

【修復建議】 響應包中去掉短信驗證碼。

修改用戶ID重置密碼

【原理】

經過手機找回密碼是通常須要短信驗證碼驗證（這裏能夠嘗試爆破或繞過），當咱們輸入正確的手機號和正確的短信驗證碼，而後進入重置密碼的最後一步，也就是輸入新的密碼，輸入密碼後提交到服務端的post數據包須要包含當前用戶的身份信息，而通常網站是經過用戶名或用戶ID來標識用戶身份的，若是這個用戶名或用戶ID沒有和當前手機號、短信驗證碼進行綁定，也就是說服務端只驗證用戶名、ID是否存在，而不去驗證用戶和當前手機號是否匹配，那麼咱們就能夠經過修改用戶名、ID去修改其餘用戶的密碼了。固然能夠修改的地方不限於找回密碼的數據包，好比修改資料的地方也可能存在這樣的漏洞。

【案例】

以某網站修改任意用戶資料致使修改任意帳號密碼爲例，截取的數據包爲：

POST /user/info_do HTTP/1.1
Host: www.XXX.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:59.0) Gecko/20100101 Firefox/59.0
Accept: */*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Referer: http://www.XXX.com/user/info_view
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 211
Cookie: yunsuo_session_verify=9341a54b945886e9485ff54a17650468; PHPSESSID=sgbibaqe7f8f6okerps8jip916; sdrcUserlockcount=1; sdrcUseruserid=14943
Connection: keep-alive

password=A123456&email=1%40qq.com&address=1&postcode=1&mobile=13888888888&sex=man&birthday=0000-00-00&degree=collegeLT&testsite=1&post=1&__hash__=b0b15b067dea00bd34fd39421b7ef684_efc2399e5c4b2071f261e75fe3362d4fa

經分析與嘗試，發現數據包中的sdrcUseruserid的值是用來標識當前用戶身份的，那麼咱們就想到這個id能否任意修改呢？答案是確定的，咱們修改id的值爲14942是能夠成功的，截圖以下：

【修復建議】

1. 用戶操做我的信息（讀取、修改）時，服務端要對當前用戶身份進行驗證，防止越權操做；
2. 用來標識用戶身份的名稱或ID可使用自定義加密，也能夠隱藏這些參數，直接從cookie中獲取用戶信息；
3. 用戶修改密碼時應該先對舊密碼進行驗證，或者使用手機短信驗證；
4. 用戶修改手機號時須要先對原手機號進行驗證。

任意郵箱接收驗證短信

登陸控制繞過

未驗證登陸憑證

有些業務的接口，由於缺乏了對用戶的登錄憑證的效驗或者是驗證存在缺陷，致使黑客能夠未經受權訪問這些敏感信息甚至是越權操做。

常見案例：

一、某電商後臺主頁面，直接在管理員web路徑後面輸入main.php之類的便可進入。
二、某電子認證中心敏感文件下載：

三、不一樣角色的帳號登陸系統後，僅經過隱藏操做菜單的方式來實現權限控制：

實際上還有不少案例，這裏就不一一例舉了，可是他們都存在一個共同的特性，就是沒有對用戶的登錄憑證進行效驗，以下圖爲例。
【預防思路】

對敏感數據存在的接口和頁面作cookie，ssid，token或者其它驗證，以下圖所示。

Token值可被預測

經過郵箱找回密碼時，郵件中將出現一個含有 token 的重置 URL，該 token 即爲重置憑證。從經驗來看，開發人員習慣以時間戳、遞增序號、關鍵字段（如郵箱地址）等三類信息之一做爲因子，採用某種加密算法或編碼生成 token，攻擊者能夠基於能收集到的關鍵字段，用常見加密算法計算一遍，以判斷是否能夠預測出 token。

案例1：基於關鍵字段生成的 token

某網站密碼找回功能，請求含有三個參數：

username 是郵箱、rvcode 圖片驗證碼、sid 未知，登陸郵箱查看重置 URL：

key 參數爲重置憑證，嘗試分析生成方式。直接將其放入 md5 在線破解網站無果，嘗試用 username、rvcode、sid 等三個參數的排列組合進行 md5，當嘗試到 md5(username + sid) 時發現生成結果與郵件中的憑證一致：

猜想出其 key 的生成算法，那麼，後續將毫無壓力地重置任意帳號的密碼了。

相似的還有，帶憑證的重置連接爲 http://mysite.com/sms.php?k=a18f057d5aF，屢次獲取重置連接發現，憑證 f198a79b9cF 末尾的 F 恆定不變，前面 10 位字符疑似 md5 加密，嘗試對不一樣參數的排列組合進行 md5 加密，當嘗試到 md5(手機號+圖片驗證碼) 時發現生成結果與郵件中的憑證一致：

案例2：基於遞增序號生成的 token

金蝶雲之家密碼找回，帶憑證的密碼找回連接以下：

從參數名猜想，u 可能爲 username、t 爲 token，爲減小複雜性，測試發現，刪掉 u 參數及值也可正常重置密碼，因此，可忽略 u 參數，重點關注 t 參數。

連續 5 次獲取重置連接，從郵件中提取 5 個 t 參數值以下：

仔細觀察發現變化點以下：

能夠看出，t 參數值的 5～8位、最後 4 位，按 2 的增量呈現遞增變化。

分析清楚憑證的變化規律，要重置任意帳號就輕鬆了。好比，要重置普通帳號 admin 的密碼，能夠先觸發找回攻擊者帳號的密碼，獲取 t 爲 52df773f24ac5b651d288d42，而後觸發找回 admin 的密碼，t 未知，再次觸發找回攻擊者帳號的密碼，獲取 t 爲 52df774d24ac5b651d288d54，根據前面分析得知的變化規律，普通帳號的 t 的 5～8 位必定是 [7740, 774c] 間的偶數，後 4 位範圍必定在 [8d44, 8d52] 間的偶數。幾回枚舉即可得有效 t 參數值：

案例3：基於時間戳生成的 token

是一道在線 CTF 題目：

「忘記密碼」功能是攻擊點，嘗試重置 admin 的密碼：

對應請求與應答爲：

除了提示已發送重置郵件外，並沒有其餘信息。嘗試重置其餘帳號 yangyangwithgnu：

得到重置 URL 信息 http://lab1.xseclab.com/password1_dc178aa12e73cfc184676a4100e07dac/reset.php?sukey=8135f8b07653b2cbc3ec05c781a29591&username=yangyangwithgnu，訪問後提示重置成功。那麼，如今的狀況是，admin 的重置 URL 無顯示，其餘帳號的 URL 有顯示，只要拿到 admin 的重置 URL，極可能就能看到 flag。

上面重置 URL 中 sukey 參數引發個人注意，顯然它就是重置憑證。將其值 8135f8b07653b2cbc3ec05c781a29591 先用 base64 解碼無果，後將其進行 MD5 解密獲得明文 1530342360：

貌似 unix 時間戳，驗證之：

果真，重置憑證是對當前 unix 時間戳進行 MD5 加密所得。

那麼，能夠設計這樣一種攻擊模型，達到重置任意帳號密碼的目的：

1. 第一次找回 yangyangwithgnu 的密碼，得到重置 URL，其中 sukey 參數含有時間戳信息；
2. 第二次找回 admin 的密碼，暫時雖沒法得到重置 URL，不要緊，服務端是已經生成好了；
3. 第三次又找回 yangyangwithgnu 的密碼，得到重置 URL，其中 sukey 參數含有時間戳信息。
4. 以第1、三次得到的時間戳做爲時間區間，因爲整個過程都在短期內完成，因此，能夠輕鬆暴破出第二次的時間戳。

經過以上思路1-3步驟，得到 admin 的時間戳在 [1530347130, 1530347161] 中，基於以前得到的重置 URL 格式，咱們能夠構造出 admin 的密碼重置 URL 相似 http://lab1.xseclab.com/password1_dc178aa12e73cfc184676a4100e07dac/reset.php?sukey={md5(unix_timestamp)}&username=admin。接下來，我將該 URL 放入 intruder 中進行暴破，將 unix_timestamp 定義爲枚舉變量：

以 [1530347130, 1530347161] 爲字典，並設置 MD5 加密算法做爲載荷預處理：

很快暴破出 admin 的重置 URL，併成功拿到 flag：

修改返回包繞過登陸

密碼找回流程通常包括獲取短信驗證碼、校驗短信驗證碼是否有效、設置新密碼等三個步驟。在第二步，校驗短信驗證碼是否有效的結果應保存在服務端，某些網站未在服務端保存而是錯誤地將結果狀態值下發客戶端，後續又依靠前端 JS 判斷是否能夠進入第三步，那麼，更改應答包中的狀態值，可重置其餘用戶的密碼。

這個漏洞常常出如今APP中，其主要緣由是對於重置密碼的的驗證是看response數據包，因爲以前的案例沒有截圖，只能畫個流程圖給你們演示一下。

【案例】

下面是找回密碼的一個流程，輸入正確的用戶名，跳到第二步，這時須要輸入短信驗證碼，這裏咱們隨意輸入一個短信驗證碼：123456，而後抓取服務端返回的信息以下所示。

簡單分析發現，驗證碼校驗經過時服務端並未向客戶端 set-cookie，猜想服務端並未記錄校驗狀態，是否進入設置新密碼頁面徹底是由前端 JS 基於應答狀態決定的，那麼，即使我沒有短信驗證碼，經過將服務端下發給客戶端的校驗狀態從「失敗」改成「成功」，也能成功重置找回帳號密碼。

把回包中false改成true後，便可繞太短信驗證碼驗證，結果以下圖所示。

【修復建議】

1. 服務端對驗證碼進行驗證，結果爲true時直接跳到下一步，無需向客戶端單獨返回驗證結果；
2. 服務端校驗短信驗證碼後應經過 cookie 記錄狀態，不該在前端經過狀態參數判斷；
3. 輸入新的密碼，而後提交到服務端，服務端應對當前用戶名、手機號、短信驗證碼進行二次匹配驗證，都爲true時，才能夠修改爲功。

此處爲了深刻理解漏洞原理和修復方案，咱們來了解下兩個概念：服務端跳轉和客戶端跳轉。

【場景描述】

你到一個機關辦事，一個是辦事窗口的那我的很不客氣地說，這個事你別找我，你找xxx窗口，而後你本身跑到xxx窗口，那個窗口的人直接給你辦了；還有一個是窗口的人和你說，你等下，他本身跑去找另外一我的溝通一番，而後跑回來給你辦了。

此處前者就是redirect重定向（客戶端跳轉），後者即是forward轉發（服務端跳轉）。

【概念解析】

服務器端跳轉：又稱爲內部跳轉，當客戶端向服務器發送一個請求，請求當前資源時，這個資源在服務器內部跳轉到另外一個資源，再向客戶端發送一個響應（即客戶端只產生了一次請求）。

(服務端)JSP重定向格式：

response.sendRedirect("path");

客戶端跳轉：又稱爲外部跳轉，當客戶端向服務器發送一個請求，請求當前資源時，這個資源向客戶端發送一個去請求其餘地址的迴應。客戶端再根據這個地址去進行下一次請求（即客戶端產生了兩次請求）。

(客戶端)JSP轉發格式：

request.getRequestDispatcher("path").forward(response,request)

【總結】進行登陸密碼驗證、密碼重置等系統核心高風險操做的時候，在驗證成功後須要跳轉頁面的狀況下，要儘量在服務器端控制頁面跳轉！不要將頁面跳轉的邏輯代碼部署在客戶端JS代碼中，不然可能被非法用戶經過篡改服務器響應包從而繞過驗證！簡而言之，不要分步校驗，服務器一旦驗證成功，直接跳轉進入下一步操做，不要等待客戶端的信息進一步回傳！