網站後台」空降」了一個管理員

新的一年開始了，發點小福利。無意間發現了一個影響phpcms最新版本的漏洞。最近我一個使用phpcms框架搭建的系統，無故多出了一個超級管理員。確定不是出於本意添加的，然後聯想到可能是這個框架中可能是存在SCRF漏洞，但是去看添加管理員的數據包的時候貌是有防CSRF的字元串，那麼這個管理員從哪裡來的呢？

然後我去分析了一下後台中可能存在SCRF的地方，能在不知不覺中被CSRF的點也只可能是在前台提交的數據，在後台能看到的地方，可能只有友情鏈接這裡了，然後我進一步的去分析了一下。

這是申請鏈接的入口，這裡輸入的數據會在後台顯示。這裡我們提交一個數據，然後抓包看一下。

這裡調用了link模塊我們看一下這個模塊的功能

這裡可以看到對我們提交的一些參數做了安全過濾，也就是我們直接想往後台插入惡意數據基本上是不可能的。接著往下看，下面就是直接入庫的操作。

可以看到這裡正常插入了，而已數據也是正常的，到這裡為止都是正常的。接下來就是看哦我們在後台讀取這些數據的時候有沒有問題。

同樣的我們找到後台讀取資料庫數據的代碼

這裡直接在資料庫中得到了表中的數據，這裡非管理許可權是不能操作的，這裡也不存在什麼問題，接著往下跟數據包的流向。

可以看到這裡載入了一個link_list文件，這裡繼續跟一下。這裡將要向頁面輸出的數據列印出來看一下。

這裡看起來都是正常的，但是在分析數據包的時候發現響應包中出現了一段對url處理的JS。這裡就出現了問題，這裡遍歷了所有的a標籤，並在a標籤的href屬性值後面全部添加了pc_hash欄位。

經過這段JS處理之後的我們之前提交的鏈接變成了如下的格式：

那麼這個鏈接就存在很大的問題了，這裡在訪問你之前提交的超鏈接時會將這個參數以GET方式攜帶過去。這裡就造成了會話憑證的泄露。

然後在自己的伺服器中寫一個接收參數的頁面

然後將你本地的鏈接提交到後台審核

然後當管理員去審核你提交的鏈接時你就可以拿到這個防csrf的字元串了，那麼就可以做很多事情了。

本文僅供學習研究，正在使用該程序的站長要注意一下這個問題。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！