溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本文小編為大家詳細介紹“web前端常見的安全問題及怎么防范措施”，內容詳細，步驟清晰，細節處理妥當，希望這篇“web前端常見的安全問題及怎么防范措施”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。
Cross-Site Scripting（跨站腳本攻擊）簡稱 XSS，是一種代碼注入攻擊。攻擊者通過在目標網站上注入惡意腳本，使之在用戶的瀏覽器上運行。利用這些惡意腳本，攻擊者可獲取用戶的敏感信息如 Cookie、SessionID 等，進而危害數據安全。
為了和 CSS 區分，這里把攻擊的第一個字母改成了 X，于是叫做 XSS。
一般可以通過三種方式來注入惡意腳本：
顧名思義，惡意 JavaScript 腳本屬于用戶發送給網站請求中的一部分，隨后網站又將這部分返回給用戶，惡意腳本在頁面中被執行。一般發生在前后端一體的應用中，服務端邏輯會改變最終的網頁代碼。
反射型 XSS 的攻擊步驟：
攻擊者構造出特殊的 URL，其中包含惡意代碼。
用戶打開帶有惡意代碼的 URL 時，網站服務端將惡意代碼從 URL 中取出，拼接在 HTML 中返回給瀏覽器。
用戶瀏覽器接收到響應后解析執行，混在其中的惡意代碼也被執行。
惡意代碼竊取用戶數據并發送到攻擊者的網站，或者冒充用戶的行為，調用目標網站接口執行攻擊者指定的操作。
目前更流行前后端分離的項目，反射型 XSS 無用武之地。 但這種攻擊不需要經過服務器，我們知道，網頁本身的 JavaScript 也是可以改變 HTML 的，黑客正是利用這一點來實現插入惡意腳本。
基于DOM 的 XSS 攻擊步驟：
攻擊者構造出特殊的 URL，其中包含惡意代碼。
用戶打開帶有惡意代碼的 URL。
用戶瀏覽器接收到響應后解析執行，前端 JavaScript 取出 URL 中的惡意代碼并執行。
惡意代碼竊取用戶數據并發送到攻擊者的網站，或者冒充用戶的行為，調用目標網站接口執行攻擊者指定的操作。
又叫持久型 XSS，顧名思義，黑客將惡意 JavaScript 腳本長期保存在服務端數據庫中，用戶一旦訪問相關頁面數據，惡意腳本就會被執行。常見于搜索、微博、社區貼吧評論等。
存儲型 XSS 的攻擊步驟：
攻擊者將惡意代碼提交到目標網站的數據庫中。
用戶打開目標網站時，網站服務端將惡意代碼從數據庫取出，拼接在 HTML 中返回給瀏覽器。
用戶瀏覽器接收到響應后解析執行，混在其中的惡意代碼也被執行。
惡意代碼竊取用戶數據并發送到攻擊者的網站，或者冒充用戶的行為，調用目標網站接口執行攻擊者指定的操作。
反射型的 XSS 的惡意腳本存在 URL 里，存儲型 XSS 的惡意代碼存在數據庫里。
反射型 XSS 攻擊常見于通過 URL 傳遞參數的功能，如網站搜索、跳轉等。
存儲型XSS攻擊常見于帶有用戶保存數據的網站功能，如論壇發帖、商品評論、用戶私信等。
而基于DOM的XSS 攻擊中，取出和執行惡意代碼由瀏覽器端完成，屬于前端 JavaScript 自身的安全漏洞，其他兩種 XSS 都屬于服務端的安全漏洞。
由上面對XSS攻擊的介紹我們知道，XSS攻擊主要有兩大步驟：
攻擊者提交惡意代碼
瀏覽器執行惡意代碼
所以我們可以針對這兩點來制定防范措施：
在用戶提交時，由前端過濾輸入，然后提交到后端，這種方法不可行，因為攻擊者可能繞過前端過濾，直接構造請求，提交惡意代碼。一般在寫入數據庫前，后端對輸入數據進行過濾。雖然輸入側過濾能夠在某些情況下解決特定的 XSS 問題，但會引入很大的不確定性和亂碼問題。在防范 XSS 攻擊時應避免此類方法。
改成純前端渲染，把代碼和數據分隔開。
對 HTML 做充分轉義。
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>嚴格的 CSP 在 XSS 的防范中可以起到以下的作用：
禁止加載外域代碼，防止復雜的攻擊邏輯。
禁止外域提交，網站被攻擊后，用戶的數據不會泄露到外域。
禁止內聯腳本執行（規則較嚴格，目前發現 GitHub 使用）。
禁止未授權的腳本執行（新特性，Google Map 移動版在使用）。
合理使用上報可以及時發現 XSS，利于盡快修復問題。
使用 W3C 提出的 CSP (Content Security Policy，內容安全策略)，定義域名白名單
設置 Cookie 的 HttpOnly 屬性，禁止JavaScript讀取cookie
驗證碼：防止腳本冒充用戶提交危險操作。
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（Cross-site request forgery）跨站請求偽造：攻擊者誘導受害者進入第三方網站，在第三方網站中，向被攻擊網站發送跨站請求。利用受害者在被攻擊網站已經獲取的注冊憑證，繞過后臺的用戶驗證，達到冒充用戶對被攻擊的網站執行某項操作的目的。
典型的CSRF攻擊是這樣的：
受害者登錄A網站，并且保留了登錄憑證（Cookie）
攻擊者引誘受害者訪問B網站
B網站向A網站發送了一個請求（這個就是下面將介紹的幾種偽造請求的方式），瀏覽器請求頭中會默認攜帶 A 網站的 Cookie
A 網站服務器收到請求后，經過驗證發現用戶是登錄了的，所以會處理請求
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就會收到包含受害者登錄信息的一次跨域請求。
這種類型的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并不常見，比起其他兩種用戶打開頁面就中招的情況，這種需要用戶點擊鏈接才會觸發。這種類型通常是在論壇中發布的圖片中嵌入惡意鏈接，或者以廣告的形式誘導用戶中招，攻擊者通常會以比較夸張的詞語誘騙用戶點擊
<a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" rel="external nofollow" taget="_blank"> 重磅消息！！ <a/>
攻擊一般發起在第三方網站，而不是被攻擊的網站。被攻擊的網站無法防止攻擊發生。
攻擊利用受害者在被攻擊網站的登錄憑證，冒充受害者提交操作；而不是直接竊取數據。
整個過程攻擊者并不能獲取到受害者的登錄憑證，僅僅是“冒用”。
跨站請求可以用各種方式：圖片URL、超鏈接、CORS、Form提交等等。部分請求方式可以直接嵌入在第三方論壇、文章中，難以進行追蹤。
由上面對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 值的。
當從 A 網站登錄后，會從響應頭中返回服務器設置的 Cookie 信息，而如果 Cookie 攜帶了 SameSite=strict 則表示完全禁用第三方站點請求頭攜帶 Cookie，比如當從 B 網站請求 A 網站接口的時候，瀏覽器的請求頭將不會攜帶該 Cookie。
Samesite=Strict，這種稱為嚴格模式，表明這個 Cookie 在任何情況下都不可能作為第三方 Cookie
Samesite=Lax，這種稱為寬松模式，比 Strict 放寬了點限制：假如這個請求是這種請求（改變了當前頁面或者打開了新頁面）且同時是個GET請求，則這個Cookie可以作為第三方Cookie。（默認）
None 任何情況下都會攜帶；
點擊劫持（Clickjacking）是一種通過視覺欺騙的手段來達到攻擊目的手段。往往是攻擊者將目標網站通過 iframe 嵌入到自己的網頁中，通過 opacity 等手段設置 iframe 為透明的，使得肉眼不可見，這樣一來當用戶在攻擊者的網站中操作的時候，比如點擊某個按鈕（這個按鈕的頂層其實是 iframe），從而實現目標網站被點擊劫持。
在HTTP投中加入 X-FRAME-OPTIONS 屬性，此屬性控制頁面是否可被嵌入 iframe 中
DENY：不能被所有網站嵌套或加載；
SAMEORIGIN：只能被同域網站嵌套或加載；
ALLOW-FROM URL：可以被指定網站嵌套或加載。
判斷當前網頁是否被 iframe 嵌套
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標頭，使其他搜索引擎更清楚這一點。 —— 谷歌安全團隊
在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——Content Delivery Network，內容分發網絡。具體來說，CDN就是采用更多的緩存服務器（CDN邊緣節點），布放在用戶訪問相對集中的地區或網絡中。當用戶訪問網站時，利用全局負載技術，將用戶的訪問指向距離最近的緩存服務器上，由緩存服務器響應用戶請求。（有點像電商的本地倉吧？）CDN應用廣泛，支持多種行業、多種場景內容加速，例如：圖片小文件、大文件下載、視音頻點播、直播流媒體、全站加速、安全加速。
網絡上有很多黑客為了讓用戶能夠登錄自己開發的釣魚網站，都會通過對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 能有效保證頁面引用資源的完整性，避免惡意代碼執行。
當瀏覽器在 script 或者 link 標簽中遇到 integrity 屬性之后，會在執行腳本或者應用樣式表之前對比所加載文件的哈希值和期望的哈希值。
當腳本或者樣式表的哈希值和期望的不一致時，瀏覽器必須拒絕執行腳本或者應用樣式表，并且必須返回一個網絡錯誤說明獲得腳本或樣式表失敗。
內容安全策略（Content Security Policy）簡稱 CSP，通過它可以明確的告訴客戶端瀏覽器當前頁面的哪些外部資源可以被加載執行，而哪些又是不可以的。
防XSS等攻擊的利器。CSP 的實質就是白名單制度，開發者明確告訴客戶端，哪些外部資源可以加載和執行，等同于提供白名單。它的實現和執行全部由瀏覽器完成，開發者只需提供配置。CSP 大大增強了網頁的安全性。攻擊者即使發現了漏洞，也沒法注入腳本，除非還控制了一臺列入了白名單的可信主機。
Content-Security-Policy 配置好并啟用后，不符合 CSP 的外部資源就會被阻止加載。
Content-Security-Policy-Report-Only 表示不執行限制選項，只是記錄違反限制的行為。它必須與report-uri選項配合使用。
通過 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">
多進程的瀏覽器架構將主要分為兩塊：瀏覽器內核和渲染內核。而安全沙箱能限制了渲染進程對操作系統資源的訪問和修改，同時渲染進程內部也沒有讀寫操作系統的能力，而這些都是在瀏覽器內核中一一實現了，包括持久存儲、網絡訪問和用戶交互等一系列直接與操作系統交互的功能。瀏覽器內核和渲染內核各自職責分明，當他們需要進行數據傳輸的時候會通過 IPC 進行。
而渲染進程的工作是進行 HTML、CSS 的解析，JavaScript 的執行等，而這部分內容是直接暴露給用戶的，所以也是最容易被黑客利用攻擊的地方，如果黑客攻擊了這里就有可能獲取到渲染進程的權限，進而威脅到操作系統。所以需要一道墻用來把不可信任的代碼運行在一定的環境中，限制不可信代碼訪問隔離區之外的資源，而這道墻就是瀏覽器的安全沙箱。
安全沙箱的存在是為了保護客戶端操作系統免受黑客攻擊，但是阻止不了 XSS 和 CSRF。
安全沙箱是利用操作系統提供的安全技術，這樣渲染進程在運行中就無法獲取或修改操作系統中的數據。安全沙箱最小隔離單位是進程，所以無法保護單進程瀏覽器。
iframe在給我們的頁面帶來更多豐富的內容和能力的同時，也帶來了不少的安全隱患。因為iframe中的內容是由第三方來提供的，默認情況下他們不受我們的控制，他們可以在iframe中運行JavaScirpt腳本、Flash插件、彈出對話框等等，這可能會破壞前端用戶體驗。
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加載的頁面地址
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：允許瀏覽器打開新窗口進行跳轉
“”：設置為空時上面所有允許全部禁止
讀到這里，這篇“web前端常見的安全問題及怎么防范措施”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
