登陸框系列最後一篇，半年的準全職賞金獵人的生涯，算是水到渠成的一篇，這一篇每一個類型都將配一個這半年來我所發現的漏洞當作案例。

0×00 文章內容結構圖

0×01 管理後臺隱藏的註冊接口

很多系統的後臺會用一些本身存在註冊功能，但是在後續正式使用的時候，開發人員爲了圖省事，僅僅刪除前端顯示的操作。也就是說該系統註冊接口仍然存在，只是你在客戶端無法找到而已。

案例

這是某系統的管理後臺，除了我們所看到的以及HTML源碼，js代碼均爲發現其他有效接口。

此時，我手動將login修改爲reg，沒想到中獎了。

很簡單的嘗試，最終讓我獲得了2500元的賞金。

一般來說我會嘗試像reg、register、sign字段，這些字段直接記住手動測試即可，都沒必要用字典跑了。

再來看另一個案例：

這個時候我們就要靈活變通了，根據開發人員的命名規則來進行測試，此時我們應該嘗試的便是：Reg、Register、Sign。

0×02 目錄遍歷

當資產僅僅只有一個登陸框時，一定要花費兩秒鐘的時間來測試這個目錄遍歷漏洞，講真，真的只需要兩秒鐘。

案例

第一秒：直接按快捷鍵 Ctrl+U（查看頁面源代碼），講真，不要再右鍵點擊了，太慢。

第二秒：直接訪問 https://domain/static/ ，不要問我爲什麼直接訪問static目錄。這個漏洞的確認沒必要用路徑掃描器去掃。

此時只需要了兩秒鐘，一個目錄遍歷漏洞便確認了。後續的則是想辦法找敏感文件來擴大危害了。

最後，找到了該系統的備份文件，很常規的一個備份文件的目錄，backup。

不過這裏有趣的時，遇到了其他困難。

找到數據庫配置文件api\app\config\database.php

可以看到加密了，使用了網上的phpjm加密，解密比較費勁，不過過了一會我想到，根本沒必要解密。

通過封裝的數據庫文件可以知道database.php文件使用變量$db來存放配置信息。

我只需要新建一個文件，然後包含database.php文件，再打印出配置信息來即可。

除去後面代碼審計出來的漏洞以外，這個漏洞獲得了4000元的賞金。

0×03 三端邏輯處理不一致導致的問題

這裏的三端只是一個虛詞，並不是非得三端，可能是兩端，也可能是四端，只是這裏我的案例是三端的原因：web端、app端、小程序端。

就像是木桶原理，你的站點web端做的安全係數可能很高，但是你的app端、小程序端如果很爛的話，依舊可以讓人突破進去。

案例

首先這個站點我先發現的是web端，其次是app端，最後則是小程序端。

我在web端跟app端用了很多時間，最後突破點是小程序端，發現小程序端以後，則用了很短的時間。

Web端安全係數最高，在登陸時，用了rsa加密，沒法直接爆破，並且用了token校驗。我手動試了一下，沒法確定用戶名，只能得到一個【用戶名或密碼錯誤的提示】。

後來我發現了app端，發現app端有圖形驗證碼，並且是有效的圖形驗證碼，我試圖通過該apk文件包含的js代碼來入手，無果。

最終我發現了微信小程序端，在登陸時由於圖形驗證碼是客戶端刷新，因此可以直接進行數據包重放。

確認用戶名是否存在非常重要，這個時候我一般會先輸入一個一定不存在的用戶名進行嘗試，可以看到，竟然提示了【賬號不存在】，最終我通過該處枚舉出了多個用戶名。

然後我進行了簡單的爆破嘗試，未果，此時我拿着正確的用戶名去嘗試app端時，發現了另一個問題。

當輸入正確的用戶名時，竟然會將該用戶的基本信息返回過來，包括但不限於姓名，部門，密碼的md5值。

我用拿到的賬號密碼登陸成功了web端、app端、小程序端。

最終獲得了1400元的漏洞賞金。

0×04 從系統幫助文檔進行突破

當資產只有一個登陸框時，確認用戶名信息則顯得至關重要，通過系統的幫助文檔，可以快速的幫我們確定用戶名的規則及密碼的規則。從而可以有針對性的進行爆破。

