檔案對話方塊

檔案上傳對話方塊是一直以來就存在的網頁控制元件。

到了 HTML5 時代，增加了更多的功能，例如支援檔案多選。Chrome 甚至還支援「上傳資料夾」這一私有特徵：

<input type="file" webkitdirectory />

在給使用者方便的同時，其安全隱患也逐漸出現。使用者平時在下載時，理所當然的彈出的是儲存對話方塊，因此常常不仔細看就做出了選擇。

這極有可能被攻擊者所利用。一些惡意網站在使用者點選下載時，故意彈出一個上傳對話方塊。只要使用者一疏忽，就把選中的資料夾給上傳了！

下載對話方塊

上傳對話方塊

當然，僅僅依靠預設的上傳，這種攻擊方式仍有較大難度。因為整個資料夾可能非常大，上傳需要很久的時間。

如果使用者等了半天也沒看見下載進度，或許就會重新整理重試，甚至放棄了。

選擇即授權

然而，HTML5 帶來了一個新的規範 —— File API，允許指令碼訪問檔案。

但由於沙箱限制，指令碼無法訪問任何一個本地檔案，除非使用者主動授權。如何授權？最常見的，就是「上傳對話方塊」了。

事實上，如今的上傳對話方塊，早已不是從前「選擇哪個檔案」的功能，而是「允許指令碼訪問哪個檔案」的許可權申請！只不過介面上沒有提示罷了。

例如，一個傳統的檔案上傳控制元件。當用戶選中檔案後，即可通過 File API 讀取檔案內容：

<input id="dialog" type="file" />
<script>
    dialog.onchange = function(e) {
        var reader = new FileReader();
        reader.onload = function() {
            console.log(this.result);
        };
        reader.readAsText(this.files[0]);
    };
</script>
 

或許你已注意到，File 位於files[]而不是file，這正是給資料夾預留的！

在 Chrome 裡，上傳控制元件只要加上 webkitdirectory 屬性，就變成資料夾選擇框。這時一旦使用者選中某個資料夾，瞬間就賜予指令碼訪問整個資料夾的許可權！

<input id="dialog" type="file" webkitdirectory />
<script>
    dialog.onchange = function(e) {
        var files = this.files;
        var table = {};

        for (var i = 0; i < files.length; i++) {
            var f = files[i];
            var dt = new Date(f.lastModified);

            table[i] = {
                path: f.webkitRelativePath,
                size: f.size,
                modified: dt.toLocaleString()
            };
        }

        console.table(table);
    };
</script>
 

演示

於是，使用者本想將檔案儲存在桌面上，結果卻將桌面上的所有資料，被攻擊者的指令碼拿到！

優化上傳

一旦指令碼可主動訪問，我們可以用更靈活的方式處理這些檔案，無需再用傳統落後的方式上傳。我們可以直接在前端分析出「有價值」的檔案，例如：

• 備註檔案、指令碼、批處理、電子表格等，很可能存有一些敏感資訊，而且體積小价值大，優先將其上傳；

• 圖片則可通過 canvas 縮放，先傳較小的縮圖。當接收端發現有意義時，再傳輸原檔案。

• 對於一些體積較大但意義不大的檔案，則可以直接忽略。

由於 HTTP 上傳是沒有壓縮的，因此在傳輸文字檔案時效率很低。我們可以藉助 Flash 內建的LZMA壓縮演算法，極大提升傳輸效率。如果不支援 Flash，也可以使用asm.js版的 LZMA 壓縮器，配合Worker執行緒在後臺壓縮和傳輸。

同時，將多個小檔案合併後再壓縮，可進一步提高壓縮率。再多開幾個連線，上傳速度即可大幅提升。

續點上傳

不過即使再優化，仍有傳不完的可能。因此，我們得將沒傳完的內容儲存起來，當用戶再次回來時，繼續傳輸。

得益於 HTML5 的 Storage API，這不難實現。

事實上，當用戶授權了某個資料夾時，我們首先要做的不是傳送，而是讀出資料夾內容，立即備份到 Storage 裡。畢竟，檔案的讀取需要使用者主動配合，機會是非常珍貴的；而 Storage 的訪問則無需任何條件。

當備份完成後，再從 Storage 裡一塊一塊的讀取、傳送、刪除。這樣，即使中途頁面重新整理或關閉了，下次回來時，仍能從 Storage 中繼續。

考慮到每個域的 Storage 容量有限，我們可以使用iframe嵌入多個不同域的頁面，然後通過postMessage進行資料的分發和彙總，這樣就不受容量限制了。

當然，能不能無限容量還得看瀏覽器策略，不然硬碟會被撐滿

將資料存放在 Storage 裡還有另一個好處，即使使用者永不回來，但資料仍持久儲存著。只要以後一旦進入其他的站點，只要是我們可控的，仍有機會繼續上傳。（例如將使用者引到我們佈置了 XSS 的站點上）

延長上傳

在之前《延長 XSS 生命期》 中介紹過，可以使用各種黑魔法來提升指令碼有效期。

利用這個原理，即使當前頁面關閉，其他關聯的頁面也能繼續上傳。事實上，除了文中提到的方法，如今還有一個新的 API —— SharedWorker，它可以讓 Worker 共享於多個頁面，只要有一個存在，執行緒就不會停止。可以讓續點時丟失的資料更少。

視覺欺騙

由於上傳控制元件有著獨特的介面，怎樣才能讓使用者不小心點到呢？萬能的方法是點選劫持（Clickjacking）。

不過本場景無需這麼麻煩，只需簡單的呼叫控制元件的click方法就可以了。

<a href="ed2k://|file|xxx.avi" id="download">高速下載</a>
<script>
    var uploader = document.createElement('input');
    uploader.type = 'file';
    uploader.webkitdirectory = true;

    download.onclick = function(e) {
        uploader.click();       // 彈出上傳對話方塊
        e.preventDefault();     // 遮蔽下載對話方塊
    };
</script>

演示

我們遮蔽超連結的預設行為，用上傳控制元件的點選事件取而代之，即可召喚出「資料夾授權」對話方塊了！

同時，為了不讓眼亮的人發現對話方塊上的破綻，我們使用一些第三方的下載方式，例如電驢、迅雷等等，讓人們誤以為就是這樣的。

當然，這只是一個小例子。只要頁面做的真實，下載內容引人入勝，使用者自然就會中招。

後記

本以為 webkitdirectory 的這個私有屬性很快就會放棄，至少是更強的安全提示。不過至少現在也沒更新，因此上網時還是要多加留心，看清楚了再做決定。

當然，這篇只是最早的「互動欺騙」探索。事實上，深入挖掘會發現可利用點遠不僅此。

如今的瀏覽器在視覺、音訊上的體驗已經非常完善，攻擊者甚至可以在網頁裡，高度模擬一個本地應用的互動效果。讓使用者誤以為是瀏覽器之外的程式彈出的介面，從而進行釣魚。