前言

隨著互聯(lián)網(wǎng)的高速發(fā)展，信息安全問(wèn)題已經(jīng)成為行業(yè)最為關(guān)注的焦點(diǎn)之一?？偟膩?lái)說(shuō)安全是很復(fù)雜的一個(gè)領(lǐng)域，在移動(dòng)互聯(lián)網(wǎng)時(shí)代，前端人員除了傳統(tǒng)的 XSS、CSRF 等安全問(wèn)題之外，還時(shí)常遭遇網(wǎng)絡(luò)劫持、非法調(diào)用 Hybrid API 等新型安全問(wèn)題。這篇文章會(huì)介紹一些常見(jiàn)的安全問(wèn)題及如何防范的內(nèi)容，在當(dāng)下其實(shí)安全問(wèn)題越來(lái)越重要，已經(jīng)逐漸成為前端開(kāi)發(fā)必備的技能了。

前端安全問(wèn)題

跨站腳本攻擊（XSS）

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)注入惡意腳本：

反射型XSS攻擊

顧名思義，惡意 JavaScript 腳本屬于用戶發(fā)送給網(wǎng)站請(qǐng)求中的一部分，隨后網(wǎng)站又將這部分返回給用戶，惡意腳本在頁(yè)面中被執(zhí)行。一般發(fā)生在前后端一體的應(yīng)用中，服務(wù)端邏輯會(huì)改變最終的網(wǎng)頁(yè)代碼。

反射型 XSS 的攻擊步驟：

• 攻擊者構(gòu)造出特殊的 URL，其中包含惡意代碼。
• 用戶打開(kāi)帶有惡意代碼的 URL 時(shí)，網(wǎng)站服務(wù)端將惡意代碼從 URL 中取出，拼接在 HTML 中返回給瀏覽器。
• 用戶瀏覽器接收到響應(yīng)后解析執(zhí)行，混在其中的惡意代碼也被執(zhí)行。
• 惡意代碼竊取用戶數(shù)據(jù)并發(fā)送到攻擊者的網(wǎng)站，或者冒充用戶的行為，調(diào)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作。

基于DOM的XSS攻擊

目前更流行前后端分離的項(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，其中包含惡意代碼。
• 用戶打開(kāi)帶有惡意代碼的 URL。
• 用戶瀏覽器接收到響應(yīng)后解析執(zhí)行，前端 JavaScript 取出 URL 中的惡意代碼并執(zhí)行。
• 惡意代碼竊取用戶數(shù)據(jù)并發(fā)送到攻擊者的網(wǎng)站，或者冒充用戶的行為，調(diào)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作。

存儲(chǔ)型XSS攻擊

又叫持久型 XSS，顧名思義，黑客將惡意 JavaScript 腳本長(zhǎng)期保存在服務(wù)端數(shù)據(jù)庫(kù)中，用戶一旦訪問(wèn)相關(guān)頁(yè)面數(shù)據(jù)，惡意腳本就會(huì)被執(zhí)行。常見(jiàn)于搜索、微博、社區(qū)貼吧評(píng)論等。

存儲(chǔ)型 XSS 的攻擊步驟：

• 攻擊者將惡意代碼提交到目標(biāo)網(wǎng)站的數(shù)據(jù)庫(kù)中。
• 用戶打開(kāi)目標(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攻擊類型的區(qū)別

• 反射型的 XSS 的惡意腳本存在 URL 里，存儲(chǔ)型 XSS 的惡意代碼存在數(shù)據(jù)庫(kù)里。

• 反射型 XSS 攻擊常見(jiàn)于通過(guò) URL 傳遞參數(shù)的功能，如網(wǎng)站搜索、跳轉(zhuǎn)等。

• 存儲(chǔ)型XSS攻擊常見(jiàn)于帶有用戶保存數(shù)據(jù)的網(wǎng)站功能，如論壇發(fā)帖、商品評(píng)論、用戶私信等。

• 而基于DOM的XSS 攻擊中，取出和執(zhí)行惡意代碼由瀏覽器端完成，屬于前端 JavaScript 自身的安全漏洞，其他兩種 XSS 都屬于服務(wù)端的安全漏洞。

XSS防范措施

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

• 攻擊者提交惡意代碼
• 瀏覽器執(zhí)行惡意代碼

所以我們可以針對(duì)這兩點(diǎn)來(lái)制定防范措施：

輸入過(guò)濾

在用戶提交時(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)避免此類方法。

預(yù)防存儲(chǔ)型和反射型 XSS 攻擊

• 改成純前端渲染，把代碼和數(shù)據(jù)分隔開(kāi)。
• 對(duì) HTML 做充分轉(zhuǎn)義。

預(yù)防 DOM 型 XSS 攻擊

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)聽(tīng)器，如 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)聽(tīng)器中包含惡意代碼 -->
<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>

