前端常見的安全問題以及防范措施總結大全

Posted on 2022-02-24 by WalkonNet

前言

隨著互聯網的高速發展，信息安全問題已經成為行業最為關註的焦點之一。總的來說安全是很復雜的一個領域，在移動互聯網時代，前端人員除瞭傳統的 XSS、CSRF 等安全問題之外，還時常遭遇網絡劫持、非法調用 Hybrid API 等新型安全問題。這篇文章會介紹一些常見的安全問題及如何防范的內容，在當下其實安全問題越來越重要，已經逐漸成為前端開發必備的技能瞭。

前端安全問題

跨站腳本攻擊（XSS）

Cross-Site Scripting（跨站腳本攻擊）簡稱 XSS，是一種代碼註入攻擊。攻擊者通過在目標網站上註入惡意腳本，使之在用戶的瀏覽器上運行。利用這些惡意腳本，攻擊者可獲取用戶的敏感信息如 Cookie、SessionID 等，進而危害數據安全。

為瞭和 CSS 區分，這裡把攻擊的第一個字母改成瞭 X，於是叫做 XSS。

一般可以通過三種方式來註入惡意腳本：

反射型XSS攻擊

顧名思義，惡意 JavaScript 腳本屬於用戶發送給網站請求中的一部分，隨後網站又將這部分返回給用戶，惡意腳本在頁面中被執行。一般發生在前後端一體的應用中，服務端邏輯會改變最終的網頁代碼。

反射型 XSS 的攻擊步驟：

攻擊者構造出特殊的 URL，其中包含惡意代碼。
用戶打開帶有惡意代碼的 URL 時，網站服務端將惡意代碼從 URL 中取出，拼接在 HTML 中返回給瀏覽器。
用戶瀏覽器接收到響應後解析執行，混在其中的惡意代碼也被執行。
惡意代碼竊取用戶數據並發送到攻擊者的網站，或者冒充用戶的行為，調用目標網站接口執行攻擊者指定的操作。

基於DOM的XSS攻擊

目前更流行前後端分離的項目，反射型 XSS 無用武之地。但這種攻擊不需要經過服務器，我們知道，網頁本身的 JavaScript 也是可以改變 HTML 的，黑客正是利用這一點來實現插入惡意腳本。

基於DOM 的 XSS 攻擊步驟：

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

存儲型XSS攻擊

又叫持久型 XSS，顧名思義，黑客將惡意 JavaScript 腳本長期保存在服務端數據庫中，用戶一旦訪問相關頁面數據，惡意腳本就會被執行。常見於搜索、微博、社區貼吧評論等。

存儲型 XSS 的攻擊步驟：

攻擊者將惡意代碼提交到目標網站的數據庫中。
用戶打開目標網站時，網站服務端將惡意代碼從數據庫取出，拼接在 HTML 中返回給瀏覽器。
用戶瀏覽器接收到響應後解析執行，混在其中的惡意代碼也被執行。
惡意代碼竊取用戶數據並發送到攻擊者的網站，或者冒充用戶的行為，調用目標網站接口執行攻擊者指定的操作。

這幾種XSS攻擊類型的區別

反射型的 XSS 的惡意腳本存在 URL 裡，存儲型 XSS 的惡意代碼存在數據庫裡。
反射型 XSS 攻擊常見於通過 URL 傳遞參數的功能，如網站搜索、跳轉等。
存儲型XSS攻擊常見於帶有用戶保存數據的網站功能，如論壇發帖、商品評論、用戶私信等。
而基於DOM的XSS 攻擊中，取出和執行惡意代碼由瀏覽器端完成，屬於前端 JavaScript 自身的安全漏洞，其他兩種 XSS 都屬於服務端的安全漏洞。

XSS防范措施

由上面對XSS攻擊的介紹我們知道，XSS攻擊主要有兩大步驟：

攻擊者提交惡意代碼
瀏覽器執行惡意代碼

所以我們可以針對這兩點來制定防范措施：

輸入過濾

在用戶提交時，由前端過濾輸入，然後提交到後端，這種方法不可行，因為攻擊者可能繞過前端過濾，直接構造請求，提交惡意代碼。一般在寫入數據庫前，後端對輸入數據進行過濾。雖然輸入側過濾能夠在某些情況下解決特定的 XSS 問題，但會引入很大的不確定性和亂碼問題。在防范 XSS 攻擊時應避免此類方法。

預防存儲型和反射型 XSS 攻擊

改成純前端渲染，把代碼和數據分隔開。
對 HTML 做充分轉義。

預防 DOM 型 XSS 攻擊

DOM 型 XSS 攻擊，實際上就是網站前端 JavaScript 代碼本身不夠嚴謹，把不可信的數據當作代碼執行瞭。

在使用 .innerHTML、.outerHTML、document.write() 時要特別小心，不要把不可信的數據作為 HTML 插到頁面上，而應盡量使用 .textContent、.setAttribute() 等。

如果用 Vue/React 技術棧，並且不使用 v-html/dangerouslySetInnerHTML 功能，就在前端 render 階段避免 innerHTML、outerHTML 的 XSS 隱患。

DOM 中的內聯事件監聽器，如 location、onclick、onerror、onload、onmouseover 等，<a> 標簽的 href 屬性，JavaScript 的 eval()、setTimeout()、setInterval() 等，都能把字符串作為代碼運行。如果不可信的數據拼接到字符串中傳遞給這些 API，很容易產生安全隱患，請務必避免。

<!-- 內聯事件監聽器中包含惡意代碼 -->
<img onclick="UNTRUSTED" onerror="UNTRUSTED" src="data:image/png,">

<!-- 鏈接內包含惡意代碼 -->
<a href="UNTRUSTED" rel="external nofollow" >1</a>

<script>
// setTimeout()/setInterval() 中調用惡意代碼
setTimeout("UNTRUSTED")
setInterval("UNTRUSTED")

// location 調用惡意代碼
location.href = 'UNTRUSTED'

// eval() 中調用惡意代碼
eval("UNTRUSTED")
</script>

Content Security Policy

嚴格的 CSP 在 XSS 的防范中可以起到以下的作用：

禁止加載外域代碼，防止復雜的攻擊邏輯。
禁止外域提交，網站被攻擊後，用戶的數據不會泄露到外域。
禁止內聯腳本執行（規則較嚴格，目前發現 GitHub 使用）。
禁止未授權的腳本執行（新特性，Google Map 移動版在使用）。
合理使用上報可以及時發現 XSS，利於盡快修復問題。

使用 W3C 提出的 CSP (Content Security Policy，內容安全策略)，定義域名白名單

其他措施

設置 Cookie 的 HttpOnly 屬性，禁止JavaScript讀取cookie
驗證碼：防止腳本冒充用戶提交危險操作。

XSS攻擊案例

2005年，年僅19歲的 Samy Kamkar 發起瞭對 MySpace.com 的 XSS Worm 攻擊。 Samy Kamkar 的蠕蟲在短短幾小時內就感染瞭100萬用戶——它在每個用戶的自我簡介後邊加瞭一句話：“but most of all, Samy is my hero.”（Samy是我的偶像）。這是 Web 安全史上第一個重量級的 XSS Worm，具有裡程碑意義。
2007年12月，百度空間收到蠕蟲攻擊，用戶之間開始轉發垃圾短消息。
QQ 郵箱 m.exmail.qq.com 域名被發現反射型 XSS 漏洞
2011年新浪微博曾被黑客 XSS 攻擊，黑客誘導用戶點擊一個帶有誘惑性的鏈接，便會自動發送一條帶有同樣誘惑性鏈接微博。攻擊范圍層層擴大，也是一種蠕蟲攻擊。

跨站請求偽造（CSRF）

