HTML5 安全問題解析

HTML5 安全問題解析

標籤： html html5 web安全

本文參考：

1. w3school:html5相關基礎知識（w3school.com.cn）

2. 51CTO的HTML5安全專題

3. FREEBUFF上有關HTML5的安全文章（FREEBUFF搜索關鍵詞：html5）

4. 相關技術博客和雜文（百度搜索關鍵詞：html5 安全）

---

文章概要：

1. html5相關新技術

2. 跨域資源共享（CORS）安全問題

3. 本地數據庫注入（Web Sql Injection）

4. 本地存儲風險（Local Storage and Session Storage）

5. js多線程（Web Worker）風險

6. Web Socket帶來的嗅探風險

7. 新標籤風險

8. 新API風險

---

正文：

---

0x01 html5相關新技術

1. XMLHttpRequest Level 2 (CORS)

XMLHttpRequest主要提供了js直接發送請求的接口，在老版本中有如下缺點：

• 只能支持文本數據傳送，其餘數據不可

• 沒有即時進度信息，只有完成與否的狀態

• 不能跨域傳輸，只能同域內進行傳輸

在新版本的XMLHttpRequest中（level 2），以上都獲得了實現，其中最關鍵的是能夠在服務器和瀏覽器自己的支持下進行跨域傳輸。

具體細節請參考：阮一峯的博客

2. 本地存儲

在html5以前，本地存儲只有cookie（flash cookie）這麼一種選擇，可是cookie的容量很小，而且安全性上得不到保障。
在html5中，新增了兩種存儲方式：local storage和session storage，local storage是永久性的存儲，大小大概是5MB, session storage時臨時的，瀏覽器關閉即刻清空。其實這兩個東西是一個東西，放在內存中是session storage，在文件系統中是local storage。

具體使用方法請見：w3school.com.cn

3. web sql（本地數據庫 已廢棄）

同時，html5提供了本地數據庫支持，默認是sqlite這一輕量級的數據庫，能夠存儲一些臨時資料或者緩存。

操做方式詳見此處

4. web worker（js多線程執行）

因爲js時單線程執行的，因此在h5以前，執行js是會阻塞UI的，h5實現了web worker這一機制，從而使得js也可使用子線程去執行任務從而不阻塞主UI線程了。

操做方式詳見此處

5. web socket （服務器推送機制）

因爲http時無狀態單鏈接的協議，因此在過去，只能是客戶端發送request，服務器響應response，如今h5實現了websocket這一機制，從而能夠保持長連接，服務器能夠主動推送信息到客戶端了。固然須要服務器支持websocket機制。
具體使用方式

6. 新標籤和新api

h5新實現了一些比較便捷的標籤和api，使得用戶對第三方插件的依賴能過有所減小，從而減小不可控安全問題。
好比<video>,<audio>,<canvas>等等。
同時實現了比較多的新的api，好比地理位置api，putstate等等。
具體請查看：w3school.com.cn

---

0x02 Ajax跨域資源共享（CORS）安全問題

1. 跨域資源請求的方式：

• ajax在以前是要嚴格遵照同源策略的，可是在h5中爲了提供更好的使用性，誕生了ajax跨域的方式-CORS。跨域資源共享是爲了解決跨域請求的問題的。

• 除了CORS這個方案，還有另外兩種跨域請求的方法，一個是使用jsonp的方式，一個是使用flash的跨域方案，經過服務器上的crossdomain.xml來控制跨域。

2. CORS的作法：

CORS的跨域方式是經過：Access–Control-Allow-Origin這個頭以及其餘的頭來實現的，客戶端跨域訪問一個服務器，服務器會肯定這個這個域名是否有權限來獲取資源，如有則返回一個帶有Access–Control-Allow-Origin頭的response以及資源。若無則返回一個權限錯誤：XMLHttpRequest cant load .....

3. 風險點：

