瀏覽器安全可分為三大塊——Web頁(yè)面安全、瀏覽器網(wǎng)絡(luò)安全和瀏覽器系統(tǒng)安全。這里是Web頁(yè)面安全。

一、瀏覽器的同源策略

如果兩個(gè)url協(xié)議、域名和端口都相同，那么就稱這兩個(gè)URL同源。瀏覽器默認(rèn)同源的兩個(gè)源之間是可以相互訪問(wèn)資源和操作DOM的。兩個(gè)不同的源之間想要互相訪問(wèn)資源或者操作DOM，那么會(huì)有一套基礎(chǔ)的安全策略的制約，我們把這稱為同源策略。

同源策略主要表現(xiàn)在DOM、Web數(shù)據(jù)和網(wǎng)絡(luò)這三個(gè)層面

１、DOM層面

同源策略限制了來(lái)自不同源的JavaScript腳本對(duì)當(dāng)前DOM對(duì)象讀和寫的操作

要是不同源的站點(diǎn)操作DOM就會(huì)報(bào)錯(cuò)：Uncaught DOMException

２、Web數(shù)據(jù)

同源策略限制了不同源站點(diǎn)讀取當(dāng)前站點(diǎn)的Cookie、IndexDB、LocalStorage等數(shù)據(jù)。

3、網(wǎng)絡(luò)

同源策略限制了通過(guò)XMLHttpRequest等方式將站點(diǎn)數(shù)據(jù)發(fā)送給不同源的站點(diǎn)。默認(rèn)情況下，XMLHttpRequest不能訪問(wèn)跨域的資源

二、犧牲一些安全性，增加一些便利性

瀏覽器犧牲了一些安全性，來(lái)讓W(xué)eb開發(fā)和使用相對(duì)便捷。讓出的安全性就衍生出了一些安全問(wèn)題。比方說(shuō)引入外部資源文件就出現(xiàn)XSS風(fēng)險(xiǎn)，進(jìn)而出現(xiàn)CSP減少XSS攻擊。

1、頁(yè)面中可以嵌入第三方資源

頁(yè)面需要引入外部不同源的文件，當(dāng)惡意程序通過(guò)各種途徑向HTML插入script標(biāo)簽的惡意腳本，當(dāng)頁(yè)面啟動(dòng)時(shí)，這個(gè)腳本就會(huì)執(zhí)行。它能修改用戶的搜索結(jié)果、改變一些內(nèi)容的鏈接指向、竊取如Cookie、IndexDB、LoacalStorage等數(shù)據(jù)，通過(guò)XSS的手段發(fā)送給服務(wù)器。為了應(yīng)對(duì)XSS攻擊，瀏覽器引入了內(nèi)容安全策略CSP，CSP的核心思想是讓服務(wù)器決定瀏覽器能夠加載哪些資源，讓服務(wù)器決定瀏覽器是否能夠執(zhí)行內(nèi)聯(lián)JavaScript代碼，CSP能夠大大減少XSS攻擊。

2、跨域資源共享和跨文檔消息機(jī)制

XMLHttpRequest因?yàn)橥床呗圆荒茉L問(wèn)不同源的資源，但實(shí)際上很多時(shí)候又需要訪問(wèn)不同源資源。

為了訪問(wèn)不同源的資源，引入了跨域資源共享（CSRS），使用此機(jī)制可以進(jìn)行跨域訪問(wèn)控制，是跨域可以安全的進(jìn)行。

兩個(gè)不同源的頁(yè)面不可以互相操作DOM，在實(shí)際應(yīng)用中，經(jīng)常需要兩個(gè)不同源之間的DOM之間進(jìn)行通信，于是引入了跨文檔消息機(jī)制，即通過(guò)window.postMessage的JavaScript接口來(lái)和不同源的DOM進(jìn)行通信

三、XSS攻擊

XSS（Cross Site Scripting）是跨站腳本攻擊，為了與“CSS”區(qū)分，所以叫XSS，翻譯過(guò)來(lái)就是跨站腳本

最開始的時(shí)候，這種攻擊是通過(guò)跨域來(lái)實(shí)現(xiàn)的，所以叫“跨站腳本”。但是現(xiàn)在往HTML中注入惡意代碼的方式越來(lái)越多了，所以是否跨域注入腳本已經(jīng)不是唯一的注入手段，但是XSS這個(gè)名字卻一直保留至今。

1、惡意腳本可以做哪些事情

• 可以竊取Cookie信息。惡意JavaScript可以通過(guò)“document.Cookie”獲取Cookie信息，然后通過(guò)XMLHttpRequest或者Fetch加上CORS功能將數(shù)據(jù)發(fā)送給惡意服務(wù)器；惡意服務(wù)器拿到用戶的Cookie信息之后，就可以在其他電腦上模擬用戶的登錄

• 可以監(jiān)聽(tīng)用戶的行為。惡意JavaScript可以使用“addEventListener”接口來(lái)監(jiān)聽(tīng)鍵盤事件，比如可以獲取用戶輸入的信用卡等信息，欺騙用戶輸入用戶名和密碼等信息

• 可以修改DOM偽造假的登錄窗口，用來(lái)欺騙用戶輸入用戶名和密碼等信息

• 可以在頁(yè)面內(nèi)生成浮窗廣告，這些廣告嚴(yán)重地影響用戶體驗(yàn)

• 其他很多事情

2、惡意腳本是如何注入的

通常情況下，被惡意注入JavaScript腳本是非常危險(xiǎn)的。所以要知道有哪些注入方式。通常情況下，主要有存儲(chǔ)型XSS攻擊、反射型XSS攻擊和基于DOM的XSS攻擊三種方式來(lái)注入惡意腳本

① 存儲(chǔ)型XSS攻擊

攻擊者將惡意JavaScript代碼提交給服務(wù)器的數(shù)據(jù)庫(kù)，用戶訪問(wèn)服務(wù)器時(shí)，惡意JavaScript代碼隨著正常請(qǐng)求的頁(yè)面返回給用戶。

② 反射型XSS攻擊

在一個(gè)反射性XSS攻擊過(guò)程中，惡意JavaScript腳本屬于用戶發(fā)送給網(wǎng)站請(qǐng)求的一部分，隨后網(wǎng)站又將惡意JavaScript腳本返回給用戶。和存儲(chǔ)型XSS類似的是都要先把惡意JavaScript腳本發(fā)送給服務(wù)器，但是反射型XSS不會(huì)存儲(chǔ)這段惡意JavaScript代碼，而是直接返回。主要是通過(guò)用戶點(diǎn)擊惡意鏈接實(shí)現(xiàn)的

③ 基于DOM的XSS攻擊

基于DOM的XSS攻擊都是在瀏覽器端完成的，不要經(jīng)過(guò)服務(wù)器，基于DOM的XSS攻擊是屬于前端的安全漏洞。黑客通過(guò)各種手段將惡意腳本注入到用戶的頁(yè)面中，比如通過(guò)網(wǎng)絡(luò)劫持在頁(yè)面?zhèn)鬏斶^(guò)程中修改HTML頁(yè)面內(nèi)容，這種劫持類型很多，比如WiFi路由器劫持、通過(guò)本地惡意軟件劫持，它們的共同點(diǎn)是在Web資源傳輸過(guò)程或者在用戶使用頁(yè)面的過(guò)程中修改Web頁(yè)面的數(shù)據(jù)。

3、如何阻止XSS攻擊

存儲(chǔ)型XSS和反射型XSS都是需要經(jīng)過(guò)Web服務(wù)器來(lái)處理的，因此可以認(rèn)為這是服務(wù)器的安全漏洞。而基于DOM的XSS攻擊全部都是在瀏覽器端完成的，因此基于DOM的XSS攻擊是屬于前端的安全漏洞。

① 服務(wù)器對(duì)輸入腳本進(jìn)行過(guò)濾轉(zhuǎn)碼

• 過(guò)濾就是把script標(biāo)簽以及其中的內(nèi)容直接過(guò)濾掉。（就是刪除）

• 轉(zhuǎn)碼就是把script標(biāo)簽等敏感字符替換

② 充分利用CSP

雖然服務(wù)器過(guò)濾轉(zhuǎn)碼能夠阻止XSS攻擊的發(fā)生，但完全依靠服務(wù)器端依然是不夠的，我們還需要CSP等策略充分地利用起來(lái)，以降低XSS攻擊帶來(lái)的風(fēng)險(xiǎn)和后果。

• 限制加載其他域下面的資源文件，這樣即使黑客插入了一個(gè)JavaScript文件，這個(gè)JavaScript文件也是無(wú)法被加載的

• 禁止向第三方域提交數(shù)據(jù)，這樣用戶數(shù)據(jù)也不會(huì)外泄

• 禁止執(zhí)行內(nèi)聯(lián)腳本和未授權(quán)的腳本

• 提供了上報(bào)機(jī)制，這樣可以幫助我們盡快發(fā)現(xiàn)有哪些XSS攻擊，以便盡快修復(fù)問(wèn)題

③ 使用HttpOnly屬性

很多XSS攻擊都喜歡盜用Cookie，服務(wù)器可以在設(shè)置Cookie時(shí)添加HttpOnly屬性，這樣document.cookie就無(wú)法獲取cookie了。

四、CSRF攻擊

CSRF(Cross Site request forgery)——跨站請(qǐng)求偽造。指黑客引誘用戶打開黑客的網(wǎng)站，在黑客的網(wǎng)站中，利用用戶的登陸狀態(tài)發(fā)起跨站的請(qǐng)求。主要有三種方式去實(shí)施CSRF攻擊：自動(dòng)發(fā)起Get請(qǐng)求、自動(dòng)發(fā)起Post請(qǐng)求、引誘用戶點(diǎn)擊鏈接。和XSS不同的是，CSRF攻擊不需要將惡意代碼注入用戶的頁(yè)面，僅僅是利用服務(wù)器的漏洞和用戶的登錄狀態(tài)來(lái)實(shí)施攻擊。

1、CSRF是如何發(fā)起偽造請(qǐng)求的

① 自動(dòng)發(fā)起Get請(qǐng)求

黑客把一個(gè)請(qǐng)求接口隱藏在img標(biāo)簽中，欺騙瀏覽器這是一個(gè)圖片資源。頁(yè)面加載的時(shí)候?yàn)g覽器會(huì)自動(dòng)發(fā)起img的資源請(qǐng)求，如果服務(wù)器沒(méi)有對(duì)該請(qǐng)求做判斷的話，就會(huì)被執(zhí)行。如果這是一個(gè)轉(zhuǎn)賬請(qǐng)求，錢就被轉(zhuǎn)走了

② 自動(dòng)發(fā)起Post請(qǐng)求

黑客在他的頁(yè)面構(gòu)造了一個(gè)隱藏的表單，表單就是一個(gè)轉(zhuǎn)賬接口。當(dāng)用戶打開該站點(diǎn)之后，這個(gè)表單就會(huì)被自動(dòng)執(zhí)行提交；當(dāng)表單被提交，就會(huì)執(zhí)行轉(zhuǎn)賬操作。

③ 引誘用戶點(diǎn)擊鏈接

黑客還可以誘惑用戶去點(diǎn)擊黑客站點(diǎn)的鏈接，這種方式常常出現(xiàn)在論壇或者惡意郵件上。黑客會(huì)采用很多方式去誘惑用戶點(diǎn)擊鏈接。比如黑客說(shuō)這是一張美女圖片，放了圖片的下載地址，而這個(gè)下載地址實(shí)際上是黑客用來(lái)轉(zhuǎn)賬的接口，一旦用戶點(diǎn)擊了這個(gè)鏈接，他的錢就會(huì)被轉(zhuǎn)到黑客賬戶上了。