CSRF（Cross-site request forgery）跨站請求偽造：攻擊者誘導受害者進入第三方網站，在第三方網站中，向被攻擊網站發送跨站請求。利用受害者在被攻擊網站已經獲取的註冊憑證，繞過後臺的用戶驗證，達到冒充用戶對被攻擊的網站執行某項操作的目的。

CSRF是怎麼攻擊的？

典型的CSRF攻擊是這樣的：

受害者登錄A網站，並且保留瞭登錄憑證（Cookie）
攻擊者引誘受害者訪問B網站
B網站向A網站發送瞭一個請求（這個就是下面將介紹的幾種偽造請求的方式），瀏覽器請求頭中會默認攜帶 A 網站的 Cookie
A 網站服務器收到請求後，經過驗證發現用戶是登錄瞭的，所以會處理請求

常見的CSRF攻擊類型

GET類型的CSRF

GET類型的CSRF利用非常簡單，隻需要一個HTTP請求，一般會這樣利用：

 <img src="http://bank.example/withdraw?amount=10000&for=hacker" >

在受害者訪問含有這個img的頁面後，瀏覽器會自動向http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker發出一次HTTP請求。bank.example就會收到包含受害者登錄信息的一次跨域請求。

POST類型的CSRF

這種類型的CSRF利用起來通常使用的是一個自動提交的表單，如：

 <form action="http://bank.example/withdraw" method=POST>
    <input type="hidden" name="account" value="xiaoming" />
    <input type="hidden" name="amount" value="10000" />
    <input type="hidden" name="for" value="hacker" />
</form>
<script> document.forms[0].submit(); </script>

訪問該頁面後，表單會自動提交，相當於模擬用戶完成瞭一次POST操作。

POST類型的攻擊通常比GET要求更加嚴格一點，但仍並不復雜。任何個人網站、博客，被黑客上傳頁面的網站都有可能是發起攻擊的來源，後端接口不能將安全寄托在僅允許POST上面。

鏈接類型的CSRF

鏈接類型的CSRF並不常見，比起其他兩種用戶打開頁面就中招的情況，這種需要用戶點擊鏈接才會觸發。這種類型通常是在論壇中發佈的圖片中嵌入惡意鏈接，或者以廣告的形式誘導用戶中招，攻擊者通常會以比較誇張的詞語誘騙用戶點擊

  <a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" rel="external nofollow"  taget="_blank">
  重磅消息！！
  <a/>

CSRF的特點

攻擊一般發起在第三方網站，而不是被攻擊的網站。被攻擊的網站無法防止攻擊發生。
攻擊利用受害者在被攻擊網站的登錄憑證，冒充受害者提交操作；而不是直接竊取數據。
整個過程攻擊者並不能獲取到受害者的登錄憑證，僅僅是“冒用”。
跨站請求可以用各種方式：圖片URL、超鏈接、CORS、Form提交等等。部分請求方式可以直接嵌入在第三方論壇、文章中，難以進行追蹤。

CSRF防范措施

由上面對CSRF的介紹我們知道瞭，CSRF通常發生在第三方域名，並且CSRF攻擊者不能獲取到受害者的cookie等信息，隻是借用他們的登錄狀態來偽造請求。所以我們可以針對這兩點來制定防范措施：

同源檢測

既然CSRF大多來自第三方網站，那麼我們就直接禁止第三方域名（或者不受信任的域名）對我們發起請求。

在HTTP協議中，每一個異步請求都會攜帶兩個Header，用於標記來源域名：

Origin Header
Referer Header

這兩個Header在瀏覽器發起請求時，大多數情況會自動帶上，並且不能由前端自定義內容。服務器可以通過解析這兩個Header中的域名，確定請求的來源域。同時服務器應該優先檢測 Origin。為瞭安全考慮，相比於 Referer，Origin 隻包含瞭域名而不帶路徑。

CSRF Token