（1）. 對Access–Control-Allow-Origin設置爲*,而且沒有攜帶會話認證，這樣子意味着信息被公開在全網。
（2）. http頭能夠僞造。http能夠僞造意味着http頭中的域名(origin)能夠是假的，因此跨域是要配合身份驗證進行的，因此跨域的時候記得帶上session id。
（3）. 就算是使用了session id，可是第三方有可能也會被入侵，從而致使源站信息泄露，因此CORS是一個很是危險的東西。
（4）. 內部信息泄露，內部成員打開一個evil website，致使我的會話信息泄露，那麼內部網站的數據將會泄露
（5）. 另外，不是設置了Access–Control-Allow-Origin，而且對請求站點作了權限控制，就能夠防止信息泄露，在返回權限錯誤的時候，請求的信息其實已經到了客戶端。
（6）. CORS默認不能攜帶會話信息，可是若是將withCredentials設置爲true，則能夠攜帶，因此這個屬性最好設置爲false。萬一須要設置爲true，請在Access–Control-Allow-Origin上設置具體的域名，不要使用 *。這是CORS的最後一層遮羞褲了，設置很差就裸奔了。

4. 防護姿式：

• 不要對Access–Control-Allow-Origin使用 *

• 要對跨域請求驗證session信息。

• 嚴格審查請求信息，好比請求參數，還有http頭信息。

5. 利用姿式：

CORS主要是提供了一種隱形的跨域數據傳輸方式，偷取信息用戶是不能感覺到的，主要是兩種利用方式。

1. 第一個是須要將跨域js植入到被攻擊的頁面，這樣子能夠劫持到對方的cookie等認證信息。這種方式就是經過一個xss或者sqli，將js植入目標服務器，這樣子就能夠將認證信息偷過來了，若是是存儲型就就更讚了，能夠實時更新認證信息。

2. 第二個是將跨域放在本身控制的網站上，經過用戶點擊來攻擊指定由CORS漏洞的服務器。這個要求目標服務器對CORS沒有設置好，有CORS配置漏洞。

3. 另外ajax跨域不存在問題了，那麼是否是CSRF也能夠更隱蔽的進行了呢

6. 參考：

51CTO h5安全專題
51CTO 文章

0x03 本地存儲安全問題

這裏的本地存儲主要指的是localstorage和sessionstorage。其餘的好比windows.history，png cache等等不作討論。

就如餘弦說的，localstorage是大勢所趨，由於隨着網站的複雜性升級，cookie最多隻能有4k，每一個網站只能存放30或者50個cookie，這樣大大制約了web的發展。因此localstorage和sessionstorage出現了（後面將不分開討論）。

使用方式：

localstorage使用只能經過js去進行寫入或者讀取，存放格式爲key-value格式，好比localStorage.set("key","value").這個意味着他沒有cookie那麼安全。

風險點：

1. js獲取，由於是隻能經過js設置和獲取，致使的結果是不能像cookie同樣設置httponly。因此能夠配合CORS來獲取網站的localstorage的信息。因此localstorage中不能存放敏感信息。

2. 由於在各大主流的瀏覽器中，除了opera採用base64加密，其餘都是採用明文存儲的，因此在存儲的時候最好在服務器端進行加密。

3. 還有一個，可能會被植入廣告追蹤標誌。

防護姿式：

1. 不要存放敏感信息。

2. 選擇合適的域存放合適的信息，好比一次過時的信息就放在sessionstorage中。

3. 對存放在其中的信息最好可以在服務端進行加密。

利用姿式:

1. 配合CORS或者XSS獲取本地存儲中的數據。

0x04 本地SQL安全問題

H5在以前引入了本地SQL這個東西，可是後面被廢除了，他的安全點和後臺數據庫的關注點差很少，就是要防止在數據中混入sql查詢指令。這裏再也不展開。

0x05 Web worker僵屍網絡風險

H5中「解決」了js單線程問題，提出了web worker機制，它爲js提供多線程支持，可是多線程帶來了一個很是可怕的危險-僵屍網絡。

使用方式：

