前言

XSS 自動點按鈕有什么危害?

在社交網(wǎng)絡(luò)里，很多操作都是通過點擊按鈕發(fā)起的，例如發(fā)表留言。假如留言系統(tǒng)有 XSS 漏洞，用戶中招后 XSS 除了攻擊之外，還能進行傳播 —— 它能自動填入留言內(nèi)容，并點擊發(fā)表按鈕，即可發(fā)出帶有惡意代碼的留言。好友看了中招后，又傳播給他們的好友。。。從而形成蠕蟲擴散。

那么，有沒有一種機制，讓「發(fā)表留言」必須通過用戶的「真實點擊」按鈕才能完成，而無法通過腳本自動實現(xiàn)?這樣就能減緩蠕蟲傳播速度了。

實現(xiàn)

這個想法聽起來好像不可行。如果發(fā)表留言需要帶上用戶行為信息，那么 XSS 完全可以偽造一份行為數(shù)據(jù)，后端根本無法識別。

除非，用戶在點擊按鈕時會產(chǎn)生一個「特殊數(shù)據(jù)」，讓后端校驗它。

但是，XSS 也可以直接調(diào)用按鈕元素的 click 方法，這樣效果和用戶點擊仍然一樣。后端仍無法識別，是腳本點的，還是用戶點的。

這么看來，我們只能保護好這個「按鈕元素」，讓它沒法被 XSS 訪問到。例如，放在一個不同源的 iframe 里，這樣就和 XSS 所在的環(huán)境隔離了!

不過，這樣還不夠。假如 XSS 破解了這個「特殊數(shù)據(jù)」的生成規(guī)則，那么即可自己偽造一個，然后直接調(diào)用 HTTP 接口發(fā)表留言。所以，我們得找一個不可偽造的硬標識。

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

演示

Demo: http://www.etherdream.com/FunnyScript/anti-xssworm/

注意：這個案例不是看能不能注入 XSS，而是看能不能通過當前頁面的 JS 自動發(fā)留言!

另外，通過第三方服務(wù)器發(fā)表是不算的。這里為簡單，省略了登錄態(tài);真實場合下，會話 Cookie 是 HttpOnly 的，無法被 JS 獲取到，也就無法讓第三方服務(wù)器代替發(fā)表。

細節(jié)：

1. 使用者加載 safebutton.js，引入 SafeButton 類

2. 使用者實例化 SafeButton 對象 A，創(chuàng)建出一個不同源的 iframe 作為按鈕界面

3. 用戶點擊 iframe 按鈕后，內(nèi)部變量 S 置為 true，同時將點擊消息告知主頁面(postMessage)

4. 主頁面收到消息后，讓 A 產(chǎn)生 onclick 事件

5. 使用者將 HTTP 請求數(shù)據(jù)，通過 A 的 send 方法扔給 iframe

6. iframe 校驗內(nèi)部變量 S：若為 true，則將數(shù)據(jù)通過 AJAX 發(fā)送;否則放棄

7. 服務(wù)器校驗 referer：若為 iframe 的地址，則繼續(xù)業(yè)務(wù)邏輯;否則放棄

8. iframe 收到 AJAX 返回后，將結(jié)果扔給主頁面

9. A 產(chǎn)生 onreceive 事件，其中包含 HTTP 返回結(jié)果

其中 No.6 的步驟最為關(guān)鍵。正是這一步，使得未經(jīng)用戶點擊，XSS 強制扔給 iframe 的消息變得無效!

缺陷

當然，這個方案阻擋不了點擊劫持 —— XSS 可以把 iframe 元素放大至整個頁面，并設(shè)置全透明。

這樣用戶只要在頁面的任何位置點一下，iframe 的 S 狀態(tài)就變成 true 了，于是就能繞過 No.6。

結(jié)尾

當然，安全防御有勝于無。并且該方案的改造成本也不是很大，后端只是增加一個 referer 判斷而已;前端也只需改造個別按鈕，例如發(fā)帖按鈕，像點贊這種按鈕就沒必要保護了。