ZZCMS v8.3二階注入之一次小心的試探
*本文原創作者：丶樓蘭，本文屬FreeBuf原創獎勵計劃，未經許可禁止轉載
萌新入坑PHP程式碼審計中╭(°A°`)╮選了這個易上手CMS，費盡心思審計出了一個有趣的二階注入，滿意的睡了，第二天打算寫文件的時候，竟然發現……
0×00 漏洞程式碼
使用者在釋出資訊時,儘管對POST資料使用了addslashes函式，但是由於editor引數可控仍舊可以插入構造好的Payload
/user/zxsave.php 第51行：
在檢視使用者釋出的資訊時,會查詢文章id所對應的相關資訊。
/zx/show.php 第36行：
會根據該資訊id，需要具備的檢視資訊的使用者組級別（groupid）來進行判斷,如果groupid不為0，並且檢視資訊時需要花費積分時，那麼便會呼叫Payif函式。
/zx/show.php 第155行：
如果使用者積分多餘檢視資訊的積分時，那麼便會：
- 減去檢視者對應的積分（根據cookie裡面的Username引數）；
- 增加發布者對應的積分（根據檢視文章對應資訊裡面的editor欄位）；
/zx/show.php 第92行：
例如：
1.正常模式下：editor=admin,$jifen=10時，那麼第二條查詢語句便是：
update zzcms_user set totleRMB=totleRMB+10 where username = 'admin'
如果 editor=’ and groupid=(select sleep(3)) — – 時，那麼第二條查詢語句便是：
update zzcms_user set totleRMB=totleRMB+10 where username = '' and groupid = (select sleep(3)) -- -'
此時我們便可根據頁面所響應的時間，來判斷查詢語句是否成功了。
0×01 利用漏洞
可以看到普通使用者的groupid是1。
在釋出資訊是可以選擇vip使用者才能檢視或者高階會員檢視，或者直接在BurpSuite中修改groupid為2，並設定檢視積分為大於0的值：
在檢視該資訊時可以看到，添加了限制：
此時將editor設定為咱們的Payload：
此時在檢視資訊時便可以看到響應時間的異常：
我們最後傳入資料庫的SQL語句如下，可以看到，這樣的話我們每執行一次查詢語句便加不了10積分，而檢視資訊卻需要10積分，這樣說來，執行一次Payload需要十積分，經過測試，最少也是1分，這…也太豪了。
update zzcms_user set totleRMB=totleRMB+10 where username = TEag1e” and groupid = (select sleep(3)) — -’
經過我思考後，我將and邏輯運算子替換為了or邏輯運算子，醬紫的話，便可以減10，加10了，一分錢不花了
然後說一下我遇到的坑/新GET到的細節：
MySQL中在使用or邏輯運算子時，如果前面的條件已經將資料庫中的結果全部篩選出來了，那麼or後面的條件便不會在進行執行了。
例如：此時資料庫中全是groupid為1的使用者
如果SQL語句是：
update zzcms_user set totleRMB=totleRMB+10 where groupid = 1 or username = (select sleep(3))
那麼username後面的自查詢便不會執行，而如果使用的是and邏輯運算子的話，如果and前面的條件一條資料也查詢不出來時，那麼and後面的子查詢語句便也不會執行了。
0×02 第二天醒來
第二天，我正要寫文件的時候，發現咋就失敗了呢，等我回到資料庫中時，發現editor欄位竟然設定了50個字元的限制，好慘…
儘管有些失落，但是我並不氣餒，畢竟漏洞被忽略的多了已經習慣了。。
0×03 一些小東西
上文筆者已經說過了，看積分文章時：
1.減去檢視者對應的積分（根據cookie裡面的Username引數）；
2.增加發布者對應的積分（根據檢視文章對應資訊裡面的editor欄位）。
經過測試發現此處存在邏輯漏洞，未校驗cookie裡面Username引數，那麼釋出資訊時，將editor設定為咱們自己的使用者名稱，在檢視咱們構造的需要花費積分的資訊時，將cookie裡面的Username設定為其他使用者的使用者名稱。
那麼：每看一次，受害者便減掉10積分，而我們則加10積分。
看一下初始時兩個使用者的積分：
此時我們設定好前置條件後，在檢視該資訊時，將Username為test：