Content Security Policy

嚴(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)操作。

XSS攻擊案例

• 2005年，年僅19歲的 Samy Kamkar 發(fā)起了對(duì) MySpace.com 的 XSS Worm 攻擊。 Samy Kamkar 的蠕蟲(chóng)在短短幾小時(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月，百度空間收到蠕蟲(chóng)攻擊，用戶之間開(kāi)始轉(zhuǎn)發(fā)垃圾短消息。

• QQ 郵箱 m.exmail.qq.com 域名被發(fā)現(xiàn)反射型 XSS 漏洞

• 2011年新浪微博曾被黑客 XSS 攻擊，黑客誘導(dǎo)用戶點(diǎn)擊一個(gè)帶有誘惑性的鏈接，便會(huì)自動(dòng)發(fā)送一條帶有同樣誘惑性鏈接微博。攻擊范圍層層擴(kuò)大，也是一種蠕蟲(chóng)攻擊。

跨站請(qǐng)求偽造（CSRF）

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是怎么攻擊的？

典型的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)求

常見(jiàn)的CSRF攻擊類型

GET類型的CSRF

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)求。

POST類型的CSRF

這種類型的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

鏈接類型的CSRF并不常見(jiàn)，比起其他兩種用戶打開(kāi)頁(yè)面就中招的情況，這種需要用戶點(diǎn)擊鏈接才會(huì)觸發(fā)。這種類型通常是在論壇中發(fā)布的圖片中嵌入惡意鏈接，或者以廣告的形式誘導(dǎo)用戶中招，攻擊者通常會(huì)以比較夸張的詞語(yǔ)誘騙用戶點(diǎn)擊

  <a  rel="external nofollow"  taget="_blank">
  重磅消息??！
  <a/>

CSRF的特點(diǎn)

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

CSRF防范措施

由上面對(duì)CSRF的介紹我們知道了，CSRF通常發(fā)生在第三方域名，并且CSRF攻擊者不能獲取到受害者的cookie等信息，只是借用他們的登錄狀態(tài)來(lái)偽造請(qǐng)求。所以我們可以針對(duì)這兩點(diǎn)來(lái)制定防范措施：

同源檢測(cè)

既然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 只包含了域名而不帶路徑。

CSRF Token

• 在瀏覽器向服務(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 值的。

給 Cookie 設(shè)置合適的 SameSite

當(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è)面或者打開(kāi)了新頁(yè)面）且同時(shí)是個(gè)GET請(qǐng)求，則這個(gè)Cookie可以作為第三方Cookie。（默認(rèn)）

• None 任何情況下都會(huì)攜帶；

點(diǎn)擊劫持（ClickJacking）

點(diǎn)擊劫持（Clickjacking）是一種通過(guò)視覺(jué)欺騙的手段來(lái)達(dá)到攻擊目的手段。往往是攻擊者將目標(biāo)網(wǎng)站通過(guò) iframe 嵌入到自己的網(wǎng)頁(yè)中，通過(guò) opacity 等手段設(shè)置 iframe 為透明的，使得肉眼不可見(jiàn)，這樣一來(lái)當(dāng)用戶在攻擊者的網(wǎng)站中操作的時(shí)候，比如點(diǎn)擊某個(gè)按鈕（這個(gè)按鈕的頂層其實(shí)是 iframe），從而實(shí)現(xiàn)目標(biāo)網(wǎng)站被點(diǎn)擊劫持。

點(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）

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書(shū)簽和輸入您網(wǎng)站的HTTP版本的人會(huì)讓您面臨中間人攻擊。在這些攻擊中，攻擊者改變各方之間的通信并誘使他們認(rèn)為他們?nèi)栽谙嗷ネㄐ拧?/li>
• 不允許覆蓋無(wú)效的證書(shū)消息，這反過(guò)來(lái)又保護(hù)了訪問(wèn)者。
• Cookie劫持：當(dāng)有人通過(guò)不安全的連接竊取會(huì)話cookie時(shí)，就會(huì)發(fā)生這種情況。Cookie可以包含各種有價(jià)值的信息，例如信用卡信息、姓名、地址等。

注意，如果之前沒(méi)有使用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ì)

