如何理解上傳Word文件形成存儲型XSS路徑

如何理解上傳Word文件形成存儲型XSS路徑，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

在滲透測試過程中，每當(dāng)看到目標測試網(wǎng)站存在上傳功能時，總會激起我的好奇心。如果能夠走運的話，若目標網(wǎng)站服務(wù)器是PHP或ASP架構(gòu)，而且上傳功能沒作后綴過濾，這樣就能導(dǎo)致可以直接上傳反彈腳本形成控制。如果這招行不通，我會嘗試上傳一個HTML頁面去觸發(fā)我自己設(shè)置的客戶端javascript腳本形成XSS攻擊。我就分享一個上傳docx文件形成存儲型XSS漏洞的實例。

測試上傳功能

剛好在某次Web測試工作中，我發(fā)現(xiàn)目標網(wǎng)站上傳功能中，用一個未授權(quán)用戶即可上傳自己的文件，該上傳功能中允許用戶上傳.docx文件：當(dāng)把這種.docx文件上傳之后，它還能被下載。通過比較發(fā)現(xiàn)，上傳成功的文件uploaded.docx和服務(wù)器上其對應(yīng)的可下載文件downloaded.docx之間存在著一些不同，也就是說，文件上傳成功之后，在提供下載之前，服務(wù)器會對這個上傳文件進行一些處理操作，之后，再提供下載。

用來上傳的文件必須是一個有效的.docx文件，那基于瀏覽器的解析顯示來說，它可能會把它轉(zhuǎn)換為html格式來顯示，那我能不能把它后綴作個更改呢？所以我先來試試在POST請求中把.docx后綴更改為.html看看：

當(dāng)這個.html文件上傳之后，向服務(wù)器請求這個文件后，服務(wù)器會把其Content-Type頭默認為text/html，這樣的話，瀏覽器會把這個文件解析為HTML執(zhí)行：

插入XSS Payload

這樣，我就想到了把XSS Payload捆綁到一個像下圖這樣的.docx壓縮文件中去。由于這是.docx經(jīng)直接把后綴更改為.zip的壓縮格式文件包樣例，我需要確定在上傳或Web解析過程中某些不會被轉(zhuǎn)儲更改的區(qū)域，最后，我發(fā)現(xiàn)了這種docx變zip壓縮格式包中的某些文件路徑會保持原樣，像下圖這樣，我把其中的Settings.xml文件名加上了一長串字母好待區(qū)分。之后，再把這個zip格式后綴還原為docx格式，用UItraEdit查看hex代碼，再在保持原樣的區(qū)域中覆蓋掉一些字節(jié)，插入我自己設(shè)置的JavaScript XSS代碼：

上傳時，服務(wù)器能正常接收這個經(jīng)過構(gòu)造的.docx文件，在HTTP POST過程中，我把它的后綴更改為.html后綴進行了最終上傳：向服務(wù)器請求這個文件時，它能被服務(wù)器解析為HTML文件，其中包含了完整的之前插入的XSS Payload代碼：當(dāng)然瀏覽器解析之后，也能成功執(zhí)行其中插入的XSS Payload：為了對這種XSS攻擊進行混淆隱蔽，攻擊者可以在其中加入一個包含URI統(tǒng)一資源標識符的隱藏iframe框架，能對受害者產(chǎn)生迷惑效果，像下圖這樣：

防護措施

這樣的效果對于開發(fā)者來說應(yīng)該采取以下手段來進行限制。

文件上傳之前，在服務(wù)器端驗證上傳文件格式是否為.doc或.docx有效格式；

嚴格限制Content-Type頭，對Content-Type頭或特定后綴格式更改過的上傳文件須保持與上傳文件相同的Content-Type頭信息；

控制文件下載時的其它操作情況，添加響應(yīng)標頭:“Content-Disposition: attachment”，以防止在瀏覽器中內(nèi)嵌顯示文件；

過濾掉所有包含HTML標簽的上傳，因為docx可經(jīng)壓縮篡改其中包含的HTML文件。

看完上述內(nèi)容，你們掌握如何理解上傳Word文件形成存儲型XSS路徑的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！