實戰 | 記一次對某SaaS平臺漏洞挖掘

自己接過的一個項目，不過其實是客戶自己在使用的一個SaaS平臺，也就是對SaaS平臺的測試本質上來說沒有嚴格授權。

由于沒有嚴格授權也就將測試范圍局限在了單個網站上，并沒有根據域名進行拓展。

Web應用信息

通過Burp發送一定請求包，可以得到服務器如下信息：

開發語言：ASP
開發框架：.NET 4.0.30319
由于使用的是ASP.NET開發框架，因此服務器中間件大概率是IIS了。
同理數據庫可能采用的是MSSQL
中間件：Tengine
支持的請求方法：GET、POST、OPTIONS

使用asp與aspx的字典對網站進行目錄掃描并沒有新發現：

其實比較有意思的是網站請求的URI是以.do結尾的，網上搜到的相關介紹都是說該后綴的文件是Java的，但是根據前面收集到的信息顯然是不合理的，結合后面一些遇到的URI，推測這是一種以.來分割的路由書寫格式。

CSRF漏洞

跨站請求偽造漏洞發生在用戶操作的時候，其原因在于沒有對請求進行“行為發起”判斷又或者允許跨域（不同鏈接的跳轉請求自動攜帶上cookie）導致身份認證功能被濫用。

web應用中涉及用戶操作的有：

微課上傳
資源上傳
文章發布
相冊上傳
視頻上傳
話題發布、回復、點贊、刪除
私信功能
關注、取消關注功能
個人資料修改、頭像修改、隱私設置功能
安全設置中的郵箱、手機綁定功能

漏洞復現：資料修改功能跨站請求偽造漏洞

這里開啟虛擬機，利用兩個賬號進行試驗，賬號AID為“中文”，賬號BID為“左卓”，利用BurpSuite攔截“中文”的個人資料修改請求：

這里僅修改UserName這個變量，因為后端會對UserNumb這個字段進行校驗，因此需要知道受害者的UserNumb這個字段是多少，但是其他功能點并不一定有該限制。

利用BurpSuite的CSRF構造功能生成相應的CSRF頁面：

構造相應頁面，讓受害者去訪問該頁面：

結果如下：

利用失敗了，當然失敗的原因也很簡單，之前提過阻斷CSRF的方式除了對請求的主動性進行驗證之外，還有就是附加數據（cookie）是否設置了httponly屬性來禁止跨域。

很不巧的是這里用于身份驗證的cookie EDUSSO就設置了httponly屬性來禁止跨域，不過這里還是有csrf漏洞。

前面在信息收集中我們也提到了，這個服務器是支持：get、post、options三種http的請求頭，此處我們利用BurpSuite的功能修改請求方式由post至get，再生成csrf的poc。

此時再去訪問：

可以看到此時訪問成功，但是提示修改的網校號不是自己的，后續只要修改一下網校號即可。

CSRF漏洞列表：

微課上傳
資源發布
話題刪除
私信
關注、取消關注
個人資料修改、隱私設置功能
安全設置中的郵箱、手機綁定功能
視頻上傳功能
不過這個視頻上傳功能處的CSRF利用局限性較大，需要知道視頻專輯處隨機生成的唯一識別ID才能夠上傳至指定的專輯。

以上功能點均存在類似的通過修改請求方式的CSRF漏洞。不過我也不清楚這里將post方式修改為了get方式之后就繞過了httponly限制的原理，這里標記一下，后面需要了解一下httponly的實現原理。

不存在CSRF的功能點大多都處理httponly的限制之外還手動添加了token 字段來驗證請求的主動性。

2.1 文章功能測試

2.1.1 我的文章功能模塊

在該功能模塊下共有：1、發布文章 2、編輯 3、刪除

1、文章發布功能測試

文章發布部分抓包情況如下：

GET方式的請求無法成功，其中TypeID為文章分類的ID識別發送人的是SESSION因此CSRF以及越權都沒有此類漏洞。

注意到了請求的連接名稱為：MyArticle.Post.data嘗試修改其中的Post為Get再發送請求，但請求失敗證明了后臺沒有相關功能，不能通過Get請求來發布文章。

AddTime參數能控制前臺顯示的時間，但是時間格式有嚴格限制，無法實現存儲型XSS。

文章的由唯一標識ID號來識別，無法通過參數來控制，故此處也無法實現存儲型XSS

測試通過文章標題的二次注入均無特殊回顯，刪除各參數后頁面回顯均無報錯，此處SQL注入漏洞不存在。

2、文章編輯功能測試

后臺通過id的方式來確定修改的文章編號：

經嘗試無法通過修改id的方式來實現越權，后續文章發布的接口與編輯文章相同，無更多漏洞。

3、文章刪除功能測試

功能的實現同樣是根據提供的文章ID來實現的，但是通過修改至他人的文章ID來測試越權功能發現文章刪除失敗。

同樣是無法實現通過Get請求來刪除文章，故此處希望CSRF的利用會失敗。

2.1.2 分類管理功能測試

分類管理功能同樣也三個主要功能：1、添加分類 2、編輯 3、刪除

1、添加分類功能測試

添加分類數據包數據如下：

同樣是通過POST傳遞參數，通過SESSION來確定用戶，因此并且通過服務器自動參數的ID來標識文章分類，因此這里不會有越權以及XSS。

但是此處可以通過GET方式來發送請求，繼續測試是否存在CSRF漏洞。

經測試，該處存在CSRF可以通過此種方式替他人創建文章分類。

2、編輯功能測試

編輯功能處的HTTP數據包請求如下：

是通過id來確定要修改的分類，同樣通過修改ID發現無法實現越權修改功能。

不過同樣，該功能點支持Post及Get方式參數數據，經過測試此處存在CSRF，但實現CSRF還需要知道分類ID，限制較大。

分類處來提供了一些預設置的不可修改的分類，通過修改ID為這些分類的ID希望能實現越權修改功能，發現也是不可行的。

3、刪除功能測試

刪除處的功能同樣是通過ID參數來定位數據的，依然支持通過Get方式發送請求，同樣不支持通過修改ID來刪除其他人的分類、刪除系統分類。

同樣具有CSRF漏洞。

2.2 微課功能測試

2.2.1 微課列表功能測試

此處功能包括：1、微課上傳 2、微課修改 3、微課刪除共三種功能

由于文件等靜態資源全是存儲在目標網站的CDN服務器上，故文件上傳文件相關的漏洞就沒有去測試了。

1、微課上傳功能

微課上傳功能的http數據包如下：

因為fileName[]這個屬性的值會被展示在前臺的DOM樹當中且無過濾，故此處存在XSS漏洞：

這里使用console.log("b1ak2")來進行JS腳本運行判斷，修改請求包相關字段如下：

控制臺顯示效果如下：

同樣，該請求支持Get方式，經過測試此處同樣存在CSRF漏洞。采用相同的方式，通過GET請求來完成CSRF，不過這次的功能點會彈出文件下載請求：

不過其中的內容是空的，此時不管是否下載CSRF攻擊已經完成了：

2、微課修改功能

該功能點前臺js代碼存在問題，修改之后的提交無法完成。

3、微課刪除功能

刪除功能處的HTTP代碼如下：

除了ID定位之外還加上了科目ID，必須要兩者同時匹配才能夠刪除相關資源，同樣支持Get方式傳遞http請求故同樣存在csrf漏洞，但偽造難度過大。

嘗試修改ID來刪除他人資源，但是此處進行了權限校驗，故不存在越權相關的邏輯漏洞。

2.3 資源功能測試

2.3.1 資源列表功能測試

同樣功能如下：1、上傳 2、修改 3、刪除

1、上傳功能測試