開(kāi)啟HSTS

在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劫持

CDN原理？

它的名字就叫做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)播、直播流媒體、全站加速、安全加速。

什么是CDN劫持？

網(wǎng)絡(luò)上有很多黑客為了讓用戶能夠登錄自己開(kāi)發(fā)的釣魚(yú)網(wǎng)站，都會(huì)通過(guò)對(duì)CDN進(jìn)行劫持的方法，讓用戶自動(dòng)轉(zhuǎn)入自己開(kāi)發(fā)的網(wǎng)站。而很多用戶卻往往無(wú)法察覺(jué)到自己已經(jīng)被劫持。其實(shí)驗(yàn)證被劫持的方法，就是輸入任何網(wǎng)址看看所打開(kāi)的網(wǎng)頁(yè)是否和自己輸入的網(wǎng)址一致，

CDN劫持防范措施

使用SRI來(lái)解決CDN劫持

SRI 全稱 Subresource Integrity - 子資源完整性，是指瀏覽器通過(guò)驗(yàn)證資源的完整性（通常從 CDN 獲?。﹣?lái)判斷其是否被篡改的安全特性。

通過(guò)給 link 標(biāo)簽或者 script 標(biāo)簽增加 integrity 屬性即可開(kāi)啟 SRI 功能，比如

<script type="text/javascript" src="http://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)并加載該資源。開(kāi)啟 SRI 能有效保證頁(yè)面引用資源的完整性，避免惡意代碼執(zhí)行。

瀏覽器如何處理 SRI

• 當(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)容安全策略（CSP）

內(nèi)容安全策略（Content Security Policy）簡(jiǎn)稱 CSP，通過(guò)它可以明確的告訴客戶端瀏覽器當(dāng)前頁(yè)面的哪些外部資源可以被加載執(zhí)行，而哪些又是不可以的。

CSP的意義

防XSS等攻擊的利器。CSP 的實(shí)質(zhì)就是白名單制度，開(kāi)發(fā)者明確告訴客戶端，哪些外部資源可以加載和執(zhí)行，等同于提供白名單。它的實(shí)現(xiàn)和執(zhí)行全部由瀏覽器完成，開(kāi)發(fā)者只需提供配置。CSP 大大增強(qiáng)了網(wǎng)頁(yè)的安全性。攻擊者即使發(fā)現(xiàn)了漏洞，也沒(méi)法注入腳本，除非還控制了一臺(tái)列入了白名單的可信主機(jī)。

CSP的分類

• Content-Security-Policy 配置好并啟用后，不符合 CSP 的外部資源就會(huì)被阻止加載。
• Content-Security-Policy-Report-Only 表示不執(zhí)行限制選項(xiàng)，只是記錄違反限制的行為。它必須與report-uri選項(xiàng)配合使用。

CSP的使用

• 通過(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">

安全沙箱（Sandbox）

多進(jìn)程的瀏覽器架構(gòu)將主要分為兩塊：瀏覽器內(nèi)核和渲染內(nèi)核。而安全沙箱能限制了渲染進(jìn)程對(duì)操作系統(tǒng)資源的訪問(wèn)和修改，同時(shí)渲染進(jìn)程內(nèi)部也沒(mé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

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)。

如何讓自己的網(wǎng)站不被其他網(wǎng)站的iframe引用？

• 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è)面地址

如何禁止被使用的 iframe 對(duì)當(dāng)前網(wǎng)站某些操作？

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：允許瀏覽器打開(kāi)新窗口進(jìn)行跳轉(zhuǎn)
• “”：設(shè)置為空時(shí)上面所有允許全部禁止

總結(jié)

到此這篇關(guān)于前端常見(jiàn)的安全問(wèn)題以及防范措施的文章就介紹到這了,更多相關(guān)前端常見(jiàn)安全問(wèn)題及防范內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論