有哪些前端安全編碼規范

本篇內容主要講解“有哪些前端安全編碼規范”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“有哪些前端安全編碼規范”吧!

1. 跨站腳本攻擊（Cross Sites Script）

跨站腳本攻擊，Cross Site Script（簡稱 CSS或）。指黑客通過“HTML注入”篡改了網頁，插入了惡意的腳本（主要是JavaScript腳本），從而在用戶瀏覽網頁時，控制用戶瀏覽器的一種攻擊。

了解了什么是XSS，那你一定想知道，它有什么危害以及如何去防御

這里羅列一張列表：

•  掛馬

•  盜取用戶Cookie。

•  釣魚攻擊，高級的釣魚技巧。

•  刪除目標文章、惡意篡改數據、嫁禍。

•  劫持用戶Web行為，甚至進一步滲透內網。

•  爆發Web2.0蠕蟲。

•  蠕蟲式掛馬攻擊、刷廣告、刷瀏量、破壞網上數據

•  其它安全問題

常見的跨站腳本攻擊也可分為：反射型XSS、存儲型XSS、DOM Based XSS

下面針對這三種常見的類型做具體的分析

1.1 反射型XSS--也可被稱為是HTML注入

反射型XSS，也稱為"非持久型XSS"簡單的把用戶輸入的數據"反射"給瀏覽器，即黑客往往需要誘使用戶"點擊"一個惡意鏈接攻擊才能成功，用戶通過點擊這個惡意鏈接，攻擊者可以成功獲取用戶隱私數據的一種方式。如："盜取用戶Cookie信息"、"破壞頁面結構"、"重定向到其他網站"，盜取內網IP等。

那么既然反射型XSS也可以是HTML注入，那么它注入的關鍵自然也就從前端的HTML頁面開始下手：

1. 用戶能夠與瀏覽器頁面產生交互動作（輸入搜索的關鍵詞，點擊按鈕，點擊鏈接等等），但這些都需要去誘使用戶去操作，說起來容易，做起來難。  2. 用戶輸入的數據會被攻擊方拼接出合適的html去執行惡意的js腳本，這樣的過程就像是"一次反射"

1.2 存儲型XSS

存儲型XSS，也稱為"`持久型XSS`"，它與`反射型XSS`不同之處在于，它會將用戶輸入的數據"存儲"在攻擊方的服務器上，具有很強的"穩定性"。  例如：訪問某黑客寫下的一篇含有惡意JavaScript代碼的博客文章，黑客把惡意腳本保存到服務端。

1.3 DOM based XSS

從效果上來說，也是"反射型XSS"，單獨劃分出來，是因為其形成是通過修改頁面的"DOM節點"形成的XSS。  例如：通過修改DOM節點上的綁定方法，用戶無意間通過點擊、輸入等行為執行這些方法獲取到用戶的相關信息

1.4 如何去檢測是否存在XSS

一般方法是，用戶可以在有關鍵字輸入搜索的地方輸入<script>alert(123)</script>后點擊搜索，若彈框出現展示123，說明存在XSS漏洞，這就說明前端并沒有對用戶輸入的內容過濾處理。

1.5 XSS的攻擊方式

1.Cookie劫持

通過偽裝一些`圖片和按鈕`等，誘使用戶對其操作，使網頁執行了攻擊者的惡意腳本，使攻擊者能夠獲取當前用戶的Cookie信息

2.構造GET和POST請求

若某攻擊者想刪除某網站的一篇文章，首先獲得當前文章的id，然后通過使用腳本`插入圖片`發送一個`GET請求`，或`構造表單`，`XMLHTTPRequest`發送`POST請求`以達到刪除該文章的目的

3.XSS釣魚

`釣魚`這個詞一般認識是起源于`社會工程學`，黑客使用這個這門學科的理念思想，在未授權不知情的情況下誘騙用戶，并得到對方對方的姓名、年齡、郵箱賬號、甚至是銀行卡密碼等私人信息。  比如："某用戶在某網站（已被攻擊）上操作黑客偽造的一個登錄框，當用戶在登錄框中輸入了用戶名（這里可能是身份證號等）和密碼之后，將其信息上傳至黑客的服務器上（該用戶的信息就已經從該網站泄漏）"

4.獲取用戶真實的IP地址

通過第三方軟件獲取，比如客戶端安裝了Java環境（JRE），則可通過調用`Java Applet`的接口獲取客戶端本地的IP地址

1.6 XSS的防御方式

1.HttpOnly

