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