前言
XSS 自動點按鈕有什么危害?
在社交網絡里,很多操作都是通過點擊按鈕發起的,例如發表留言。假如留言系統有 XSS 漏洞,用戶中招后 XSS 除了攻擊之外,還能進行傳播 —— 它能自動填入留言內容,并點擊發表按鈕,即可發出帶有惡意代碼的留言。好友看了中招后,又傳播給他們的好友。。。從而形成蠕蟲擴散。
那么,有沒有一種機制,讓「發表留言」必須通過用戶的「真實點擊」按鈕才能完成,而無法通過腳本自動實現?這樣就能減緩蠕蟲傳播速度了。
實現
這個想法聽起來好像不可行。如果發表留言需要帶上用戶行為信息,那么 XSS 完全可以偽造一份行為數據,后端根本無法識別。
除非,用戶在點擊按鈕時會產生一個「特殊數據」,讓后端校驗它。
但是,XSS 也可以直接調用按鈕元素的 click 方法,這樣效果和用戶點擊仍然一樣。后端仍無法識別,是腳本點的,還是用戶點的。
這么看來,我們只能保護好這個「按鈕元素」,讓它沒法被 XSS 訪問到。例如,放在一個不同源的 iframe 里,這樣就和 XSS 所在的環境隔離了!
不過,這樣還不夠。假如 XSS 破解了這個「特殊數據」的生成規則,那么即可自己偽造一個,然后直接調用 HTTP 接口發表留言。所以,我們得找一個不可偽造的硬標識。
事實上,有個很簡單的辦法:我們干脆讓 HTTP 請求也通過 iframe 發送。這樣,后端通過 referer 即可檢測請求是否為 iframe 發起的。畢竟,XSS 是無法偽造 referer 的!
演示
Demo: http://www.etherdream.com/FunnyScript/anti-xssworm/
注意:這個案例不是看能不能注入 XSS,而是看能不能通過當前頁面的 JS 自動發留言!
另外,通過第三方服務器發表是不算的。這里為簡單,省略了登錄態;真實場合下,會話 Cookie 是 HttpOnly 的,無法被 JS 獲取到,也就無法讓第三方服務器代替發表。
細節:
1. 使用者加載 safebutton.js,引入 SafeButton 類
2. 使用者實例化 SafeButton 對象 A,創建出一個不同源的 iframe 作為按鈕界面
3. 用戶點擊 iframe 按鈕后,內部變量 S 置為 true,同時將點擊消息告知主頁面(postMessage)
4. 主頁面收到消息后,讓 A 產生 onclick 事件
5. 使用者將 HTTP 請求數據,通過 A 的 send 方法扔給 iframe
6. iframe 校驗內部變量 S:若為 true,則將數據通過 AJAX 發送;否則放棄
7. 服務器校驗 referer:若為 iframe 的地址,則繼續業務邏輯;否則放棄
8. iframe 收到 AJAX 返回后,將結果扔給主頁面
9. A 產生 onreceive 事件,其中包含 HTTP 返回結果
其中 No.6 的步驟最為關鍵。正是這一步,使得未經用戶點擊,XSS 強制扔給 iframe 的消息變得無效!
缺陷
當然,這個方案阻擋不了點擊劫持 —— XSS 可以把 iframe 元素放大至整個頁面,并設置全透明。
這樣用戶只要在頁面的任何位置點一下,iframe 的 S 狀態就變成 true 了,于是就能繞過 No.6。
結尾
當然,安全防御有勝于無。并且該方案的改造成本也不是很大,后端只是增加一個 referer 判斷而已;前端也只需改造個別按鈕,例如發帖按鈕,像點贊這種按鈕就沒必要保護了。
轉載請注明出處 AE博客|墨淵 ? 如何保護網頁按鈕不被XSS自動點擊
發表評論