原理：瀏覽器禁止頁面的Javascript訪問帶有HttpOnly屬性的cookie。（實質解決的是：XSS后的cookie劫持攻擊）如今已成為一種“標準”的做法

解決方案：  JavaEE給Cookie添加HttpOnly的方式為：  response.setHeader("Set-Cookie","cookiename=value; Path=/;Domain=domainvalue;Max-Age=seconds;HTTPOnly");

2.輸入檢查（XSS Filter）

原理：讓一些基于特殊字符的攻擊失效。（常見的Web漏洞如XSS、SQLInjection等，都要求攻擊者構造一些特殊字符）  * 輸入檢查的邏輯，必須在服務端實現，因為客戶端的檢查也是很容易被攻擊者繞過，現有的普遍做法是兩端都做同樣的檢查，客戶端的檢查可以阻擋大部分誤操作的正常用戶，從而節約服務器的資源。  解決方案：  檢查是否包含"JavaScript"，"<script></script>"等敏感字符。以及對字符串中的<>:"&/'等特殊字符做處理

3.輸出檢查

原理：一般來說除了富文本輸出之外，在變量輸出到HTML頁面時，使用編碼或轉義的方式來防御XSS攻擊  解決方案：  *   針對HTML代碼的編碼方式：HtmlEncode  *   PHP：htmlentities()和htmlspecialchars()兩個函數  *   Javascript：JavascriptEncode（需要使用""對特殊字符進行轉義，同時要求輸出的變量必須在引號內部）  *   在URL的path（路徑）或者search（參數）中輸出，使用URLEncode

4.更嚴格的做法

除了數字和字母外的所有字符，都使用十六進制的方式進行編碼

2. 跨站點請求偽造（Cross Sites Request Forgery）

跨站點請求偽造，指利用用戶身份操作用戶賬戶的一種攻擊方式，即攻擊者誘使用戶訪問一個頁面，就以該用戶身份在第三方有害站點中執行了一次操作，泄露了用戶的身份信息，接著攻擊者就可以使用這個偽造的，但真實存在的身份信息，到某網站冒充用戶執行惡意操作。

但是，攻擊者只有預測到URL的所有參數與參數值，才能成功地偽造一個請求（當然了，他可以在安全站點里以自己的身份實際去操作一下，還是能拿到參數的）；反之，攻擊者無法攻擊成功

我們可以總結，完成一次CSRF攻擊，必須滿足兩個條件

•  用戶登錄受信任網站A，并且在本地生成Cookie

•  在不登出網站A的情況下，訪問有害網站B

2.1 CSRF的原理

CSRF攻擊是攻擊者利用**`用戶身份`**操作用戶賬戶的一種攻擊方式  如電影速度與激情5中吉賽爾使用內褲獲取巴西大佬指紋，最后成功使用偽造指紋的手法打開保險柜，CSRF只不過是網絡上這個手法的實現。

2.2 CSRF的攻擊方式

1.瀏覽器的Cookie策略

瀏覽器所持有的策略一般分為兩種：  Session Cookie，臨時Cookie。保存在瀏覽器進程的內存中，瀏覽器關閉了即失效。  Third-party Cookie，本地Cookie。服務器在Set-Cookie時指定了Expire Time。過期了本地Cookie失效，則網站會要求用戶重新登錄。

* 在瀏覽網站的過程中，即使瀏覽器打開了Tab頁，Session Cookie都是有效的，因此發起CSRF攻擊是可行的。

2.P3P頭的副作用

"P3P Header"是 "W3C" 制定的一項關于隱私的標準，全稱是 "The Platform for Privacy Preference"（隱私偏好平臺）  如果網站返回給瀏覽器的 HTTP 頭包含有 P3P 頭，則在某種程度上來說，將允許 瀏覽器發送第三方 Cookie。在 IE 下即使是"<iframe>"、`<script>`等標簽頁將不再攔截第三方 Cookie 的發送。主要應用在類似廣告等需要跨域訪問的頁面。

3.GET，POST請求

* 這里有個誤區  大多數 CSRF 攻擊，都是通過 <img> 、 <iframe> 、 <script> 等帶 src 屬性的標簽，這類標簽只能發送一次 GET 請求，而不能發送 POST 請求，由此也有了認為 CSRF 攻擊只能由 GET 請求發起的錯誤觀點。 構造一個 POST 請求，只需要在一個不可見的iframe窗口中，構造一個form表單，然后使用JavaScript自動提交這個表單。那么整個自動提交表單的過程，對于用戶來說就是不可見的。