資源的功能同微課的功能及其相似，猜測大體功能框架是相同的，同樣也存在XSS、CSRF漏洞，此處不展示類似的細節了。

2、修改功能測試

同樣修改功能前端語句存在bug，功能無法正常運行。

3、刪除功能測試

與微課功能相同，具有權限驗證。不存在越權漏洞。

2.4 相冊功能測試

2.4.1 我的相冊

功能主要包括兩個：1、上傳圖片 2、新建相冊 3、編輯相冊 4、刪除相冊

1、上傳圖片功能測試

文件上傳功能的http請求包如下：

可以通過修改imgList屬性值來達到修改顯示名稱的作用，且該段數據可以插入到DOM樹當中，但是對雙引號有一定限制措施，嘗試了一下之后沒有找到有效的利用方式，不在這個功能點上死磕了。

此處同樣是通過categoryId來確定要上傳的相冊位置，替換為他人的相冊ID之后服務端會報錯，故此處并不存在越權漏洞，此處也支持Get方式傳遞數據故CSRF漏洞同樣存在。

2、新建相冊功能測試

新建相冊功能不支持Get方式發送請求，故此處不像之前一樣有CSRF漏洞

這里Name屬性的值會出現在DOM樹當中，同樣可以通過修改來達到存儲型XSS的目的，但是對這里有長度限制，不過這里出里共會在DOM當中出現3次，可以依靠這個來實現繞過也說不一定。

3、編輯相冊功能測試

同樣不支持Get方式發送請求，CSRF漏洞無望，數據包情況如下：

通過唯一身份識別的ID來定位相冊，這里通過修改ID來定位到其他用戶的相冊，雖然服務器端沒有報錯但是功能并沒有實現，越權漏洞失敗。

同樣存在類似的XSS注入點，可能存在XSS利用的情況。

4、刪除相冊功能測試

相冊刪除功能的http請求如下：

依靠的是唯一識別ID來定位相冊。

同樣，該功能支持Get形式傳遞請求則同樣存在CSRF漏洞。而修改至他人ID后服務器端處理出錯，也不存在邏輯漏洞。

2.5 視頻功能測試

2.5.1 我的視頻功能測試

該處包含三種功能：1、新建視頻專輯 2、編輯 3、刪除 4、上傳視頻

1、新建視頻專輯功能測試

該功能處http請求如下：

該處存在XSS，CategoryName與PicURL兩參數均存在存儲型XSS，修改相應參數即可。不過PicURL會判斷雙引號是否成對出現，不過采用1">alert(1)<"類似的格式來繞過即可

同樣，該處支持通過Get方式傳遞http請求故存在CSRF漏洞。

而此處定位用戶通過的是Session即無法測試相關的越權漏洞。

2、編輯功能測試

編輯功能處http請求如下：

是通過CategoryID來確定相冊的，本身功能頁面是和創建相冊相同的，相同漏洞此處不重復測試。

而相冊編輯功能中可以通過CategoryID來定位到其他用戶的相冊，故相冊編輯功能處存在邏輯越權漏洞。

3、刪除功能測試

相冊刪除處http請求如下：

是通過CategoryID來定位相冊的，可以通過Get方式發送http請求，推測此處同樣存在CSRF漏洞，經測試確實存在。

刪除功能同樣存在越權邏輯漏洞。

4、上傳視頻功能測試

上傳視頻功能處http請求如下：

同樣支持Get方式傳遞http請求，經測試存在CSRF漏洞。

此處識別相冊是通過CategoryID來識別的，同樣存在越權邏輯漏洞。

修改數據至如下：

前端共發型存儲型DOMXSS四個：

補充：功能疏忽

訪問其實也是一種功能，這里碰巧發現了：

相冊訪問頁面也是通過CategoryID來識別的，將該ID修改為他人相冊后可以成功訪問，此處存在水平越權邏輯漏洞。

