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

2022-02-24 13:01:17

前言

隨著網際網路的高速發展，資訊保安問題已經成為行業最為關注的焦點之一。總的來說安全是很複雜的一個領域，在行動網際網路時代，前端人員除了傳統的 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：允許瀏覽器開啟新視窗進行跳轉
“”：設定為空時上面所有允許全部禁止

總結

到此這篇關於前端常見的安全問題以及防範措施的文章就介紹到這了,更多相關前端常見安全問題及防範內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！