自己接過的一個項目,不過其實是客戶自己在使用的一個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漏洞。
系統安全運維
系統安全運維
安全圈
合天網安實驗室
系統安全運維
安全牛
LemonSec
瀟湘信安
系統安全運維
D1Net
系統安全運維
系統安全運維