安全建設-攻防思路及實踐（一）

原文鏈接：https://mp.weixin.qq.com/s/mnHGLZ_e3tWkxCL-DPAAvQ

背景

以前挖國內src時的一個套路：

通過"尋找管理后臺 + 尋找api接口 + burp驗證api接口"來找未授權api

找到未授權api后，根據api功能就能造成不同危害：

比如利用"重置密碼接口"來重置管理員密碼，然后登陸后臺

比如利用"查數據接口"獲取數據

個人覺得這個套路比較好用，原因在于：

沒有攻擊payload，waf、nids等安全設備比較難檢測（雖然可能按照訪問404頻率和比例等特征封禁）

"管理后臺對外開放"和"api接口未授權訪問"，個人感覺這兩個風險在企業里很難靠"技術手段"完全杜絕

大部分檢測工作可以用工具完成

也有不好的地方，在于：

整個流程沒有完全自動化，需要人工做重復性的事情，比如判斷是否是管理后臺

詳細過程

怎么找"管理后臺"？大概分三步：

* 第一步篩出可能的管理后臺地址
* 第二步將首頁截圖保存成本地
* 第三步人工瀏覽截圖

第一步篩選管理后臺地址的策略包括：

* 域名中包含關鍵詞，直接當作后臺管理系統
* 30x跳轉地址包含關鍵詞
* 響應html中包含table標簽（因為有可能后臺管理首頁就存在未授權訪問，數據展示時會用到table標簽）
* 判斷頁面是否是vue框架寫的（因為很多開發喜歡選擇用vue來做管理系統）

腳本代碼：https://gist.github.com/leveryd/334b719e253261ffd0abfd161e499ae7

怎么找api接口？

從js文件文本中找，策略如下：

* 將js代碼中字符串常量提取出來
* 字符串常量匹配 `/[\w\d\-./]+` 且不以 // 字符開頭，認為是api路徑
* 字符串常量匹配 `[\w\d\-]+/[\w\d\-./]+` 且不以 / 字符開頭，認為是api路徑

腳本代碼：https://gist.github.com/leveryd/465d19610d5fcf99199beb9284cd6f8c

這種方式不需要前端存在sourcemap泄漏。

當然如果前端有sourcemap信息就更好，這樣可以利用 利用sourcemap還原前端項目-瀏覽器插件這種工具還原前端項目，代碼閱讀性更好一些。接著對前端項目做代碼審計，有可能在前端代碼中看到 啥token、啥功能比較特殊的api接口（比如上傳文件）。

怎么使用burpsuite驗證api接口？

將找到的api接口放到burpsuite批量驗證，根據 響應狀態碼、響應長度、響應內容 來判斷是否有未授權的api接口。

測試過程中可以變換請求方法：GET、POST、PUT

確認存在未授權接口后，再人工從前端js中找參數值利用。

成果

[評級高危-順豐某系統后臺API接口未做認證導致用戶信息泄漏]

[評級高危-順豐某系統未授權導致獲取后臺管理權限，可查看大量訂單信息]

[評級高危-字節某業務線后端接口未授權訪問]

[評級中危-騰訊廣告后臺接口未認證]

[評級低危-后臺API接口存在未授權訪問(可增刪改數據)]

安全管理與技術

對于"管理后臺對外開放"和"api接口未授權訪問"這兩類風險，在企業安全建設中是怎么防范的呢？

怎么減少"管理后臺對外"安全風險？

根據個人有限的經驗來總結，管理上包括如下手段：

* 公司發布安全紅線：禁止后臺開放到公網訪問
* 安全意識的宣導

技術上包括如下手段：

* 統一認證登陸
* 周期性對資產做掃描，識別"管理后臺"
* 從流量層面識別"管理后臺"

業務上包括如下手段：

* 后臺訪問白名單限制
* 后臺登陸多因素認證MFA（短信二次認證、rsa token等）

比如能看到的，滴滴很多后臺管理業務都接入了統一認證登陸，對于我來說就比較難進一步測試。

不過上面的手段都并不一定管用，各種手段自身也有設計缺陷、安全漏洞等。

比如我前公司的統一認證平臺 統一認證登陸出現過一個設計上的漏洞。

正常的業務場景是：它支持釘釘登陸，員工在web頁面輸入郵箱后，釘釘app會收到一個確認登陸鏈接。員工點擊確認鏈接后，web端就會驗證通過，進入到后臺系統。

有白帽子收集一些部分員工郵箱，就在web頁面填收集到的郵箱。結果有部分員工點擊了釘釘上收到的"確認登陸鏈接"消息，幫助"攻擊者"進到了后臺系統。

另外還聽我同事給我分享的案例，他遇到某些有多因子認證的系統時，加x-forwarded-for請求頭偽造內網ip就繞過去了，原因是面向內部的系統去掉了"多因子認證"。

至于安全意識的宣導、安全紅線到底有多大作用，這感覺更不好衡量。

怎么減少"api接口未授權訪問"安全風險？

根據個人有限的經驗來總結，技術上包括以下手段：

* 依賴開發人員的代碼安全質量
* 零信任架構的實施

零信任應用的兩個場景包括了 用戶訪問服務 和 服務之間互相訪問 時的認證鑒權，而"用戶登陸后臺訪問數據"恰好就是"用戶訪問服務"這個場景。

總結

驗證了這個老套路在國內還是能挖到洞的。

站在攻擊方的角度來看，現有每一步的安全策略可以優化，比如可以詳細調研一下后臺系統的分類，比如為什么開源的cms后臺和前臺經常是在一個域名下，而企業里的后臺系統為什么經常是單獨的訪問方式？

整個流程或許也可以優化到完全依賴工具產出報警，就像 一種針對Webpack等前端打包工具構建的網站的自動化測試思路（附開源項目）一樣。雖然沒有用過這個項目，但是看文章介紹感覺有不少實戰上的細節和經驗。