在瀏覽器向服務器發起請求時，服務器生成一個 CSRF Token。CSRF Token 其實就是服務器生成的隨機字符串，然後將該字符串植入到返回的頁面中，通常是放到表單的隱藏輸入框中，這樣能夠很好的保護 CSRF Token 不被泄漏；
當瀏覽器再次發送請求的時候，就需要攜帶這個 CSRF Token 值一起提交；
服務器驗證 CSRF Token 是否一致；從第三方網站發出的請求是無法獲取用戶頁面中的 CSRF Token 值的。

給 Cookie 設置合適的 SameSite

當從 A 網站登錄後，會從響應頭中返回服務器設置的 Cookie 信息，而如果 Cookie 攜帶瞭 SameSite=strict 則表示完全禁用第三方站點請求頭攜帶 Cookie，比如當從 B 網站請求 A 網站接口的時候，瀏覽器的請求頭將不會攜帶該 Cookie。

Samesite=Strict，這種稱為嚴格模式，表明這個 Cookie 在任何情況下都不可能作為第三方 Cookie
Samesite=Lax，這種稱為寬松模式，比 Strict 放寬瞭點限制：假如這個請求是這種請求（改變瞭當前頁面或者打開瞭新頁面）且同時是個GET請求，則這個Cookie可以作為第三方Cookie。（默認）
None 任何情況下都會攜帶；

點擊劫持（ClickJacking）

點擊劫持（Clickjacking）是一種通過視覺欺騙的手段來達到攻擊目的手段。往往是攻擊者將目標網站通過 iframe 嵌入到自己的網頁中，通過 opacity 等手段設置 iframe 為透明的，使得肉眼不可見，這樣一來當用戶在攻擊者的網站中操作的時候，比如點擊某個按鈕（這個按鈕的頂層其實是 iframe），從而實現目標網站被點擊劫持。

點擊劫持防范措施

在HTTP投中加入 X-FRAME-OPTIONS 屬性，此屬性控制頁面是否可被嵌入 iframe 中
- DENY：不能被所有網站嵌套或加載；
- SAMEORIGIN：隻能被同域網站嵌套或加載；
- ALLOW-FROM URL：可以被指定網站嵌套或加載。
判斷當前網頁是否被 iframe 嵌套

HTTP嚴格傳輸安全（HSTS）

HTTP嚴格傳輸安全(HSTS)是一種安全功能，web服務器通過它來告訴瀏覽器僅用HTTPS來與之通訊，而不是使用HTTP。

HSTS代表HTTP嚴格傳輸安全性，由IETF在2012年的RFC 6797中指定。創建它是為瞭在站點通過HTTPS運行時強制瀏覽器使用安全連接。它是您添加到Web服務器的安全標頭，並在響應標頭中反映為Strict-Transport-Security。HSTS很重要，因為它解決瞭以下問題：

