前言
最近主要在學JAVA，不過PHP審計相關的技能也不能生疏了，於是打算去找點代碼來審審，在CTFSHOW上找到了一款源碼，而且目前也沒有WP
那麼就開審罷
（因為這套系統使用量比較少，而且是好幾個月前提交的了，現在基本都給修好了，所以直接把這篇分析發出來了。）
框架分析
進來之後看到傳參，估計是個MVC架構
來看看源碼是怎麼實現的，index.php中接受了action、do、id、userid等傳參
繼續往下看，發現MV的不是很C，可能是系統比較簡單，直接把action的傳值放在switch里決定包含什麼文件。
點進一個文件看看，發現do的傳值決定了程序要進行的操作
所以這裡的action文件可以簡單的理解為控制器，do傳入的東西可以簡單地理解為要執行的方法。
權限控制以及SQL語句執行方式分析
在開始審計之前，我還想知道這套系統是用什麼方式來校驗用戶身份的，我發現了兩個比較重要的函數
沒有使用什麼取巧的判斷方式，這個我們是繞不過去的，並且鑒權失敗會直接exit()。那麼再看看sql語句的執行是怎麼實現的，這裡使用了query方法，這個方法在mysql類中定義，我們看看怎麼實現
如下圖，沒有額外的過濾，直接執行傳入的SQL語句，那麼猜測這套系統應該會存在SQL注入相關的問題
未授權訪問其一
剛剛我們分析了兩個權限控制函數If_rabc()和is_admin()，並且提到這兩個函數繞不過去，那麼我們需要找到一些不存在這兩個函數的方法進行調用。這裡先找到了一個，address控制器在傳入的do參數為空時可以觸發
這裡的display函數其實是用於加載視圖的，因為和本文關係不大而且比較複雜，所以不展開分析了。總之我們直接get傳入action=address，就可以訪問到通訊錄管理界面了
SQL注入其一
既然上述點的權限校驗不嚴格，那麼我們是否可以進一步利用呢？進一步分析代碼
可以看到，在要執行的sql語句中有三個變量，我們逐一分析看看是否會出問題。首先是$search變量，對於$search變量來說，首先系統會判斷是否POST傳入kewords，如果有的話，將其拼接至一個語句中
但是注意，這裡的kewords被魔術引號轉義了，並且拼接的語句里也有單引號，所以這裡我們是沒有操作空間的。
繼續往後看，下面的代碼又進行了一個判斷
這裡是判斷是否傳入time_strat和time_over，如果存在那麼又拼接到一個sql語句里，並且還會和我們上面的and name like 『%strip_tags(kewords)%』進行拼接。但是非常不幸，這裡用strtotime()函數進行了處理。
所以$search這個點算是徹底沒用了，那麼第二個點$pageNum呢？這個變量的值是這樣定義的
可以看到，儘管沒有過濾，但是它會被進行數字運算，這個點最終也無法利用。那麼只剩下$numPerPage這個可控變量了。
可以看到，如果我們沒傳入numPerPage，那麼其值為10。如果傳入了那麼就用我們傳入的值。儘管它也用魔術引號進行轉義了，但是並不影響我們直接執行SQL語句（因為沒有引號）
這裡有個小細節，首先這裡是limit注入，並且有order by，不能直接聯合注入，這裡嘗試使用 PROCEDURE ANALYSE()語句結合延時注入進行嘗試。
下面是正常傳參的返回時間
而傳入sql語句之後產生延時，說明該點存在延時注入
如下圖，可以使用sqlmap一把梭
任意用戶註冊（0day）
靠上面的sql注入比較水，主要是在limit後面注入還是有點麻煩，於是我又找到了一個沒有進行權限校驗的點，user控制器的add方法（添加用戶）
其實剛開始看到這個點，我還覺得不太能利用，主要是這裡，以為有Token校驗機制會比較棘手
但往上看了一下token的實現方法，實在是被蠢哭了
把$module、$timestamp的值和#$@%!^*拼接一下，md5加密之後就算token了，而且$module、$timestamp變量的值還是可控的。
那我們試着給module和timestamp傳入1，拼接之後就變成1#$@%!^*1，然後再對其MD5加密
然後POST傳入一下，如圖，如果不帶任何東西訪問的話就會提示非法數據來源
傳入構造好的token值就可以往後執行了
繞過了這裡就繼續往後看，其實後面也沒什麼好看的了。這裡把一堆值直接插入到了數據庫里
這些變量的來源都在上面，全都可控
唯一需要注意的就是這個$id，為什麼它需要注意，因為id在index.php中使用get傳入
因此這裡可以實現任意用戶添加
先來演示一下添加用戶，使用如下POC即可添加一個用戶名為SSS，密碼為test123的用戶
這還不是最騷的，最騷的是他後台隱藏密碼的圓點符是前端實現的，而用戶管理還能看到admin
可以直接看到md5加密後的admin密碼，不過解不出來，這裡姑且也算一個小漏洞罷。
後台XSS1（0day）
後台有好多點，從數據庫里取數據回顯到視圖上
直覺告訴我這種地方都容易出現XSS，試着改改上面任意用戶添加的POC。這裡是」><img src=1>的url編碼
如圖，成功實現存儲型XSS
那麼去代碼層面看看到底是怎麼產生的。這裡是user控制器，沒有傳入方法
如圖，這裡先是執行了上面的sql語句，然後執行了fetchAll()方法。開發者已經給出了fetchAll方法的功能
往後看到這個點調用的user_list.htm視圖，
跟進user_list.htm，不難發現，這裡的意思大概就是把$list變量的值（也即fetchAll函數執行結果）遍歷，也即我們之前寫入的那些用戶信息，然後輸出出來
這裡沒有任何過濾就進行了輸出，後台的大量視圖都存在這個問題。
後台XSS2（0day）
上述是存儲型XSS，看了一會代碼，我又發現了一些反射型XSS。注意看user_list.html視圖中的這個點。未經任何過濾就把time_start和time_over接收到的值輸出出來了，因為這裡使用的是$_REQUEST來接收參數，所以存在反射型XSS
構造如下Payload
address_list.htm同理
後記
這篇文章屬於代碼審計的練手之作，涉及到的漏洞原理都相對簡單。其實一開始我是有點被誤導的，因為題目給的條件是前台getshell，當時沒往sql注入去想，以為是命令執行或者代碼執行，再不濟也是文件上傳或者文件寫入，於是找到危險的命令執行函數一路往上跟，但是跟到最後都沒法利用，最後都沒有啥可控點。最後突然醒悟不一定非得要往rce的方向去挖，挖洞還是不能太死腦筋！最後也是靠這道題收穫了兩個通用型編號，屬於是意外之喜了。
推薦閱讀：
實戰 | 記一次1000美金的TikTok盲打XSS的漏洞挖掘
實戰 | 記一次挖掘到微軟的存儲型XSS漏洞的經歷
乾貨 | 最全的CTF練習網站和在線攻防網站總結
實戰 | 記一次23000美元賞金的漏洞挖掘
實戰 | 記一次Everything服務引發的藍隊溯源
原創投稿作者：L@2uR1te
留言列表