一、簡(jiǎn)介

眾所周知，HTML5是W3C制定的新一代HTML語(yǔ)言標(biāo)準(zhǔn)。HTML5的一些新功能，也帶來(lái)了一些安全挑戰(zhàn)。

接下來(lái)我們要去講解一些標(biāo)簽和攻擊。

二、HTML5 新標(biāo)簽

2.1 新標(biāo)簽的XSS

HTML5 定義了一些新標(biāo)簽，新事件，這些可能帶來(lái)新的XSS攻擊。

之前我們?cè)谥v述XSS攻擊時(shí)，使用的是script標(biāo)簽

<script>alert(0)</script> 

HTML5添加了音視頻的標(biāo)簽，而這些標(biāo)簽又有一些有趣的屬性，例如poster、autofocus、onerror、formaction、oninput，這些屬性都可以用來(lái)執(zhí)行javascript。這會(huì)導(dǎo)致XSS攻擊。

例如：

<video src="https:xxxxxx" onloadedmetadata="alert(document.cookie)" ontimeupdate="alert('XSS攻擊')"></video>

2.2 iframe的sandbox

iframe標(biāo)簽一直以來(lái)為人詬病。一些XSS、clickJacking等攻擊中都能看到它的身影。

HTML5為iframe元素增加了sandbox屬性，防止不信任的Web頁(yè)面執(zhí)行某些操作，例如訪問(wèn)父頁(yè)面的DOM、執(zhí)行腳本、訪問(wèn)本地存儲(chǔ)或者本地?cái)?shù)據(jù)庫(kù)等等。

sandbox可以通過(guò)參數(shù)來(lái)支持更精準(zhǔn)的控制。有下面的幾個(gè)值可以選擇

""：應(yīng)用以下所有的限制。
allow-same-origin：允許 iframe 內(nèi)容被視為與包含文檔有相同的來(lái)源。
allow-top-navigation ：允許 iframe 內(nèi)容從包含文檔導(dǎo)航（加載）內(nèi)容。
allow-forms：允許表單提交。
allow-scripts：允許腳本執(zhí)行。

sandbox是專門為iframe而定制的一個(gè)屬性，現(xiàn)在對(duì)瀏覽器兼容來(lái)說(shuō)不能完美兼容。但只是一個(gè)簡(jiǎn)單的代碼在寫的時(shí)候建議加入’sandbox’。還是起到一定的安全作用的。

但是這個(gè)安全策略又會(huì)帶來(lái)另外的風(fēng)險(xiǎn)，例如ClickJacking攻擊里阻止Javascript腳本的運(yùn)行來(lái)繞過(guò)Javascript的防御方式。

2.3 Link Types:noreferrer

在HTML5中為<a>標(biāo)簽和<area>標(biāo)簽定義了一個(gè)新的Link Types:noreferrer。即標(biāo)簽指定noreferrer后，瀏覽器在請(qǐng)求該標(biāo)簽指定地址時(shí)不添加Referer。通過(guò)Referer，可能會(huì)泄露一些敏感信息。

<a href="xxx" ref="noreferrer">test</a>

2.4 Canvas的使用

Canvas可以說(shuō)是HTML5中最大的創(chuàng)新之一。Canvas標(biāo)簽讓Javascript可以在頁(yè)面中直接操作圖片對(duì)象，也可以直接操作像素，構(gòu)造出圖片區(qū)域。

通過(guò)Canvas自動(dòng)破解驗(yàn)證碼，最大的好處時(shí)可以在瀏覽器環(huán)境中實(shí)現(xiàn)在線破解，大大降低了攻擊的門檻。

三、其他安全問(wèn)題

3.1 CORS

瀏覽器實(shí)現(xiàn)的同源策略限制了腳本的跨域請(qǐng)求。但互聯(lián)網(wǎng)趨勢(shì)是越來(lái)越開放的，因此跨域訪問(wèn)的需求也越來(lái)越迫切。

CORS主要是通過(guò)對(duì)被請(qǐng)求資源站點(diǎn)設(shè)置 Access–Control-Allow-Origin 的響應(yīng)頭來(lái)實(shí)現(xiàn)的，也就是比如：

a.com 需要通過(guò)ajax方式訪問(wèn)b.com 的資源，那么就可以對(duì)b.com 的HTTP 響應(yīng)設(shè)置

Access–Control-Allow-Origin：http://a.com 

這樣來(lái)允許a.com

帶來(lái)便捷的同時(shí)往往伴隨著安全問(wèn)題。對(duì)于開發(fā)者來(lái)說(shuō)，通常不喜歡通過(guò)白名單的形式去使用這些安全策略。因?yàn)橐馕吨坏┬略鲆粋€(gè)網(wǎng)站又得修改策略，所以一般采用通配符，即Access–Control-Allow-Origin：*，允許所有來(lái)源的請(qǐng)求。這就意味著同源策略的失效，導(dǎo)致一些攻擊或者信息泄露。

這類問(wèn)題的防御其實(shí)也相對(duì)比較簡(jiǎn)單，比如對(duì)于跨域請(qǐng)求應(yīng)該驗(yàn)證身份，驗(yàn)證數(shù)據(jù)有效性等，確實(shí)是正常用戶的跨域請(qǐng)求，再進(jìn)行對(duì)應(yīng)處理。

3.2 postMessage----跨窗口傳遞信息

我們之前提到，利用window.name來(lái)跨窗口、跨域傳遞信息。實(shí)際上，window這個(gè)對(duì)象幾乎不受同源策略的限制的，很多腳本攻擊都巧妙的利用了window對(duì)象這一特點(diǎn)。

postMessage允許每一個(gè)window（包括當(dāng)前窗口、彈出窗口、iframe等）對(duì)象往其他的窗口發(fā)送文本信息，從而實(shí)現(xiàn)跨窗口的消息傳遞。這個(gè)功能是不受同源策略限制的。

在使用postMessage時(shí)，有兩個(gè)安全問(wèn)題需要注意

必要時(shí)，可以接收窗口驗(yàn)證Domain，甚至驗(yàn)證URL,以防止來(lái)自非法頁(yè)面的消息
如果將消息寫入innerHTML,甚至直接寫入script中，則可能會(huì)導(dǎo)致XSS攻擊的產(chǎn)生。所以在接收敞口不應(yīng)該信任接收到消息，而需要對(duì)消息進(jìn)行安全檢查

3.4 Web Storage

開發(fā)者可以為應(yīng)用創(chuàng)建本地存儲(chǔ)，存儲(chǔ)一些有用的信息。例如LocalStorage可以長(zhǎng)期存儲(chǔ)，而且存放空間很大，一般是5M，極大的解決了之前只能用Cookie來(lái)存儲(chǔ)數(shù)據(jù)的容量小、存取不便、容易被清除的問(wèn)題。由于是瀏覽器本地存儲(chǔ)，那么意味著一旦重要、敏感數(shù)據(jù)采用這種存儲(chǔ)方式，而其API都是通過(guò)Javascript提供的，這樣攻擊者可以通過(guò)XSS攻擊竊取信息，例如用戶token或者資料。

這里主要應(yīng)該避免存儲(chǔ)敏感數(shù)據(jù)，還有就是把對(duì)應(yīng)的數(shù)據(jù)放在不同域里，比如會(huì)話ID應(yīng)該存儲(chǔ)在sessionStorage，相對(duì)于localStorage，sessionStorage會(huì)在瀏覽器窗口或者標(biāo)簽頁(yè)關(guān)閉后刪除。