Web前端安全攻擊與防護

時間 2020-09-14

標籤 web 前端安全攻擊防護欄目 HTML 简体版

原文原文鏈接

最近在刷面經，遇到web安全問題老是隻知其一;不知其二，說不清楚，針對面試集中複習了web安全攻擊與防護手段，一直想總結下，今日開坑。javascript

博主參加過幾回網絡安全比賽，除了MISC主要就是web方向，遇到過一些web安全漏洞問題，發現安全漏洞也區分先後端。html

首先咱們要區分一下web的先後端安全問題：前端

前端安全：發生在瀏覽器、單頁面應用、Web頁面的安全問題，好比：跨站腳本攻擊XSS、CSRF攻擊、點擊劫持、iframe帶來的風險、不安全的第三方依賴包。java

後端安全：發生在後端服務器、應用、服務當中的安全問題，好比SQL注入漏洞。web

前端安全攻擊手段面試

（一）XSS（Cross-Site Scripting），跨站腳本攻擊。chrome

一種代碼注入方式, 爲了與 CSS 區分因此被稱做 XSS，其注入方式很簡單包括但不限於 JavaScript / VBScript / CSS / Flash 等。原理：惡意攻擊者在web頁面中插入一些惡意代碼。當目標網站、目標用戶瀏覽器渲染HTML文檔的過程當中，出現了不被預期的腳本指令並執行時，XSS發生，從而達到惡意攻擊用戶的目的。數據庫

跨站腳本攻擊有可能形成如下影響:後端

利用虛假輸入表單騙取用戶我的信息。
利用腳本竊取用戶的Cookie值，被害者在不知情的狀況下，幫助攻擊者發送惡意請求。
顯示僞造的文章或圖片。

根據攻擊的來源，XSS 攻擊可分爲反射型、存儲型和 DOM 型三種：跨域

反射型XSS：發出請求時，XSS代碼出如今URL中，做爲輸入提交到服務器端，服務器端解析後響應，XSS代碼隨響應內容一塊兒傳回給瀏覽器，最後瀏覽器解析執行XSS代碼。這個過程像一次反射，故叫反射型XSS。

一、攻擊者給用戶發送一個惡意構造了Web的URL。

二、用戶點擊並查看這個URL時，網站服務端將惡意代碼從 URL 中取出，拼接在 HTML 中返回給瀏覽器

三、用戶獲取到一個具備漏洞的HTML頁面並顯示在本地瀏覽器中，惡意代碼也被執行。

四、漏洞HTML頁面執行惡意JavaScript腳本，將用戶信息盜取發送給攻擊者，或者篡改用戶看到的數據，或者冒充用戶的行爲，調用目標網站接口執行攻擊者指定的操做。

反射型XSS防護：

1. Web 頁面渲染的全部內容或者渲染的數據都必須來自於服務端。

2. 儘可能不要從 URL，document.referrer，document.forms 等這種 DOM API 中獲取數據直接渲染。

3. 儘可能不要使用 eval, new Function()，document.write()，document.writeln()，window.setInterval()，window.setTimeout()，innerHTML，document.createElement() 等可執行字符串的方法。

4. 若是作不到以上幾點，也必須對涉及 DOM 渲染的方法傳入的字符串參數作 escape 轉義。

5. 前端渲染的時候對任何的字段都須要作 escape 轉義編碼。