2、如何阻止CSRF

CSRF發(fā)起攻擊有三個(gè)必要條件：目標(biāo)站點(diǎn)必須要有CSRF漏洞、用戶要登錄過(guò)目標(biāo)站點(diǎn)，并持有目標(biāo)站點(diǎn)的Cookie、第三個(gè)需要用戶打開一個(gè)第三方站點(diǎn)，可以是黑客的站點(diǎn)或者是一些論壇

① 利用Cookie的SameSite屬性

在HTTP響應(yīng)頭中，通過(guò)設(shè)置set-cookie字段設(shè)置Cookie時(shí)，可以帶上SameSite選項(xiàng)，SameSite有三個(gè)值：Strict、Lax和None

• Strict會(huì)完全禁用第三方Cookie。從B網(wǎng)站訪問(wèn)A網(wǎng)站無(wú)論如何都不會(huì)帶上A網(wǎng)站的Cookie

• Lax相對(duì)寬松一點(diǎn)，從B網(wǎng)站提交Get表單到A網(wǎng)站或者從B網(wǎng)站打開A網(wǎng)站的鏈接都會(huì)帶上Cookie，Post或者img、iframe等都不會(huì)攜帶Cookie

• None的話，就是任何情況下都可以發(fā)生Cookie

② 驗(yàn)證請(qǐng)求的來(lái)源站點(diǎn)

服務(wù)器可以通過(guò)驗(yàn)證請(qǐng)求來(lái)源的站點(diǎn)，禁用來(lái)自第三方的請(qǐng)求。

Referer是請(qǐng)求頭中的一個(gè)字段，記錄了HTTP請(qǐng)求的來(lái)源地址，Referer可以告訴服務(wù)器HTTP請(qǐng)求的來(lái)源，這只是一個(gè)選項(xiàng)，因?yàn)橛行﹫?chǎng)景不適合將Referer發(fā)送給服務(wù)器。

Origin屬性，通過(guò)XMLHttpRequest、Fetch發(fā)起跨站請(qǐng)求或者通過(guò)Post方法發(fā)送請(qǐng)求時(shí)，都會(huì)帶上Origin屬性。Origin屬性和Referer的區(qū)別是Origin只包含了域名信息，沒(méi)有包含具體的URL路徑，這是因?yàn)橛行┱军c(diǎn)因?yàn)榘踩紤]，不想把源站點(diǎn)的詳細(xì)路徑暴露給服務(wù)器。

服務(wù)器的策略是優(yōu)先判斷Origin，如果請(qǐng)求頭中沒(méi)有包含Origin屬性，再根據(jù)實(shí)際情況判斷是否使用Referer值

③ CSRF Token

CSRF Token驗(yàn)證分為兩步

第一步：客戶端發(fā)起請(qǐng)求后，服務(wù)器生成一個(gè)CSRF Token，即服務(wù)器生成的字符串，然后將該字符串植入到返回的頁(yè)面中

第二步：在瀏覽器端如果要發(fā)起轉(zhuǎn)賬請(qǐng)求，那么需要帶上頁(yè)面中的CSRF Token，然后服務(wù)器會(huì)驗(yàn)證該Token是否合法。如果是從第三方站點(diǎn)發(fā)出的請(qǐng)求，那么將無(wú)法獲取到CSRF中的值，所以即使發(fā)出了請(qǐng)求，服務(wù)器也會(huì)因?yàn)镃SRF Token不正確而拒絕請(qǐng)求。

了解更多，請(qǐng)點(diǎn)擊：https://www.bilibili.com/video/BV19D4y197os/

作者：寶榮
鏈接：https://juejin.cn/post/6911548730638336013
來(lái)源：掘金
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。