2.3 CSRF的防御方式

1.驗證碼

原理：  CSRF攻擊過程中，用戶在不知情的情況下構造了網絡請求，添加驗證碼后，強制用戶必須與應用進行交互  *  優點：簡潔而有效  *  缺點：網站不能給所有的操作都加上驗證碼

2.Referer Check

原理：  * 利用HTTP頭中的Referer判斷請求來源是否合法  * Referer首部包含了當前請求頁面的來源頁面的地址，一般情況下Referer的來源頁就是發起請求的那個頁面，如果是在iframe中發起的請求，那么對應的頁面URL就是iframe的src  *  優點：簡單易操作（只需要在最后給所有安全敏感的請求統一添加一個攔截器來檢查Referer的值就行）  *  缺點：服務器并非什么時候都能取到Referer          1.很多出于保護用戶隱私的考慮，限制了Referer的發送。          2.比如從HTTPS跳轉到HTTP，出于安全的考慮，瀏覽器不會發送Referer

3.使用Anti CSRF Token

原理：把參數加密，或者使用一些隨機數，從而讓攻擊者無法猜測到參數值，也就無法構造請求的 URL，也就無法發起 CSRF 攻擊。  例子（增加token）：  *  比如一個刪除操作的URL是：`http://host/path/delete?uesrname=abc&item=123`  *  保持原參數不變，新增一個參數Token，Token值是隨機的，不可預測  *  http://host/path/delete?username=abc&item=123&token=[random(seed)]  *  優點：比檢查Referer方法更安全，并且不涉及用戶隱私  *  缺點：          加密          1. 加密后的URL非常難讀，對用戶非常不友好          2. 加密的參數每次都在改變，導致用戶無法對頁面進行搜索          3. 普通參數也會被加密或哈希，將會給DBA工作帶來很大的困擾，因為數據分析常常需要用到參數的明文              token          1. 對所有的請求都添加Token比較困難

需要注意的點

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泄露）

2.4 XSRF

當網站同時存在XSS和CSRF漏洞時，XSS可以模擬客戶端瀏覽器執行任意操作，在XSS攻擊下，攻擊者完全可以請求頁面后，讀取頁面內容中的Token值，然后再構造出一個合法的請求

3. 點擊劫持（ClickJacking）

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

比如，程序員小王在訪問A網頁時，點擊空白區域，瀏覽器卻意外打開了xx新葡京賭場的頁面，于是他在A網頁打開控制臺，在空白區域發現了一個透明的iframe，該iframe嵌入了一個第三方網頁的URL

3.1 點擊劫持防御方式

1.X-Frame-Options HTTP響應頭是用來給瀏覽器指示允許一個頁面能否在`<frame>、<iframe>、<object>`中展現的標記  #### 有三個可選的值  1.  DENY：瀏覽器會拒絕當前頁面加載任何frame頁面（即使是相同域名的頁面也不允許）  2.  SAMEORIGIN：允許加載frame頁面，但是frame頁面的地址只能為同源域名下的頁面  3.  ALLOW-FROM：可以加載指定來源的frame頁面（可以定義frame頁面的地址）  2.禁止iframe的嵌套  if(window.top.location !== window.loaction){window.top.location === window.self.location}

4. 其他安全問題

4.1 跨域問題處理     當服務端設置 'Access-Control-Allow-Origin' 時使用了通配符 "*",允許來自任意域的跨域請求，這是極其危險的  4.2 postMessage 跨窗口傳遞信息      postMessage 允許每一個 window（包括當前窗口、彈出窗口、iframes等）對象往其他的窗口發送文本消息，從而實現跨窗口的消息傳遞。并且這個功能不受同源策略限制。      必要時，在接受窗口驗證 Domain，甚至驗證URL，以防止來自非法頁面的消息。實際上是在代碼上實現一次同源策略的驗證過程。接受窗口對接口的信息進行安全檢查。    4.3 Web Storage      Web Storage 分為 Session Storage 和 Local Storage。      雖然受同源策略的約束，但當存有敏感信息時，也可能會成為攻擊的目標。

5. 總結

1.  謹慎用戶輸入信息，進行輸入檢查（客戶端和服務端同時檢查）

2.  在變量輸出到HTML頁面時，都應該進行編碼或轉義來預防XSS攻擊

3.  該用驗證碼的時候一定要添上

4.  盡量在重要請求上添加Token參數，注意Token要足夠隨機，用足夠安全的隨機數生成算法 

到此，相信大家對“有哪些前端安全編碼規范”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！