2.6 動態功能測試

動態這里會展示自己關注的用戶上傳的資源，之前測試到的資源功能里的存儲型XSS會在這里生效：

動態功能如下：1、發布微博 2、點贊 3、評論 4、回復 5、分享 6、刪除

1、發布微博功能測試

微博發布處的http請求如下：

此處添加了token作為請求驗證，故CSRF漏洞失效，而評論數據是通過JSON格式來進行傳輸的，其中會過濾<>之前的全部內容，暫未想到有什么好的利用方法。

2、點贊功能測試

http請求包如下：

同樣是有token，且身份識別依靠的是SESSION故無CSRF及越權漏洞。

3、評論功能測試

同樣，身份識別是依靠SESSION且存在token對請求的唯一性進行驗證：

同樣，評論會過濾兩個尖括號之間的內容，并未想到好的過濾方式。

4、回復功能測試

回復功能采用相同的功能架構，不作贅述了。

5、回復刪除功能測試

同樣存在token對請求唯一性進行驗證，同時刪除他人回復會進行權限檢測：

6、分享功能測試

功能存在問題，不能正常執行

7、刪除功能測試

刪除功能http請求包如下：

同樣支持Get方式傳輸http請求，同樣存在CSRF漏洞。

對刪除功能進行了權限校驗，不存在越權漏洞。

2.7 話題功能測試

話題功能和動態采取的是同一套框架，這里不作贅述了。

2.8 私信功能測試

私信功能有兩個功能：1、回復消息 2、清除記錄

1、回復消息功能測試

回復的http請求如下：

能夠自主控制的只有接收方和發送內容，不過好在這里同樣可以通過Get方式傳遞http請求，故此處存在CSRF漏洞。

而回復的內容不在DOM樹當中，且尖括號中的內容會被過濾，暫未想到好的繞過方法。

2、清除記錄功能測試

請求的http數據包如下：

同樣支持Get方式發送請求，故此處同樣存在CSRF漏洞。而發送者由SESSIOIN來確定，無法偽造發送人。

2.9 關注功能測試

關注功能主要有：1、關注 2、取消關注 3、查找用戶

關注和取消關注功能之前測試過，存在CSRF漏洞，身份識別依靠的是SESSION，故也不存在越權漏洞

3、查找用戶

查找用戶方面最直接的聯想就是SQL注入，這里查找的關鍵詞只有一個keyword，對該參數使用fuzz排查之后并未發現有特殊的回顯，故判斷此處沒有SQL注入漏洞。

2.10 設置功能測試

2.10.1 個人資料功能測試

個人資料功能之前提到過csrf漏洞，此處不在贅述。

在測試相關功能中，會很自然的想到此處是否存在SQL注入漏洞，不過根據排查其他功能時候對SQL注入的測試，這個網站還是對相關漏洞防護功能做的挺不錯的，但是這個地方的SQL注入功能沒有關閉報錯信息，這導致雖然只能獲取少部分信息，但是一些異常操作還是能夠獲取到信息的。

該功能的http請求如下：

我們這里將UserName這個字段刪去之后數據庫會返回如下錯誤信息：

2.10.2 修改頭像功能測試

由于上傳的文件會被上傳至CDN服務器，且自動對文件進行重命名，所以這里針對文件名的XSS漏洞嘗試就失敗了。

2.10.3 安全設置功能測試

安全設置主要的功能有：1、安全郵箱 2、綁定手機 3、密碼

經過測試，郵箱、手機綁定存在邏輯漏洞，這兩處功能即使密碼錯誤的情況下也能夠修改綁定的郵箱、手機號，同時支持Get方式發送http請求，也就造成了邏輯漏洞。兩者配合即可在驗證碼有效期內修改受害人綁定的手機、郵箱賬號。

2.10.4 隱私設置功能測試

隱私設置功能主要用于設置各個功能他人的訪問權限，此處存在CSRF漏洞。