前言

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 判斷而已;前端也只需改造個別按鈕，例如發帖按鈕，像點贊這種按鈕就沒必要保護了。