訪問者嘗試使用您網站頁面的不安全版本 (HTTP://) 的任何嘗試都將自動轉發到安全版本 (HTTPS://)。
舊的HTTP書簽和輸入您網站的HTTP版本的人會讓您面臨中間人攻擊。在這些攻擊中，攻擊者改變各方之間的通信並誘使他們認為他們仍在相互通信。
不允許覆蓋無效的證書消息，這反過來又保護瞭訪問者。
Cookie劫持：當有人通過不安全的連接竊取會話cookie時，就會發生這種情況。Cookie可以包含各種有價值的信息，例如信用卡信息、姓名、地址等。

註意，如果之前沒有使用HTTPS協議訪問過該站點，那麼HSTS是不奏效的，隻有瀏覽器曾經與服務器創建過一次安全連接並且網站通過HTTPS協議告訴瀏覽器它支持HSTS，那麼之後瀏覽器才會強制使用HTTPS，即使鏈接被換成瞭HTTP。

雖然我們的系統默認更喜歡HTTPS版本，但您也可以通過將您的HTTP站點重定向到您的HTTPS版本並在您的服務器上實施HSTS標頭，使其他搜索引擎更清楚這一點。 —— 谷歌安全團隊

開啟HSTS

在Apache中啟用HSTS

將以下代碼添加到您的虛擬主機文件中。

Header always set Strict-Transport-Security max-age=31536000

在NGINX中啟用 HSTS

將以下代碼添加到您的NGINX配置中。

add_header Strict-Transport-Security max-age=31536000

事實上，添加HSTS標頭有性能優勢。如果有人試圖通過HTTP訪問您的站點，而不是發出HTTP請求，它隻是重定向到HTTPS版本。

CDN劫持

CDN原理？

它的名字就叫做CDN——Content Delivery Network，內容分發網絡。具體來說，CDN就是采用更多的緩存服務器（CDN邊緣節點），佈放在用戶訪問相對集中的地區或網絡中。當用戶訪問網站時，利用全局負載技術，將用戶的訪問指向距離最近的緩存服務器上，由緩存服務器響應用戶請求。（有點像電商的本地倉吧？）CDN應用廣泛，支持多種行業、多種場景內容加速，例如：圖片小文件、大文件下載、視音頻點播、直播流媒體、全站加速、安全加速。

什麼是CDN劫持？

網絡上有很多黑客為瞭讓用戶能夠登錄自己開發的釣魚網站，都會通過對CDN進行劫持的方法，讓用戶自動轉入自己開發的網站。而很多用戶卻往往無法察覺到自己已經被劫持。其實驗證被劫持的方法，就是輸入任何網址看看所打開的網頁是否和自己輸入的網址一致，

CDN劫持防范措施

使用SRI來解決CDN劫持

SRI 全稱 Subresource Integrity – 子資源完整性，是指瀏覽器通過驗證資源的完整性（通常從 CDN 獲取）來判斷其是否被篡改的安全特性。

通過給 link 標簽或者 script 標簽增加 integrity 屬性即可開啟 SRI 功能，比如

<script type="text/javascript" src="//s.url.cn/xxxx/aaa.js" 
    integrity="sha256-xxx sha384-yyy"
    crossorigin="anonymous"></script>

integrity 值分成兩個部分，第一部分指定哈希值的生成算法（sha256、sha384 及 sha512），第二部分是經過 base64 編碼的實際哈希值，兩者之間通過一個短橫（-）分割。integrity 值可以包含多個由空格分隔的哈希值，隻要文件匹配其中任意一個哈希值，就可以通過校驗並加載該資源。開啟 SRI 能有效保證頁面引用資源的完整性，避免惡意代碼執行。

瀏覽器如何處理 SRI

當瀏覽器在 script 或者 link 標簽中遇到 integrity 屬性之後，會在執行腳本或者應用樣式表之前對比所加載文件的哈希值和期望的哈希值。
當腳本或者樣式表的哈希值和期望的不一致時，瀏覽器必須拒絕執行腳本或者應用樣式表，並且必須返回一個網絡錯誤說明獲得腳本或樣式表失敗。

內容安全策略（CSP）

內容安全策略（Content Security Policy）簡稱 CSP，通過它可以明確的告訴客戶端瀏覽器當前頁面的哪些外部資源可以被加載執行，而哪些又是不可以的。

CSP的意義

防XSS等攻擊的利器。CSP 的實質就是白名單制度，開發者明確告訴客戶端，哪些外部資源可以加載和執行，等同於提供白名單。它的實現和執行全部由瀏覽器完成，開發者隻需提供配置。CSP 大大增強瞭網頁的安全性。攻擊者即使發現瞭漏洞，也沒法註入腳本，除非還控制瞭一臺列入瞭白名單的可信主機。

CSP的分類

Content-Security-Policy 配置好並啟用後，不符合 CSP 的外部資源就會被阻止加載。
Content-Security-Policy-Report-Only 表示不執行限制選項，隻是記錄違反限制的行為。它必須與report-uri選項配合使用。

CSP的使用

通過 HTTP 頭配置 Content-Security-Policy，以下配置說明該頁面隻允許當前源和 https://apis.google.com 這 2 個源的腳本加載和執行：

Content-Security-Policy: script-src 'self' https://apis.google.com

通過頁面 <meta> 標簽配置：

<meta http-equiv="Content-Security-Policy" content="script-src 'self' https://apis.google.com">

安全沙箱（Sandbox）

多進程的瀏覽器架構將主要分為兩塊：瀏覽器內核和渲染內核。而安全沙箱能限制瞭渲染進程對操作系統資源的訪問和修改，同時渲染進程內部也沒有讀寫操作系統的能力，而這些都是在瀏覽器內核中一一實現瞭，包括持久存儲、網絡訪問和用戶交互等一系列直接與操作系統交互的功能。瀏覽器內核和渲染內核各自職責分明，當他們需要進行數據傳輸的時候會通過 IPC 進行。

而渲染進程的工作是進行 HTML、CSS 的解析，JavaScript 的執行等，而這部分內容是直接暴露給用戶的，所以也是最容易被黑客利用攻擊的地方，如果黑客攻擊瞭這裡就有可能獲取到渲染進程的權限，進而威脅到操作系統。所以需要一道墻用來把不可信任的代碼運行在一定的環境中，限制不可信代碼訪問隔離區之外的資源，而這道墻就是瀏覽器的安全沙箱。

安全沙箱的存在是為瞭保護客戶端操作系統免受黑客攻擊，但是阻止不瞭 XSS 和 CSRF。

安全沙箱是利用操作系統提供的安全技術，這樣渲染進程在運行中就無法獲取或修改操作系統中的數據。安全沙箱最小隔離單位是進程，所以無法保護單進程瀏覽器。

Iframe

iframe在給我們的頁面帶來更多豐富的內容和能力的同時，也帶來瞭不少的安全隱患。因為iframe中的內容是由第三方來提供的，默認情況下他們不受我們的控制，他們可以在iframe中運行JavaScirpt腳本、Flash插件、彈出對話框等等，這可能會破壞前端用戶體驗。

如何讓自己的網站不被其他網站的iframe引用？

js的防禦方案：將下面這段代碼放到網站頁面的</body>標簽前，這樣別人在通過iframe框架引用你的網站網頁時，瀏覽器會自動跳轉到你的網站所引用的頁面上。
```
<script>
if (self == top) {
    var theBody = document.getElementsByTagName('body')[0];
    theBody.style.display = "block";
} else {
    top.location = self.location;
}
</script>
```

使用X-Frame-Options防止網頁被iframe：X-FRAME-OPTIONS是微軟提出的一個http頭，專門用來防禦利用iframe嵌套的點擊劫持攻擊。

DENY               // 拒絕任何域加載
SAMEORIGIN         // 允許同源域下加載
ALLOW-FROM         // 可以定義允許frame加載的頁面地址

如何禁止被使用的 iframe 對當前網站某些操作？

sandbox是html5的新屬性，主要是提高iframe安全系數。iframe因安全問題而臭名昭著，這主要是因為iframe常被用於嵌入到第三方中，然後執行某些惡意操作。【這個與上面說到的安全沙箱（Sandbox）不同】現在有一場景：我的網站需要 iframe 引用某網站，但是不想被該網站操作DOM、不想加載某些js（廣告、彈框等）、當前窗口被強行跳轉鏈接等，我們可以設置 sandbox 屬性:

allow-same-origin：允許被視為同源，即可操作父級DOM或cookie等
allow-top-navigation：允許當前iframe的引用網頁通過url跳轉鏈接或加載
allow-forms：允許表單提交
allow-scripts：允許執行腳本文件
allow-popups：允許瀏覽器打開新窗口進行跳轉
“”：設置為空時上面所有允許全部禁止

總結

到此這篇關於前端常見的安全問題以及防范措施的文章就介紹到這瞭,更多相關前端常見安全問題及防范內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

目錄

前言