白帽子挖漏洞日記之指定型XSS

各位信息安全大神們，大家好！我準備在這篇文章中跟大家分享一些我在最近一次挖洞過程中的發現，並與安全社區一同分享我的挖洞經驗。

寫在前面的話

在這篇文章中，我準備跟大家討論一個我在Bugcrowd私人項目中發現的反射性XSS漏洞，幾乎該網站下的任何一個頁面都存在這種XSS漏洞，但是之前卻沒有被任何人發現。在本文中，我們暫且將該網站視作private-bounty.com。

挖洞過程

當我在對這個Web應用進行了一次簡單的觀察與分析之後，我發現了一個結點，其URL地址格式如下所示；

接下來，我對源碼進行了分析並嘗試定位「view」參數反映在Web頁面的什麼位置。原來，整個URL地址都存在於一段Javascript代碼中（Script標籤），但是其中的「view」參數以及相應的值卻不在裡面。

我查看到的反射值為：

其中的foo、bar和baz的值同樣會反射在頁面之中，但這些值都經過了適當的編碼處理，因此我無法對這些值進行解析。

接下來，我又嘗試在路徑地址中添加單引號，但它同樣會被Web應用進行編碼處理。由於這個網站會對用戶的輸入數據進行恰當的編碼處理，因此我們無法在這裡找到可用的XSS漏洞，於是我便繼續尋找其他的結點。

我在該網站的每一個結點都發現了 」utm_content=foo&utm_medium=bar&utm_source=baz」這種模式，而且都沒有其他參數被反射到頁面中。因此，我打算自己在該地址後面添加一個參數，看看我所添加的自定義參數是否會被反射到頁面上。但不幸的是，我並沒有成功。

接下來，我又嘗試添加了一個參數：utm_foobarbaz=xxxxx

添加後的地址格式如下所示：

但這一次我竟然成功了，這個值成功地被反射在了頁面上，原來這個Web應用只會將以「utm」開頭的參數反射到頁面之中。

所以我又進行了一次嘗試，嘗試使用這個參數值來實現XSS攻擊，但這個參數值還是會被Web應用編碼。

接下來我所做的最後一次嘗試就是在參數名本身中注入一個Payload來觸發XSS漏洞：

BOOM!!!!!!!這一次我終於成功了！這一次，這個以「utm」開頭的參數名並沒有被編碼，並且成功反射到了頁面之中。

想必大家也知道接下來的結果了，我們成功觸發了一次警告彈窗。

總結

我們可以從這一次挖洞經歷中學到的是，我們有的時候可以嘗試在參數名本身中注入Payload，或者對參數名進行fuzzing操作。本文所介紹的情況相對來說是比較特殊的，因為這個Web應用並不會對特殊關鍵字（「utm」）進行編碼，因此我們從參數名入手實現了一次XSS攻擊。

* 參考來源：noob，FB小編Alpha_h4ck編譯

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

本站內容充實豐富，博大精深，小編精選每日熱門資訊，隨時更新，點擊「搶先收到最新資訊」瀏覽吧！

請您繼續閱讀更多來自 白帽子黑客 的精彩文章: