本篇其實算之前安全整改話題的一點補充,對之前內容感興趣的可以走以下快捷通道:
背景
前不久某家客戶對我們提供的系統又進行了一輪安全測試,其中有一條我覺得很有意思,也算是刷新了我的認知,那就是“pdf預覽存在xss注入”,在此跟大家分享一波,也算是相互提醒。
復現問題
拿到安全報告以后我隨即使用了提供的pdf文件成功復現問題,果不其然一預覽瀏覽器就彈出一個提示框。
xss注入問題確實讓人心頭一震,按照以往的經驗接下來的滲透測試就會從簡單的alert替換成劫持session一類危險操作,所以修復工作刻不容緩。
原理解析
pdf執行js代碼於我而言確實是一件新鮮事,查閱了相關資料以后得知使用pdf編輯軟件可以直接植入js代碼,然而這並不是什么黑科技,屬於pdf早就支持的特性,以Adobe Acrobat DC為例,打開pdf可以直接編輯內容
從圖上可以看到pdf中植入的js代碼也執行了,接着我們看看是怎么植入的。
-
切換到工具
-
選擇JavaScript
-
看到pdf文檔上方多了JavaScript的操作按鈕
-
選擇文檔級JavaScript
-
點擊編輯按鈕修改js代碼
到這兒一段簡單的js代碼就算是植入到了pdf文件中,借助工具操作還是很便捷的,簡單看下這段代碼:
function test_alert() { app.alert('這是一個alert窗'); } test_alert();
不用過多解釋大伙應該都知道什么意思,唯一比較可疑的是app.alert,這里的app其實是pdf中的對象。
在我的印象中早期的瀏覽器沒有內置pdf viewer(這個沒有求證,只是憑記憶,如果說錯了請一定糾正我),需要先下載然后使用Adobe pdf reader等軟件查看,現在的瀏覽器大多都內置了pdf viewer可以讀取pdf的內容,也支持pdf中的js代碼。
自己的一點思考
過往的xss很容易聯想到session劫持,這次我也是想嘗試自己構造一個用例來加深理解,看了官方api和一些博客以后我有點絕望了,似乎沒有方法可以讀取cookie,session劫持之路暫時擱淺。
繼續查,繼續試,終於找到了突破口。
我假想了一個例子,有一個在線購書網站,賣家上傳pdf類型的書到網站,買家付費以后便可以在線閱讀,這里賣家上傳的書是含有釣魚鏈接的,釣魚鏈接的制作過程如下:
-
pdf編輯器可以在頁面上放置表單元素,比如input輸入框,本例使用輸入框;
-
為輸入框設置動作,類似於js中的onblur,onchange等,動作設置為打開網絡鏈接;
-
網絡鏈接設置為轉賬操作的url,比如onlinebook.com/transfer?toAccount=1002&money=1000
這不就是臭名遠昭的csrf(跨站請求偽造)嗎,雖不能劫持session,但我一套組合拳照樣掏空你的錢包。
千里之堤潰於螻蟻,任何一點漏洞都足以摧毀整個網站,安全問題,不容小覷。
修復
-
使用第三方的一些在線預覽組件,我測試了其中的幾個,會把pdf轉換成圖片顯示,所以不會有機會執行pdf中植入的js代碼;
-
徹底取消pdf的在線預覽,改為下載,由本地pdf reader查看,降低攻擊的可能性。
彩蛋
上周五有個客戶急匆匆的打來電話跟我們說:“快,看下網站是不是被黑了,怎么預覽了一個pdf,網頁的title顯示為用友軟件股份有限公司了。”
客戶和用友看似風馬牛不相及,怎么在這扯上關系了呢?瀏覽器標簽頁上展示的內容是html中的title,但這個是一個pdf,在哪里設置title?其實,pdf也是可以設置title的,依然以Adobe Acrobat DC為例,文件-屬性就可以編輯標題。
我懷疑客戶這個pdf應該是用了用友的辦公軟件生成的,標題被自動設置成了“用友軟件股份有限公司”,跟客戶一說,確實是虛驚一場。
推薦閱讀
https://opensource.adobe.com/dc-acrobat-sdk-docs/acrobatsdk/pdfs/acrobatsdk_jsdevguide.pdf
圖片拍攝於西安漢長安城遺址公園