前言

XSS 自動點按鈕有什麼危害？

在社交網路裡，很多操作都是通過點選按鈕發起的，例如發表留言。假如留言系統有 XSS，使用者中招後除了基本攻擊外，還能進行傳播 —— XSS 自動填入留言內容，並模擬點擊發表按鈕，於是就能釋出帶有惡意程式碼的留言。好友看了中招後，又傳播給他們的好友。。。從而形成蠕蟲擴散。

那麼有沒有一種機制，讓「發表留言」必須通過使用者的「真實點選」按鈕才能完成，而無法通過指令碼自動實現？這樣就能減緩蠕蟲傳播速度了。

實現

這個想法聽起來好像不可行：如果發表留言需要帶上使用者行為資訊，那麼 XSS 完全可以偽造一份行為資料，後端根本無法識別。

除非，使用者在點選按鈕時會產生一個「特殊資料」，讓後端校驗它。

但是，XSS 也可以直接呼叫按鈕元素的 click 方法，這樣效果和使用者點選仍然一樣。後端仍無法識別是「指令碼點的」還是「使用者點的」。

這麼看來，我們只能保護好這個「按鈕元素」，讓它沒法被 XSS 訪問到。例如，把按鈕放到一個 不同源的 iframe 裡，這樣就和 XSS 所在的環境隔離了！

不過，這樣還不夠。假如 XSS 破解了這個「特殊資料」的生成規則，那麼即可自己偽造一個，然後直接呼叫 HTTP 介面發表留言。所以，我們得找一個不可偽造的硬標識。

事實上，有個很簡單的辦法：我們乾脆讓 HTTP 請求也通過 iframe 傳送。這樣，後端通過 referer 即可檢測請求是否為 iframe 發起的。畢竟，XSS 是無法偽造 referer 的！

演示

注意：這個案例不是看能不能注入 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 判斷而已；前端也只需改造個別按鈕，例如發帖按鈕，像點贊這種按鈕就沒必要保護了。