var worker = new Worker("worker.js");
worker.postMessage("hello world");
worker.onmessage = function(){}

風險點：

風險點只有一個，那就是在用戶不知情的狀況下，使用pc端的資源往外發送大量的請求，若是受控的客戶端（殭屍）夠多，而且針對某一個目標發送，能夠形成應用層的DDOS。（雖然是異域，可是不須要CORS配合，由於CORS只是限制客戶端是否可以拿到服務器的數據，而不會限制發送這個事情）
其實這裏還有一個postMessage的問題，放到API風險那個小結。

防護姿式：

1. 不要訪問不安全的站點

2. 用戶注意觀察客戶端資源佔用狀況，發現某個頁面資源佔用反常就關掉。

利用方式：

很是清晰，寫一個webworker，而後注入到一些頁面中去，只要訪問這個頁面，web worker就開始工做。

0x06 Web socket 嗅探內部端口

H5的web socket 顛覆了傳統的http通訊方式（request-response），他經過創建一個長連接，讓服務器能夠隨時推送消息給客戶端，而不是採用輪詢的方式去作這個事情。

風險點

他是經過開啓另一個非80的端口去作這件事情。從而致使嗅探的可能性。

0x06 新標籤帶來的XSS風險

H5引進了不少新的標籤，好比<video><audio><cavans>等等，具體的能夠去w3school查看。
新標籤意味着以前指定的xss過濾或者轉義規則可能會不適用。

1. 新標籤

新的方式以下：

<video onerror=alert(1)><source>
<video><sourceonerror="javascript:alert(1)"
<video src=".." onloadedmetadata="alert(1)" ondurationchanged="alert(2)" ontimeupdate="alert(3)"></video>
<video><sourceonerrorsourceonerrorsourceonerrorsourceonerror="javascript:alert(1)「>
<videopostervideopostervideopostervideoposter=」javascript:alert(1)」>

待補充#todo

2. 新屬性

新方式以下：

<form id="test" /><button form="test" formaction="javascript:alert(1)">X
<form id=test onforminput=alert(1)><input></form><button form=test on formchange=alert(2)>X
<input onfocus=write(1) autofocus>

待補充#todo
更多可查看：HTML5 標籤安全

0x07 新API安全

1. postMessage

postMessage是web worker中的一個函數，它的做用是主線程給新線程post數據用的，可是有一個問題就是postMessage是不經過服務器的，那麼頗有可能形成DOM-based XSS。

防護方式
可是postMessage的防護點不在自己，而在onmessage上，onmessage中不能直接使用innerHTML相似的語句添加或者修改網頁。

利用方式：

postMessage("<script>alert(1)</script>");
worker.onmessage = function(e) {
    document.getElementById("test").innerHTML = e.data;
}

2. History API

H5在History API新增了兩個API：pushState()和replaceState(),這兩個方法能夠在不刷新頁面的狀況下添加或者修改歷史條目

• pushState(data,title [, url])
  他的做用是在瀏覽器歷史列表的站定添加一條記錄，一個是狀態，一個是標題，一個是URL（可選，同域）

• replaceState(data,tile [,url])
  參數和上一個相同，它的做用是更改當前頁面的歷史紀錄。

利用方式：
能夠利用他來假裝GET方法下的反射型xss。
好比，存在一個有漏洞的連接 http://www.foo.com/?a=1，能夠進行XSS注入，如：http://www.foo.com/?a=<script>alert(1)</script>

可是若是這麼直接寫在頁面上讓用戶點擊，通常都會發現有問題，因此能夠採用短連接的方式，假設上述連接轉換爲：http://www.foo.com/TqsjW，用戶應該會點過去了，可是點過去以後，URL欄中仍是原來的長連接，一樣會被發現。

可是這麼寫的話：

http://www.foo.com/?a=<script>history.pushState({},'',location.href.split("?").shift();alert(1))</script>

將他轉換成短連接，點擊以後，會轉換到http://www.foo.com/這個上面，因此就完美的隱藏了。