案例

如下圖所時，這個系統我放棄了一次又一次，在登陸時會先校驗公司名是否存在，但是我卻連公司名都不知道，更不要說用戶名了。

我發現這個系統用的是非自研的系統，因此我通過蛛絲馬跡（恕我直言，我不能說），結合google語法，intitle:XXXX，發現了該系統的一個測試系統，該測試系統使用了另一個域名，於是我通過site該域名，發現了該系統的一個幫助文檔。

通過下圖，我獲得了，公司名的命名規則。

通過下圖，我獲得了密碼的規則，至少6位，2/3原則。

使用了正確的公司名後發現了，發現存在用戶名枚舉漏洞，然後我寫了一個腳本，原理就是三重循環。

公司名 – 用戶名 – 生成的該用戶符合規則的社工型字典。

很快，大約30秒，第一個用戶的密碼就出來了。

我使用的是用戶名+123456的形式，既符合規則，又好用。

登陸系統後發現了很多漏洞。最終也是獲得了6000元的賞金。

0×05 從js文件進行突破

講真，我是真的很喜歡讀js文件，因爲它經常給我帶來驚喜，接口信息、命名規則等頻率是極高的。

案例

如下圖，看到下圖的時候，我小心_髒噗通一跳，哇咔咔，竟然沒有校驗舊密碼。

於是我構造數據包。對了，有一個技巧，其實不用構造數據包，直接將我紅框標記的區域複製出來，粘貼到開發者工具，js的控制檯裏，然後替換userCode變量跟password變量回車抓包即可。

我推測存在admin用戶，果然推測成功。

最終順利登陸後臺，賺的2000元的賞金。

0×06 其他

當然還有很多其他類型的，如apk重編譯突破登陸限制、圖型驗證碼dos攻擊、歷史漏洞、Http Request Smuggling等。

我便不再說了，網上很多資料。打算完結了，也不會再寫啦。

0×07 綜合

說一個綜合的吧。我這個漏洞是利用了web端跟pc端處理邏輯不一樣，然後通過pc端js文件發現了密碼規則（這不是一個單純的名命規則）及可用來枚舉用戶名的接口來進行突破的。

案例

Web端非常安全，我通過fuzz目錄，xxxx.jsp，發現了該站點的一個app下載地址download.jsp。

這個PC端跟web一樣存在圖型驗證碼，只不過web端的圖形驗證碼無法繞過，但是pc端的圖形驗證碼可以通過刪除該字段的值進行繞過。

但是，不管用戶名是否存在，反饋都是一樣：賬號不存在或密碼錯誤。

這個站點我放棄了很多天，因爲js文件實在是太太太太大了，除了大還有別的障礙，總之就是一句話，讀起來費勁。

最終我還是一段代碼一段代碼的讀了。

如下圖，原始功能是，用戶改變自己的在線/離線狀態。

這個接口導致我可以在未登陸狀態下，通過賬戶名加在線（1）離線（0）來根據響應包判斷出用戶是否存在。

如果用戶名存在，那麼res的值爲1（即切換狀態成功），如果不存在那麼值爲-1

通過下圖，可以得知密碼的名命規則，字母+數字+特殊字符，最短8位。

這樣的密碼規則，確實難爆破，我心中一涼。

但是峯迴路轉的是，我看到了以下代碼。

於是我推測，可能是因爲後臺的某些功能，導致會存在不符合規則的密碼存在，使用這些不符合規則的密碼進行登陸時，依舊可以登陸成功。

window.loation.href= main_url;

於是我用枚舉出來的幾千個賬號，嘗試123456的密碼。最終成功登陸了PC端跟web端，結合其他福利獲得了2300元的賞金。

對了，再補充一下，通過刪除圖形驗證碼的值繞過校驗的截圖。

0×08 臨別

最後分享我師傅送我的一句話：在路上點滴挪步，不驕不躁。

對啦，容我再打一個小廣告，哈哈哈哈哈，喜歡相互分享的同學，很樂意各位加入我們米斯特安全團隊，這裏有着每個人各種各樣的分享。

*本文原創作者：丶樓蘭，本文屬於FreeBuf原創獎勵計劃，未經許可禁止轉載