function escape(str) {
  str = str.replace(/&/g, '&amp;')
  str = str.replace(/</g, '&lt;')
  str = str.replace(/>/g, '&gt;')
  str = str.replace(/"/g, '&quto;')
  str = str.replace(/'/g, '&#39;')
  str = str.replace(/`/g, '&#96;')
  str = str.replace(/\//g, '&#x2F;')
  return str
}

存儲型XSS：存儲型XSS和反射型XSS的差異僅在於，提交的代碼會存儲在服務器端，下次請求目標頁面時不用再提交XSS代碼，這樣，每個訪問特定網頁的用戶都會被攻擊。

持久型 XSS 漏洞，通常存在於 Form 表單提交等交互功能，如文章留言，提交文本信息等，黑客利用的 XSS 漏洞，將內容經正常功能提交進入數據庫持久保存，當前端頁面得到後端從數據庫中讀出的注入代碼時，剛好將其渲染執行。具體攻擊過程以下：

一、攻擊者將惡意代碼提交到目標網站的數據庫中。

二、用戶打開目標網站時，網站服務端將惡意代碼從數據庫取出，拼接在 HTML 中返回給瀏覽器。

三、用戶瀏覽器接收到響應後解析執行，混在其中的惡意代碼也被執行。

四、惡意代碼竊取用戶數據併發送到攻擊者的網站，或者冒充用戶的行爲，調用目標網站接口執行攻擊者指定的操做。

攻擊成功須要同時知足如下幾個條件：

POST 請求提交表單後端沒作轉義直接入庫。
後端從數據庫中取出數據沒作轉義直接輸出給前端。
前端拿到後端數據沒作轉義直接渲染成 DOM。

存儲型XSS防護：

1. 後端須要對提交的數據進行過濾。

2. 前端也能夠作一下處理方式，好比對script標籤，將特殊字符替換成HTML編碼這些等。

3. 純前端渲，把代碼和數據分隔開。渲染過程：瀏覽器先加載一個靜態 HTML，此 HTML 中不包含任何跟業務相關的數據；而後瀏覽器執行 HTML 中的 JavaScript；JavaScript 經過 Ajax 加載業務數據，調用 DOM API 更新到頁面上。

在純前端渲染中，咱們會明確的告訴瀏覽器：下面要設置的內容是文本（.innerText），仍是屬性（.setAttribute），仍是樣式（.style）等等。瀏覽器不會被輕易的被欺騙，執行預期外的代碼了。
但純前端渲染還需注意避免 DOM 型 XSS 漏洞（例如 onload 事件和 href 中的 javascript:xxx 等，請參考下文」預防 DOM 型 XSS 攻擊「部分）。
在不少內部、管理系統中，採用純前端渲染是很是合適的。但對於性能要求高，或有 SEO 需求的頁面，咱們仍然要面對拼接 HTML 的問題。

DOM型XSS：DOM型XSS是基於DOM文檔對象模型的一種漏洞,經過 HTML DOM，經過植入js代碼，形成dom的更改，所以形成了XSS-DOM漏洞，因此DOM類型的XSS多是反射型也多是儲存型。

DOM 型 XSS 跟前兩種 XSS 的區別：DOM 型 XSS 攻擊中，取出和執行惡意代碼由瀏覽器端完成，屬於前端 JavaScript 自身的安全漏洞，而其餘兩種 XSS 都屬於服務端的安全漏洞。攻擊過程以下：

攻擊者構造出特殊的 URL，其中包含惡意代碼。
用戶打開帶有惡意代碼的 URL。
用戶瀏覽器接收到響應後解析執行，前端 JavaScript 取出 URL 中的惡意代碼並執行。
惡意代碼竊取用戶數據併發送到攻擊者的網站，或者冒充用戶的行爲，調用目標網站接口執行攻擊者指定的操做。

DOM型XSS防護：

一、在使用 .innerHTML、.outerHTML、document.write() 時要特別當心，不要把不可信的數據做爲 HTML 插到頁面上，而應儘可能使用 .textContent、.setAttribute() 等。

二、在使用 .innerHTML、.outerHTML、document.write() 時要特別當心，不要把不可信的數據做爲 HTML 插到頁面上，而應儘可能使用 .textContent、.setAttribute() 等。

三、在使用 .innerHTML、.outerHTML、document.write() 時要特別當心，不要把不可信的數據做爲 HTML 插到頁面上，而應儘可能使用 .textContent、.setAttribute() 等。

四、Http Only cookie：預防XSS攻擊竊取用戶cookie最有效的防護手段。Web應用程序在設置cookie時，將其屬性設爲HttpOnly，就能夠避免該網頁的cookie被客戶端惡意JavaScript竊取，保護用戶cookie信息。

五、對產品輸入要求格式嚴謹檢查過濾。

其餘防護方式：

CSP（ Content-Security-Policy）

CSP 本質上就是創建白名單，開發者明確告訴瀏覽器哪些外部資源能夠加載和執行。咱們只須要配置規則，如何攔截是由瀏覽器本身實現的。咱們能夠經過這種方式來儘可能減小 XSS 攻擊。

一般能夠經過兩種方式來開啓 CSP：

設置 HTTP Header 中的 Content-Security-Policy
設置 meta 標籤的方式

只容許加載本站資源

Content-Security-Policy: default-src 'self'

只容許加載 HTTPS 協議圖片

Content-Security-Policy: img-src https://*

容許加載任何來源框架

Content-Security-Policy: child-src 'none'

（二）CSRF攻擊（Cross-Site Request Forgeries），跨站點請求僞造。

它利用用戶已登陸的身份，在用戶絕不知情的狀況下，以用戶的名義完成非法操做。指攻擊者經過設置好的陷阱，強制對已完成認證的用戶進行非預期的我的信息或設定信息等某些狀態更新，屬於被動攻擊。

一個典型的CSRF攻擊有着以下的流程：

受害者登陸 a.com，並保留了登陸憑證（Cookie）
攻擊者引誘受害者訪問了b.com
b.com 向 a.com 發送了一個請求：a.com/act=xx瀏覽器會默認攜帶a.com的Cookie
a.com接收到請求後，對請求進行驗證，並確認是受害者的憑證，誤覺得是受害者本身發送的請求
a.com以受害者的名義執行了act=xx
攻擊完成，攻擊者在受害者不知情的狀況下，冒充受害者，讓a.com執行了本身定義的操做

CSRF攻擊防護：

一、驗證 HTTP Referer 字段。

二、不讓第三方網站訪問到用戶 Cookie。

三、使用 token驗證。

四、顯示驗證方式：添加驗證碼、密碼等。

五、涉及到數據修改操做嚴格使用 post 請求而不是 get 請求。

1) Referer Check

HTTP Referer是header的一部分，當瀏覽器向web服務器發送請求時，通常會帶上Referer信息告訴服務器是從哪一個頁面連接過來的，服務器籍此能夠得到一些信息用於處理。能夠經過檢查請求的來源來防護CSRF攻擊。正常請求的referer具備必定規律，如在提交表單的referer一定是在該頁面發起的請求。因此經過檢查http包頭referer的值是否是這個頁面，來判斷是否是CSRF攻擊。

但在某些狀況下如從https跳轉到http，瀏覽器處於安全考慮，不會發送referer，服務器就沒法進行check了。若與該網站同域的其餘網站有XSS漏洞，那麼攻擊者能夠在其餘網站注入惡意腳本，受害者進入了此類同域的網址，也會遭受攻擊。出於以上緣由，沒法徹底依賴Referer Check做爲防護CSRF的主要手段。可是能夠經過Referer Check來監控CSRF攻擊的發生。

2) SameSite

能夠對 Cookie 設置 SameSite 屬性。該屬性表示 Cookie 不隨着跨域請求發送，能夠很大程度減小 CSRF 的攻擊，可是該屬性目前並非全部瀏覽器都兼容。

3) Anti CSRF Token

目前比較完善的解決方案是加入Anti-CSRF-Token。即發送請求時在HTTP 請求中以參數的形式加入一個隨機產生的token，並在服務器創建一個攔截器來驗證這個token。服務器讀取瀏覽器當前域cookie中這個token值，會進行校驗該請求當中的token和cookie當中的token值是否都存在且相等，才認爲這是合法的請求。不然認爲此次請求是違法的，拒絕該次服務。

這種方法相比Referer檢查要安全不少，token能夠在用戶登錄後產生並放於session或cookie中，而後在每次請求時服務器把token從session或cookie中拿出，與本次請求中的token 進行比對。因爲token的存在，攻擊者沒法再構造出一個完整的URL實施CSRF攻擊。但在處理多個頁面共存問題時，當某個頁面消耗掉token後，其餘頁面的表單保存的仍是被消耗掉的那個token，其餘頁面的表單提交時會出現token錯誤。

4) 驗證碼

應用程序和用戶進行交互過程當中，特別是帳戶交易這種核心步驟，強制用戶輸入驗證碼，才能完成最終請求。在一般狀況下，驗證碼夠很好地遏制CSRF攻擊。但增長驗證碼下降了用戶的體驗，網站不能給全部的操做都加上驗證碼。因此只能將驗證碼做爲一種輔助手段，在關鍵業務點設置驗證碼。

（三）點擊劫持攻擊

點擊劫持是一種視覺欺騙的攻擊手段。攻擊者將須要攻擊的網站經過 iframe 嵌套的方式嵌入本身的網頁中，並將 iframe 設置爲透明，在頁面中透出一個按鈕誘導用戶點擊。即攻擊者使用一個透明的、不可見的iframe，覆蓋在一個網頁上，而後誘使用戶在網頁上進行操做，此時用戶將在不知情的狀況下點擊透明的iframe頁面。經過調整iframe頁面的位置，能夠誘使用戶剛好點擊在iframe頁面的一些功能性按鈕上。

網絡劫持通常分爲兩種:

DNS劫持: (輸入京東被強制跳轉到淘寶這就屬於dns劫持)
- DNS強制解析: 經過修改運營商的本地DNS記錄，來引導用戶流量到緩存服務器；
- 302跳轉的方式: 經過監控網絡出口的流量，分析判斷哪些內容是能夠進行劫持處理的,再對劫持的內存發起302跳轉的回覆，引導用戶獲取內容。
HTTP劫持: (訪問谷歌可是一直有貪玩藍月的廣告)，因爲http明文傳輸，運營商會修改你的http響應內容(即加廣告)。

點擊劫持攻擊防護：

DNS劫持因爲涉嫌違法,已經被監管起來,如今不多會有DNS劫持,而http劫持依然很是盛行。最有效的辦法就是全站HTTPS,將HTTP加密,這使得運營商沒法獲取明文,就沒法劫持你的響應內容。

1、X-Frame-Options瀏覽器機制：X-Frame-Options HTTP響應頭是用來給瀏覽器指示容許一個頁面可否在<frame>、<iframe>、<object>中展示的標記，有三個可選的值：DENY：瀏覽器會拒絕當前頁面加載任何frame頁面（即便是相同域名的頁面也不容許）SAMEORIGIN：容許加載frame頁面，可是frame頁面的地址只能爲同源域名下的頁面ALLOW-FROM：能夠加載指定來源的frame頁面（能夠定義frame頁面的地址）但這個缺陷就是chrome、Safari是不支持ALLOW-FROM語法！

2、使用認證碼認證用戶：點擊劫持漏洞經過僞造網站界面進行攻擊，網站開發人員能夠經過認證碼識別用戶，肯定是用戶發出的點擊命令才執行相應操做。識別用戶的方法中最有效的方法是認證碼認證。例如，在網站上普遍存在的發帖認證碼，要求用戶輸入圖形中的字符，輸入某些圖形的特徵等。

3、使用 FrameBusting 代碼：使用 JavaScript 腳本阻止惡意網站載入網頁。若是檢測到網頁被非法網頁載入，就執行自動跳轉功能。若是用戶瀏覽器禁用JavaScript腳本，那麼FrameBusting代碼也沒法正常運行。因此，該類代碼只能提供部分保障功能。

當經過 iframe 的方式加載頁面時，攻擊者的網頁直接不顯示全部內容：

<head>
  <style id="click-jack">
    html {
      display: none !important;
    }
  </style>
</head>
<body>
  <script>
    if (self == top) {
      var style = document.getElementById('click-jack')
      document.body.removeChild(style)
    } else {
      top.location = self.location
    }
  </script>
</body>

（四）iframe帶來的風險

iframe中的內容是由第三方來提供的，默認狀況下他們不受咱們的控制，他們能夠在iframe中運行JavaScirpt腳本、Flash插件、彈出對話框等等，這可能會破壞前端用戶體驗。frame自己不受咱們控制，那麼若是iframe中的域名由於過時而被惡意攻擊者搶注，或者第三方被黑客攻破，iframe中的內容被替換掉了，從而利用用戶瀏覽器中的安全漏洞下載安裝木馬、惡意勒索軟件等等。

iframe防護：

iframe有了一個叫作sandbox的安全屬性，經過它能夠對iframe的行爲進行各類限制，在 iframe 元素中添加上這個關鍵詞就行，另外，sandbox也提供了豐富的配置參數，咱們能夠進行較爲細粒度的控制。一些典型的參數以下：

allow-forms：容許iframe中提交form表單

allow-popups：容許iframe中彈出新的窗口或者標籤頁（例如，window.open()，showModalDialog()，target=」_blank」等等）

allow-scripts：容許iframe中執行JavaScript

allow-same-origin：容許iframe中的網頁開啓同源策略

若是你只是添加上這個屬性而保持屬性值爲空，那麼瀏覽器將會對 iframe 實施史上最嚴厲的調控限制。

（五）不安全的第三方依賴

項目裏面使用了不少第三方的依賴，不論應用本身的代碼的安全性有多高，若是這些來自第三方的代碼有安全漏洞，那麼對應用總體的安全性依然會形成嚴峻的挑戰。jQuery就存在多個已知安全漏洞，Node.js也有一些已知的安全漏洞。

第三方依賴包防護：

手動檢查這些第三方代碼有沒有安全問題是個苦差事，主要是由於應用依賴的這些組件數量衆多，手工檢查太耗時，有自動化的工具可使用，好比NSP(Node Security Platform)，Snyk、sonarQubej檢測工具等等。

VUE對前端安全的處理：VUE的安全措施