溫馨提示×
您好，登錄后才能下訂單哦！
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶服務(wù)條款》
您好，登錄后才能下訂單哦！
本文小編為大家詳細(xì)介紹“web前端常見的安全問(wèn)題及怎么防范措施”，內(nèi)容詳細(xì)，步驟清晰，細(xì)節(jié)處理妥當(dāng)，希望這篇“web前端常見的安全問(wèn)題及怎么防范措施”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來(lái)學(xué)習(xí)新知識(shí)吧。
Cross-Site Scripting（跨站腳本攻擊）簡(jiǎn)稱 XSS，是一種代碼注入攻擊。攻擊者通過(guò)在目標(biāo)網(wǎng)站上注入惡意腳本，使之在用戶的瀏覽器上運(yùn)行。利用這些惡意腳本，攻擊者可獲取用戶的敏感信息如 Cookie、SessionID 等，進(jìn)而危害數(shù)據(jù)安全。
為了和 CSS 區(qū)分，這里把攻擊的第一個(gè)字母改成了 X，于是叫做 XSS。
一般可以通過(guò)三種方式來(lái)注入惡意腳本：
顧名思義，惡意 JavaScript 腳本屬于用戶發(fā)送給網(wǎng)站請(qǐng)求中的一部分，隨后網(wǎng)站又將這部分返回給用戶，惡意腳本在頁(yè)面中被執(zhí)行。一般發(fā)生在前后端一體的應(yīng)用中，服務(wù)端邏輯會(huì)改變最終的網(wǎng)頁(yè)代碼。
反射型 XSS 的攻擊步驟：
攻擊者構(gòu)造出特殊的 URL，其中包含惡意代碼。
用戶打開帶有惡意代碼的 URL 時(shí)，網(wǎng)站服務(wù)端將惡意代碼從 URL 中取出，拼接在 HTML 中返回給瀏覽器。
用戶瀏覽器接收到響應(yīng)后解析執(zhí)行，混在其中的惡意代碼也被執(zhí)行。
惡意代碼竊取用戶數(shù)據(jù)并發(fā)送到攻擊者的網(wǎng)站，或者冒充用戶的行為，調(diào)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作。
目前更流行前后端分離的項(xiàng)目，反射型 XSS 無(wú)用武之地。 但這種攻擊不需要經(jīng)過(guò)服務(wù)器，我們知道，網(wǎng)頁(yè)本身的 JavaScript 也是可以改變 HTML 的，黑客正是利用這一點(diǎn)來(lái)實(shí)現(xiàn)插入惡意腳本。
基于DOM 的 XSS 攻擊步驟：
攻擊者構(gòu)造出特殊的 URL，其中包含惡意代碼。
用戶打開帶有惡意代碼的 URL。
用戶瀏覽器接收到響應(yīng)后解析執(zhí)行，前端 JavaScript 取出 URL 中的惡意代碼并執(zhí)行。
惡意代碼竊取用戶數(shù)據(jù)并發(fā)送到攻擊者的網(wǎng)站，或者冒充用戶的行為，調(diào)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作。
又叫持久型 XSS，顧名思義，黑客將惡意 JavaScript 腳本長(zhǎng)期保存在服務(wù)端數(shù)據(jù)庫(kù)中，用戶一旦訪問(wèn)相關(guān)頁(yè)面數(shù)據(jù)，惡意腳本就會(huì)被執(zhí)行。常見于搜索、微博、社區(qū)貼吧評(píng)論等。
存儲(chǔ)型 XSS 的攻擊步驟：
攻擊者將惡意代碼提交到目標(biāo)網(wǎng)站的數(shù)據(jù)庫(kù)中。
用戶打開目標(biāo)網(wǎng)站時(shí)，網(wǎng)站服務(wù)端將惡意代碼從數(shù)據(jù)庫(kù)取出，拼接在 HTML 中返回給瀏覽器。
用戶瀏覽器接收到響應(yīng)后解析執(zhí)行，混在其中的惡意代碼也被執(zhí)行。
惡意代碼竊取用戶數(shù)據(jù)并發(fā)送到攻擊者的網(wǎng)站，或者冒充用戶的行為，調(diào)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作。
反射型的 XSS 的惡意腳本存在 URL 里，存儲(chǔ)型 XSS 的惡意代碼存在數(shù)據(jù)庫(kù)里。
反射型 XSS 攻擊常見于通過(guò) URL 傳遞參數(shù)的功能，如網(wǎng)站搜索、跳轉(zhuǎn)等。
存儲(chǔ)型XSS攻擊常見于帶有用戶保存數(shù)據(jù)的網(wǎng)站功能，如論壇發(fā)帖、商品評(píng)論、用戶私信等。
而基于DOM的XSS 攻擊中，取出和執(zhí)行惡意代碼由瀏覽器端完成，屬于前端 JavaScript 自身的安全漏洞，其他兩種 XSS 都屬于服務(wù)端的安全漏洞。
由上面對(duì)XSS攻擊的介紹我們知道，XSS攻擊主要有兩大步驟：
攻擊者提交惡意代碼
瀏覽器執(zhí)行惡意代碼
所以我們可以針對(duì)這兩點(diǎn)來(lái)制定防范措施：
在用戶提交時(shí)，由前端過(guò)濾輸入，然后提交到后端，這種方法不可行，因?yàn)楣粽呖赡芾@過(guò)前端過(guò)濾，直接構(gòu)造請(qǐng)求，提交惡意代碼。一般在寫入數(shù)據(jù)庫(kù)前，后端對(duì)輸入數(shù)據(jù)進(jìn)行過(guò)濾。雖然輸入側(cè)過(guò)濾能夠在某些情況下解決特定的 XSS 問(wèn)題，但會(huì)引入很大的不確定性和亂碼問(wèn)題。在防范 XSS 攻擊時(shí)應(yīng)避免此類方法。
改成純前端渲染，把代碼和數(shù)據(jù)分隔開。
對(duì) HTML 做充分轉(zhuǎn)義。
DOM 型 XSS 攻擊，實(shí)際上就是網(wǎng)站前端 JavaScript 代碼本身不夠嚴(yán)謹(jǐn)，把不可信的數(shù)據(jù)當(dāng)作代碼執(zhí)行了。
在使用 .innerHTML、.outerHTML、document.write() 時(shí)要特別小心，不要把不可信的數(shù)據(jù)作為 HTML 插到頁(yè)面上，而應(yīng)盡量使用 .textContent、.setAttribute() 等。
如果用 Vue/React 技術(shù)棧，并且不使用 v-html/dangerouslySetInnerHTML 功能，就在前端 render 階段避免 innerHTML、outerHTML 的 XSS 隱患。
DOM 中的內(nèi)聯(lián)事件監(jiān)聽器，如 location、onclick、onerror、onload、onmouseover 等，<a> 標(biāo)簽的 href 屬性，JavaScript 的 eval()、setTimeout()、setInterval() 等，都能把字符串作為代碼運(yùn)行。如果不可信的數(shù)據(jù)拼接到字符串中傳遞給這些 API，很容易產(chǎn)生安全隱患，請(qǐng)務(wù)必避免。
<!-- 內(nèi)聯(lián)事件監(jiān)聽器中包含惡意代碼 -->
<img onclick="UNTRUSTED" onerror="UNTRUSTED" src="data:image/png,">
<!-- 鏈接內(nèi)包含惡意代碼 -->
<a href="UNTRUSTED" rel="external nofollow" >1</a>
<script>
// setTimeout()/setInterval() 中調(diào)用惡意代碼
setTimeout("UNTRUSTED")
setInterval("UNTRUSTED")
// location 調(diào)用惡意代碼
location.href = 'UNTRUSTED'
// eval() 中調(diào)用惡意代碼
eval("UNTRUSTED")
</script>嚴(yán)格的 CSP 在 XSS 的防范中可以起到以下的作用：
禁止加載外域代碼，防止復(fù)雜的攻擊邏輯。
禁止外域提交，網(wǎng)站被攻擊后，用戶的數(shù)據(jù)不會(huì)泄露到外域。
禁止內(nèi)聯(lián)腳本執(zhí)行（規(guī)則較嚴(yán)格，目前發(fā)現(xiàn) GitHub 使用）。
禁止未授權(quán)的腳本執(zhí)行（新特性，Google Map 移動(dòng)版在使用）。
合理使用上報(bào)可以及時(shí)發(fā)現(xiàn) XSS，利于盡快修復(fù)問(wèn)題。
使用 W3C 提出的 CSP (Content Security Policy，內(nèi)容安全策略)，定義域名白名單
設(shè)置 Cookie 的 HttpOnly 屬性，禁止JavaScript讀取cookie
驗(yàn)證碼：防止腳本冒充用戶提交危險(xiǎn)操作。
2005年，年僅19歲的 Samy Kamkar 發(fā)起了對(duì) MySpace.com 的 XSS Worm 攻擊。 Samy Kamkar 的蠕蟲在短短幾小時(shí)內(nèi)就感染了100萬(wàn)用戶——它在每個(gè)用戶的自我簡(jiǎn)介后邊加了一句話：“but most of all, Samy is my hero.”（Samy是我的偶像）。這是 Web 安全史上第一個(gè)重量級(jí)的 XSS Worm，具有里程碑意義。
2007年12月，百度空間收到蠕蟲攻擊，用戶之間開始轉(zhuǎn)發(fā)垃圾短消息。
QQ 郵箱 m.exmail.qq.com 域名被發(fā)現(xiàn)反射型 XSS 漏洞
2011年新浪微博曾被黑客 XSS 攻擊，黑客誘導(dǎo)用戶點(diǎn)擊一個(gè)帶有誘惑性的鏈接，便會(huì)自動(dòng)發(fā)送一條帶有同樣誘惑性鏈接微博。攻擊范圍層層擴(kuò)大，也是一種蠕蟲攻擊。
CSRF（Cross-site request forgery）跨站請(qǐng)求偽造：攻擊者誘導(dǎo)受害者進(jìn)入第三方網(wǎng)站，在第三方網(wǎng)站中，向被攻擊網(wǎng)站發(fā)送跨站請(qǐng)求。利用受害者在被攻擊網(wǎng)站已經(jīng)獲取的注冊(cè)憑證，繞過(guò)后臺(tái)的用戶驗(yàn)證，達(dá)到冒充用戶對(duì)被攻擊的網(wǎng)站執(zhí)行某項(xiàng)操作的目的。
典型的CSRF攻擊是這樣的：
受害者登錄A網(wǎng)站，并且保留了登錄憑證（Cookie）
攻擊者引誘受害者訪問(wèn)B網(wǎng)站
B網(wǎng)站向A網(wǎng)站發(fā)送了一個(gè)請(qǐng)求（這個(gè)就是下面將介紹的幾種偽造請(qǐng)求的方式），瀏覽器請(qǐng)求頭中會(huì)默認(rèn)攜帶 A 網(wǎng)站的 Cookie
A 網(wǎng)站服務(wù)器收到請(qǐng)求后，經(jīng)過(guò)驗(yàn)證發(fā)現(xiàn)用戶是登錄了的，所以會(huì)處理請(qǐng)求
GET類型的CSRF利用非常簡(jiǎn)單，只需要一個(gè)HTTP請(qǐng)求，一般會(huì)這樣利用：
<img src="http://bank.example/withdraw?amount=10000&for=hacker" >
在受害者訪問(wèn)含有這個(gè)img的頁(yè)面后，瀏覽器會(huì)自動(dòng)向http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker發(fā)出一次HTTP請(qǐng)求。bank.example就會(huì)收到包含受害者登錄信息的一次跨域請(qǐng)求。
這種類型的CSRF利用起來(lái)通常使用的是一個(gè)自動(dòng)提交的表單，如：
<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>
訪問(wèn)該頁(yè)面后，表單會(huì)自動(dòng)提交，相當(dāng)于模擬用戶完成了一次POST操作。
POST類型的攻擊通常比GET要求更加嚴(yán)格一點(diǎn)，但仍并不復(fù)雜。任何個(gè)人網(wǎng)站、博客，被黑客上傳頁(yè)面的網(wǎng)站都有可能是發(fā)起攻擊的來(lái)源，后端接口不能將安全寄托在僅允許POST上面。
鏈接類型的CSRF并不常見，比起其他兩種用戶打開頁(yè)面就中招的情況，這種需要用戶點(diǎn)擊鏈接才會(huì)觸發(fā)。這種類型通常是在論壇中發(fā)布的圖片中嵌入惡意鏈接，或者以廣告的形式誘導(dǎo)用戶中招，攻擊者通常會(huì)以比較夸張的詞語(yǔ)誘騙用戶點(diǎn)擊
<a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" rel="external nofollow" taget="_blank"> 重磅消息??！ <a/>
攻擊一般發(fā)起在第三方網(wǎng)站，而不是被攻擊的網(wǎng)站。被攻擊的網(wǎng)站無(wú)法防止攻擊發(fā)生。
攻擊利用受害者在被攻擊網(wǎng)站的登錄憑證，冒充受害者提交操作；而不是直接竊取數(shù)據(jù)。
整個(gè)過(guò)程攻擊者并不能獲取到受害者的登錄憑證，僅僅是“冒用”。
跨站請(qǐng)求可以用各種方式：圖片URL、超鏈接、CORS、Form提交等等。部分請(qǐng)求方式可以直接嵌入在第三方論壇、文章中，難以進(jìn)行追蹤。
由上面對(duì)CSRF的介紹我們知道了，CSRF通常發(fā)生在第三方域名，并且CSRF攻擊者不能獲取到受害者的cookie等信息，只是借用他們的登錄狀態(tài)來(lái)偽造請(qǐng)求。所以我們可以針對(duì)這兩點(diǎn)來(lái)制定防范措施：
既然CSRF大多來(lái)自第三方網(wǎng)站，那么我們就直接禁止第三方域名（或者不受信任的域名）對(duì)我們發(fā)起請(qǐng)求。
在HTTP協(xié)議中，每一個(gè)異步請(qǐng)求都會(huì)攜帶兩個(gè)Header，用于標(biāo)記來(lái)源域名：
Origin Header
Referer Header
這兩個(gè)Header在瀏覽器發(fā)起請(qǐng)求時(shí)，大多數(shù)情況會(huì)自動(dòng)帶上，并且不能由前端自定義內(nèi)容。 服務(wù)器可以通過(guò)解析這兩個(gè)Header中的域名，確定請(qǐng)求的來(lái)源域。同時(shí)服務(wù)器應(yīng)該優(yōu)先檢測(cè) Origin。為了安全考慮，相比于 Referer，Origin 只包含了域名而不帶路徑。
在瀏覽器向服務(wù)器發(fā)起請(qǐng)求時(shí)，服務(wù)器生成一個(gè) CSRF Token。CSRF Token 其實(shí)就是服務(wù)器生成的隨機(jī)字符串，然后將該字符串植入到返回的頁(yè)面中，通常是放到表單的隱藏輸入框中，這樣能夠很好的保護(hù) CSRF Token 不被泄漏；
當(dāng)瀏覽器再次發(fā)送請(qǐng)求的時(shí)候，就需要攜帶這個(gè) CSRF Token 值一起提交；
服務(wù)器驗(yàn)證 CSRF Token 是否一致；從第三方網(wǎng)站發(fā)出的請(qǐng)求是無(wú)法獲取用戶頁(yè)面中的 CSRF Token 值的。
當(dāng)從 A 網(wǎng)站登錄后，會(huì)從響應(yīng)頭中返回服務(wù)器設(shè)置的 Cookie 信息，而如果 Cookie 攜帶了 SameSite=strict 則表示完全禁用第三方站點(diǎn)請(qǐng)求頭攜帶 Cookie，比如當(dāng)從 B 網(wǎng)站請(qǐng)求 A 網(wǎng)站接口的時(shí)候，瀏覽器的請(qǐng)求頭將不會(huì)攜帶該 Cookie。
Samesite=Strict，這種稱為嚴(yán)格模式，表明這個(gè) Cookie 在任何情況下都不可能作為第三方 Cookie
Samesite=Lax，這種稱為寬松模式，比 Strict 放寬了點(diǎn)限制：假如這個(gè)請(qǐng)求是這種請(qǐng)求（改變了當(dāng)前頁(yè)面或者打開了新頁(yè)面）且同時(shí)是個(gè)GET請(qǐng)求，則這個(gè)Cookie可以作為第三方Cookie。（默認(rèn)）
None 任何情況下都會(huì)攜帶；
點(diǎn)擊劫持（Clickjacking）是一種通過(guò)視覺欺騙的手段來(lái)達(dá)到攻擊目的手段。往往是攻擊者將目標(biāo)網(wǎng)站通過(guò) iframe 嵌入到自己的網(wǎng)頁(yè)中，通過(guò) opacity 等手段設(shè)置 iframe 為透明的，使得肉眼不可見，這樣一來(lái)當(dāng)用戶在攻擊者的網(wǎng)站中操作的時(shí)候，比如點(diǎn)擊某個(gè)按鈕（這個(gè)按鈕的頂層其實(shí)是 iframe），從而實(shí)現(xiàn)目標(biāo)網(wǎng)站被點(diǎn)擊劫持。
在HTTP投中加入 X-FRAME-OPTIONS 屬性，此屬性控制頁(yè)面是否可被嵌入 iframe 中
DENY：不能被所有網(wǎng)站嵌套或加載；
SAMEORIGIN：只能被同域網(wǎng)站嵌套或加載；
ALLOW-FROM URL：可以被指定網(wǎng)站嵌套或加載。
判斷當(dāng)前網(wǎng)頁(yè)是否被 iframe 嵌套
HTTP嚴(yán)格傳輸安全(HSTS)是一種安全功能，web服務(wù)器通過(guò)它來(lái)告訴瀏覽器僅用HTTPS來(lái)與之通訊，而不是使用HTTP。
HSTS代表HTTP嚴(yán)格傳輸安全性，由IETF在2012年的RFC 6797中指定。創(chuàng)建它是為了在站點(diǎn)通過(guò)HTTPS運(yùn)行時(shí)強(qiáng)制瀏覽器使用安全連接。它是您添加到Web服務(wù)器的安全標(biāo)頭，并在響應(yīng)標(biāo)頭中反映為Strict-Transport-Security。HSTS很重要，因?yàn)樗鉀Q了以下問(wèn)題：
訪問(wèn)者嘗試使用您網(wǎng)站頁(yè)面的不安全版本 (HTTP://) 的任何嘗試都將自動(dòng)轉(zhuǎn)發(fā)到安全版本 (HTTPS://)。
舊的HTTP書簽和輸入您網(wǎng)站的HTTP版本的人會(huì)讓您面臨中間人攻擊。在這些攻擊中，攻擊者改變各方之間的通信并誘使他們認(rèn)為他們?nèi)栽谙嗷ネㄐ拧?/p>
不允許覆蓋無(wú)效的證書消息，這反過(guò)來(lái)又保護(hù)了訪問(wèn)者。
Cookie劫持：當(dāng)有人通過(guò)不安全的連接竊取會(huì)話cookie時(shí)，就會(huì)發(fā)生這種情況。Cookie可以包含各種有價(jià)值的信息，例如信用卡信息、姓名、地址等。
注意，如果之前沒有使用HTTPS協(xié)議訪問(wèn)過(guò)該站點(diǎn)，那么HSTS是不奏效的，只有瀏覽器曾經(jīng)與服務(wù)器創(chuàng)建過(guò)一次安全連接并且網(wǎng)站通過(guò)HTTPS協(xié)議告訴瀏覽器它支持HSTS，那么之后瀏覽器才會(huì)強(qiáng)制使用HTTPS，即使鏈接被換成了HTTP。
雖然我們的系統(tǒng)默認(rèn)更喜歡HTTPS版本，但您也可以通過(guò)將您的HTTP站點(diǎn)重定向到您的HTTPS版本并在您的服務(wù)器上實(shí)施HSTS標(biāo)頭，使其他搜索引擎更清楚這一點(diǎn)。 —— 谷歌安全團(tuán)隊(duì)
在Apache中啟用HSTS
將以下代碼添加到您的虛擬主機(jī)文件中。
Header always set Strict-Transport-Security max-age=31536000
在NGINX中啟用 HSTS
將以下代碼添加到您的NGINX配置中。
add_header Strict-Transport-Security max-age=31536000
事實(shí)上，添加HSTS標(biāo)頭有性能優(yōu)勢(shì)。如果有人試圖通過(guò)HTTP訪問(wèn)您的站點(diǎn)，而不是發(fā)出HTTP請(qǐng)求，它只是重定向到HTTPS版本。
它的名字就叫做CDN——Content Delivery Network，內(nèi)容分發(fā)網(wǎng)絡(luò)。具體來(lái)說(shuō)，CDN就是采用更多的緩存服務(wù)器（CDN邊緣節(jié)點(diǎn)），布放在用戶訪問(wèn)相對(duì)集中的地區(qū)或網(wǎng)絡(luò)中。當(dāng)用戶訪問(wèn)網(wǎng)站時(shí)，利用全局負(fù)載技術(shù)，將用戶的訪問(wèn)指向距離最近的緩存服務(wù)器上，由緩存服務(wù)器響應(yīng)用戶請(qǐng)求。（有點(diǎn)像電商的本地倉(cāng)吧？）CDN應(yīng)用廣泛，支持多種行業(yè)、多種場(chǎng)景內(nèi)容加速，例如：圖片小文件、大文件下載、視音頻點(diǎn)播、直播流媒體、全站加速、安全加速。
網(wǎng)絡(luò)上有很多黑客為了讓用戶能夠登錄自己開發(fā)的釣魚網(wǎng)站，都會(huì)通過(guò)對(duì)CDN進(jìn)行劫持的方法，讓用戶自動(dòng)轉(zhuǎn)入自己開發(fā)的網(wǎng)站。而很多用戶卻往往無(wú)法察覺到自己已經(jīng)被劫持。其實(shí)驗(yàn)證被劫持的方法，就是輸入任何網(wǎng)址看看所打開的網(wǎng)頁(yè)是否和自己輸入的網(wǎng)址一致，
SRI 全稱 Subresource Integrity - 子資源完整性，是指瀏覽器通過(guò)驗(yàn)證資源的完整性（通常從 CDN 獲?。﹣?lái)判斷其是否被篡改的安全特性。
通過(guò)給 link 標(biāo)簽或者 script 標(biāo)簽增加 integrity 屬性即可開啟 SRI 功能，比如
<script type="text/javascript" src="//s.url.cn/xxxx/aaa.js" integrity="sha256-xxx sha384-yyy" crossorigin="anonymous"></script>
integrity 值分成兩個(gè)部分，第一部分指定哈希值的生成算法（sha256、sha384 及 sha512），第二部分是經(jīng)過(guò) base64 編碼的實(shí)際哈希值，兩者之間通過(guò)一個(gè)短橫（-）分割。integrity 值可以包含多個(gè)由空格分隔的哈希值，只要文件匹配其中任意一個(gè)哈希值，就可以通過(guò)校驗(yàn)并加載該資源。開啟 SRI 能有效保證頁(yè)面引用資源的完整性，避免惡意代碼執(zhí)行。
當(dāng)瀏覽器在 script 或者 link 標(biāo)簽中遇到 integrity 屬性之后，會(huì)在執(zhí)行腳本或者應(yīng)用樣式表之前對(duì)比所加載文件的哈希值和期望的哈希值。
當(dāng)腳本或者樣式表的哈希值和期望的不一致時(shí)，瀏覽器必須拒絕執(zhí)行腳本或者應(yīng)用樣式表，并且必須返回一個(gè)網(wǎng)絡(luò)錯(cuò)誤說(shuō)明獲得腳本或樣式表失敗。
內(nèi)容安全策略（Content Security Policy）簡(jiǎn)稱 CSP，通過(guò)它可以明確的告訴客戶端瀏覽器當(dāng)前頁(yè)面的哪些外部資源可以被加載執(zhí)行，而哪些又是不可以的。
防XSS等攻擊的利器。CSP 的實(shí)質(zhì)就是白名單制度，開發(fā)者明確告訴客戶端，哪些外部資源可以加載和執(zhí)行，等同于提供白名單。它的實(shí)現(xiàn)和執(zhí)行全部由瀏覽器完成，開發(fā)者只需提供配置。CSP 大大增強(qiáng)了網(wǎng)頁(yè)的安全性。攻擊者即使發(fā)現(xiàn)了漏洞，也沒法注入腳本，除非還控制了一臺(tái)列入了白名單的可信主機(jī)。
Content-Security-Policy 配置好并啟用后，不符合 CSP 的外部資源就會(huì)被阻止加載。
Content-Security-Policy-Report-Only 表示不執(zhí)行限制選項(xiàng)，只是記錄違反限制的行為。它必須與report-uri選項(xiàng)配合使用。
通過(guò) HTTP 頭配置 Content-Security-Policy，以下配置說(shuō)明該頁(yè)面只允許當(dāng)前源和 https://apis.google.com 這 2 個(gè)源的腳本加載和執(zhí)行：
Content-Security-Policy: script-src 'self' https://apis.google.com
通過(guò)頁(yè)面 <meta> 標(biāo)簽配置：
<meta http-equiv="Content-Security-Policy" content="script-src 'self' https://apis.google.com">
多進(jìn)程的瀏覽器架構(gòu)將主要分為兩塊：瀏覽器內(nèi)核和渲染內(nèi)核。而安全沙箱能限制了渲染進(jìn)程對(duì)操作系統(tǒng)資源的訪問(wèn)和修改，同時(shí)渲染進(jìn)程內(nèi)部也沒有讀寫操作系統(tǒng)的能力，而這些都是在瀏覽器內(nèi)核中一一實(shí)現(xiàn)了，包括持久存儲(chǔ)、網(wǎng)絡(luò)訪問(wèn)和用戶交互等一系列直接與操作系統(tǒng)交互的功能。瀏覽器內(nèi)核和渲染內(nèi)核各自職責(zé)分明，當(dāng)他們需要進(jìn)行數(shù)據(jù)傳輸?shù)臅r(shí)候會(huì)通過(guò) IPC 進(jìn)行。
而渲染進(jìn)程的工作是進(jìn)行 HTML、CSS 的解析，JavaScript 的執(zhí)行等，而這部分內(nèi)容是直接暴露給用戶的，所以也是最容易被黑客利用攻擊的地方，如果黑客攻擊了這里就有可能獲取到渲染進(jìn)程的權(quán)限，進(jìn)而威脅到操作系統(tǒng)。所以需要一道墻用來(lái)把不可信任的代碼運(yùn)行在一定的環(huán)境中，限制不可信代碼訪問(wèn)隔離區(qū)之外的資源，而這道墻就是瀏覽器的安全沙箱。
安全沙箱的存在是為了保護(hù)客戶端操作系統(tǒng)免受黑客攻擊，但是阻止不了 XSS 和 CSRF。
安全沙箱是利用操作系統(tǒng)提供的安全技術(shù)，這樣渲染進(jìn)程在運(yùn)行中就無(wú)法獲取或修改操作系統(tǒng)中的數(shù)據(jù)。安全沙箱最小隔離單位是進(jìn)程，所以無(wú)法保護(hù)單進(jìn)程瀏覽器。
iframe在給我們的頁(yè)面帶來(lái)更多豐富的內(nèi)容和能力的同時(shí)，也帶來(lái)了不少的安全隱患。因?yàn)閕frame中的內(nèi)容是由第三方來(lái)提供的，默認(rèn)情況下他們不受我們的控制，他們可以在iframe中運(yùn)行JavaScirpt腳本、Flash插件、彈出對(duì)話框等等，這可能會(huì)破壞前端用戶體驗(yàn)。
js的防御方案：將下面這段代碼放到網(wǎng)站頁(yè)面的</body>標(biāo)簽前，這樣別人在通過(guò)iframe框架引用你的網(wǎng)站網(wǎng)頁(yè)時(shí)，瀏覽器會(huì)自動(dòng)跳轉(zhuǎn)到你的網(wǎng)站所引用的頁(yè)面上。
<script>
if (self == top) {
var theBody = document.getElementsByTagName('body')[0];
theBody.style.display = "block";
} else {
top.location = self.location;
}
</script>使用X-Frame-Options防止網(wǎng)頁(yè)被iframe：X-FRAME-OPTIONS是微軟提出的一個(gè)http頭，專門用來(lái)防御利用iframe嵌套的點(diǎn)擊劫持攻擊。
DENY // 拒絕任何域加載 SAMEORIGIN // 允許同源域下加載 ALLOW-FROM // 可以定義允許frame加載的頁(yè)面地址
sandbox是html5的新屬性，主要是提高iframe安全系數(shù)。iframe因安全問(wèn)題而臭名昭著，這主要是因?yàn)閕frame常被用于嵌入到第三方中，然后執(zhí)行某些惡意操作?！具@個(gè)與上面說(shuō)到的安全沙箱（Sandbox）不同】 現(xiàn)在有一場(chǎng)景：我的網(wǎng)站需要 iframe 引用某網(wǎng)站，但是不想被該網(wǎng)站操作DOM、不想加載某些js（廣告、彈框等）、當(dāng)前窗口被強(qiáng)行跳轉(zhuǎn)鏈接等，我們可以設(shè)置 sandbox 屬性:
allow-same-origin：允許被視為同源，即可操作父級(jí)DOM或cookie等
allow-top-navigation：允許當(dāng)前iframe的引用網(wǎng)頁(yè)通過(guò)url跳轉(zhuǎn)鏈接或加載
allow-forms：允許表單提交
allow-scripts：允許執(zhí)行腳本文件
allow-popups：允許瀏覽器打開新窗口進(jìn)行跳轉(zhuǎn)
“”：設(shè)置為空時(shí)上面所有允許全部禁止
讀到這里，這篇“web前端常見的安全問(wèn)題及怎么防范措施”文章已經(jīng)介紹完畢，想要掌握這篇文章的知識(shí)點(diǎn)還需要大家自己動(dòng)手實(shí)踐使用過(guò)才能領(lǐng)會(huì)，如果想了解更多相關(guān)內(nèi)容的文章，歡迎關(guān)注億速云行業(yè)資訊頻道。
免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱：is@yisu.com進(jìn)行舉報(bào)，并提供相關(guān)證據(jù)，一經(jīng)查實(shí)，將立刻刪除涉嫌侵權(quán)內(nèi)容。
億速云公眾號(hào)
手機(jī)網(wǎng)站二維碼