隨著互聯(lián)網(wǎng)的發(fā)展，各種Web應(yīng)用變得越來(lái)越復(fù)雜，滿足了用戶(hù)的各種需求的同時(shí)，各種網(wǎng)絡(luò)安全問(wèn)題也接踵而至。作為前端工程師也逃不開(kāi)這個(gè)問(wèn)題，今天一起看一看Web前端有哪些安全問(wèn)題以及我們?nèi)绾稳z測(cè)和防范這些問(wèn)題。（非前端的攻擊如SQL注入，DDOS攻擊等本文不會(huì)討論）
QQ郵箱、新浪微博、YouTube、WordPress 和 百度 等知名網(wǎng)站都曾遭遇攻擊，如果你從未有過(guò)安全方面的問(wèn)題，不是因?yàn)槟闼_(kāi)發(fā)的網(wǎng)站很安全，更大的可能是你的網(wǎng)站的流量非常低或者沒(méi)有攻擊的價(jià)值。
1. XSS攻擊
XSS(Cross-Site Scripting，跨站腳本攻擊)是一種代碼注入攻擊。攻擊者在目標(biāo)網(wǎng)站上注入惡意代碼，當(dāng)被攻擊者登陸網(wǎng)站時(shí)就會(huì)執(zhí)行這些惡意代碼，這些腳本可以讀取 cookie，session tokens，或者其它敏感的網(wǎng)站信息，對(duì)用戶(hù)進(jìn)行釣魚(yú)欺詐，甚至發(fā)起蠕蟲(chóng)攻擊等。
XSS 的本質(zhì)是：惡意代碼未經(jīng)過(guò)濾，與網(wǎng)站正常的代碼混在一起；瀏覽器無(wú)法分辨哪些腳本是可信的，導(dǎo)致惡意腳本被執(zhí)行。由于直接在用戶(hù)的終端執(zhí)行，惡意代碼能夠直接獲取用戶(hù)的信息，利用這些信息冒充用戶(hù)向網(wǎng)站發(fā)起攻擊者定義的請(qǐng)求。
根據(jù)攻擊的來(lái)源，XSS攻擊可以分為存儲(chǔ)型(持久性)、反射型(非持久型)和DOM型三種。下面我們來(lái)詳細(xì)了解一下這三種XSS攻擊：
1.1 反射型XSS
當(dāng)用戶(hù)點(diǎn)擊一個(gè)惡意鏈接，或者提交一個(gè)表單，或者進(jìn)入一個(gè)惡意網(wǎng)站時(shí)，注入腳本進(jìn)入被攻擊者的網(wǎng)站。Web服務(wù)器將注入腳本，比如一個(gè)錯(cuò)誤信息，搜索結(jié)果等，未進(jìn)行過(guò)濾直接返回到用戶(hù)的瀏覽器上。
反射型 XSS 的攻擊步驟：
攻擊者構(gòu)造出特殊的 URL，其中包含惡意代碼。
用戶(hù)打開(kāi)帶有惡意代碼的 URL 時(shí)，網(wǎng)站服務(wù)端將惡意代碼從 URL 中取出，拼接在 HTML 中返回給瀏覽器。
用戶(hù)瀏覽器接收到響應(yīng)后解析執(zhí)行，混在其中的惡意代碼也被執(zhí)行。
惡意代碼竊取用戶(hù)數(shù)據(jù)并發(fā)送到攻擊者的網(wǎng)站，或者冒充用戶(hù)的行為，調(diào)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作。
反射型 XSS 漏洞常見(jiàn)于通過(guò) URL 傳遞參數(shù)的功能，如網(wǎng)站搜索、跳轉(zhuǎn)等。由于需要用戶(hù)主動(dòng)打開(kāi)惡意的 URL 才能生效，攻擊者往往會(huì)結(jié)合多種手段誘導(dǎo)用戶(hù)點(diǎn)擊。
POST 的內(nèi)容也可以觸發(fā)反射型 XSS，只不過(guò)其觸發(fā)條件比較苛刻（需要構(gòu)造表單提交頁(yè)面，并引導(dǎo)用戶(hù)點(diǎn)擊），所以非常少見(jiàn)。
1.2 DOM 型 XSS
DOM 型 XSS 攻擊，實(shí)際上就是前端 JavaScript 代碼不夠嚴(yán)謹(jǐn)，把不可信的內(nèi)容插入到了頁(yè)面。在使用 .innerHTML、.outerHTML、.appendChild、document.write()等API時(shí)要特別小心，不要把不可信的數(shù)據(jù)作為 HTML 插到頁(yè)面上，盡量使用 .innerText、.textContent、.setAttribute() 等。
DOM 型 XSS 的攻擊步驟：
攻擊者構(gòu)造出特殊數(shù)據(jù)，其中包含惡意代碼。
用戶(hù)瀏覽器執(zhí)行了惡意代碼。
惡意代碼竊取用戶(hù)數(shù)據(jù)并發(fā)送到攻擊者的網(wǎng)站，或者冒充用戶(hù)的行為，調(diào)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作。
如何防范 DOM 型 XSS 攻擊
防范 DOM 型 XSS 攻擊的核心就是對(duì)輸入內(nèi)容進(jìn)行轉(zhuǎn)義(DOM
中的內(nèi)聯(lián)事件監(jiān)聽(tīng)器和鏈接跳轉(zhuǎn)都能把字符串作為代碼運(yùn)行，需要對(duì)其內(nèi)容進(jìn)行檢查)。
對(duì)于url鏈接(例如圖片的src屬性)，那么直接使用 encodeURIComponent 來(lái)轉(zhuǎn)義。
非url，我們可以這樣進(jìn)行編碼：
> return str.replace(/"/g, '"')
>? ? ? ? ? ? .replace(/'/g, ''')
>? ? ? ? ? ? .replace(/</g, '<')
>? ? ? ? ? ? .replace(/>/g, '>'); }? ```
DOM 型 XSS 攻擊中，取出和執(zhí)行惡意代碼由瀏覽器端完成，屬于前端 JavaScript 自身的安全漏洞。
1.3 存儲(chǔ)型XSS
惡意腳本永久存儲(chǔ)在目標(biāo)服務(wù)器上。當(dāng)瀏覽器請(qǐng)求數(shù)據(jù)時(shí)，腳本從服務(wù)器傳回并執(zhí)行，影響范圍比反射型和DOM型XSS更大。存儲(chǔ)型XSS攻擊的原因仍然是沒(méi)有做好數(shù)據(jù)過(guò)濾：前端提交數(shù)據(jù)至服務(wù)端時(shí)，沒(méi)有做好過(guò)濾；服務(wù)端在接受到數(shù)據(jù)時(shí)，在存儲(chǔ)之前，沒(méi)有做過(guò)濾；前端從服務(wù)端請(qǐng)求到數(shù)據(jù)，沒(méi)有過(guò)濾輸出。
存儲(chǔ)型 XSS 的攻擊步驟：
攻擊者將惡意代碼提交到目標(biāo)網(wǎng)站的數(shù)據(jù)庫(kù)中。
用戶(hù)打開(kāi)目標(biāo)網(wǎng)站時(shí)，網(wǎng)站服務(wù)端將惡意代碼從數(shù)據(jù)庫(kù)取出，拼接在 HTML 中返回給瀏覽器。
用戶(hù)瀏覽器接收到響應(yīng)后解析執(zhí)行，混在其中的惡意代碼也被執(zhí)行。
惡意代碼竊取用戶(hù)數(shù)據(jù)并發(fā)送到攻擊者的網(wǎng)站，或者冒充用戶(hù)的行為，調(diào)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作。
這種攻擊常見(jiàn)于帶有用戶(hù)保存數(shù)據(jù)的網(wǎng)站功能，如論壇發(fā)帖、商品評(píng)論、用戶(hù)私信等。
如何防范存儲(chǔ)型XSS攻擊：
前端數(shù)據(jù)傳遞給服務(wù)器之前，先轉(zhuǎn)義/過(guò)濾(防范不了抓包修改數(shù)據(jù)的情況)
服務(wù)器接收到數(shù)據(jù)，在存儲(chǔ)到數(shù)據(jù)庫(kù)之前，進(jìn)行轉(zhuǎn)義/過(guò)濾
前端接收到服務(wù)器傳遞過(guò)來(lái)的數(shù)據(jù)，在展示到頁(yè)面前，先進(jìn)行轉(zhuǎn)義/過(guò)濾
除了謹(jǐn)慎的轉(zhuǎn)義，我們還需要其他一些手段來(lái)防范XSS攻擊:
1.Content Security Policy
在服務(wù)端使用 HTTP的 Content-Security-Policy 頭部來(lái)指定策略，或者在前端設(shè)置 meta 標(biāo)簽。
2.輸入內(nèi)容長(zhǎng)度控制
對(duì)于不受信任的輸入，都應(yīng)該限定一個(gè)合理的長(zhǎng)度。雖然無(wú)法完全防止 XSS 發(fā)生，但可以增加 XSS 攻擊的難度。
3.輸入內(nèi)容限制
對(duì)于部分輸入，可以限定不能包含特殊字符或者僅能輸入數(shù)字等。
4.其他安全措施
HTTP-only Cookie: 禁止 JavaScript 讀取某些敏感 Cookie，攻擊者完成 XSS 注入后也無(wú)法竊取此 Cookie。
驗(yàn)證碼：防止腳本冒充用戶(hù)提交危險(xiǎn)操作。
XSS 檢測(cè)
讀到這兒，相信大家已經(jīng)知道了什么是XSS攻擊，XSS攻擊的類(lèi)型，以及如何去防范XSS攻擊。但是有一個(gè)非常重要的問(wèn)題是：我們?nèi)绾稳z測(cè)XSS攻擊，怎么知道自己的頁(yè)面是否存在XSS漏洞？
很多大公司，都有專(zhuān)門(mén)的安全部門(mén)負(fù)責(zé)這個(gè)工作，但是如果沒(méi)有安全部門(mén)，作為開(kāi)發(fā)者本身，該如何去檢測(cè)呢？
1.使用通用 XSS 攻擊字串手動(dòng)檢測(cè) XSS 漏洞
如: jaVasCript:/-//*\/’/"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/–!>\x3csVg/<sVg/oNloAd=alert()//>\x3e
能夠檢測(cè)到存在于 HTML 屬性、HTML 文字內(nèi)容、HTML 注釋、跳轉(zhuǎn)鏈接、內(nèi)聯(lián) JavaScript 字符串、內(nèi)聯(lián) CSS 樣式表等多種上下文中的 XSS 漏洞，也能檢測(cè) eval()、setTimeout()、setInterval()、Function()、innerHTML、document.write() 等 DOM 型 XSS 漏洞，并且能繞過(guò)一些 XSS 過(guò)濾器。
<img src=1 onerror=alert(1)>
2.使用第三方工具進(jìn)行掃描
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)的用戶(hù)驗(yàn)證，達(dá)到冒充用戶(hù)對(duì)被攻擊的網(wǎng)站執(zhí)行某項(xiàng)操作的目的。
典型的CSRF攻擊流程：
受害者登錄A站點(diǎn)，并保留了登錄憑證（Cookie）。
攻擊者誘導(dǎo)受害者訪問(wèn)了站點(diǎn)B。
站點(diǎn)B向站點(diǎn)A發(fā)送了一個(gè)請(qǐng)求，瀏覽器會(huì)默認(rèn)攜帶站點(diǎn)A的Cookie信息。
站點(diǎn)A接收到請(qǐng)求后，對(duì)請(qǐng)求進(jìn)行驗(yàn)證，并確認(rèn)是受害者的憑證，誤以為是無(wú)辜的受害者發(fā)送的請(qǐng)求。
站點(diǎn)A以受害者的名義執(zhí)行了站點(diǎn)B的請(qǐng)求。
攻擊完成，攻擊者在受害者不知情的情況下，冒充受害者完成了攻擊。
一圖勝千言：
CSRF的特點(diǎn)：
攻擊通常在第三方網(wǎng)站發(fā)起，如圖上的站點(diǎn)B，站點(diǎn)A無(wú)法防止攻擊發(fā)生。
攻擊利用受害者在被攻擊網(wǎng)站的登錄憑證，冒充受害者提交操作；并不會(huì)去獲取cookie信息(cookie有同源策略)
跨站請(qǐng)求可以用各種方式：圖片URL、超鏈接、CORS、Form提交等等(來(lái)源不明的鏈接，不要點(diǎn)擊)
運(yùn)行代碼，更直觀了解一下
用戶(hù) loki 銀行存款 10W。
用戶(hù) yvette 銀行存款 1000。
我們來(lái)看看 yvette 如何通過(guò) CSRF 攻擊，將 loki 的錢(qián)偷偷轉(zhuǎn)到自己的賬戶(hù)中，并根據(jù)提示，查看如何去防御CSRF攻擊。
**CSRF 攻擊防御**
1.添加驗(yàn)證碼(體驗(yàn)不好)
驗(yàn)證碼能夠防御CSRF攻擊，但是我們不可能每一次交互都需要驗(yàn)證碼，否則用戶(hù)的體驗(yàn)會(huì)非常差，但是我們可以在轉(zhuǎn)賬，交易等操作時(shí)，增加驗(yàn)證碼，確保我們的賬戶(hù)安全。
2.判斷請(qǐng)求的來(lái)源：檢測(cè)Referer(并不安全，Referer可以被更改)
Referer 可以作為一種輔助手段，來(lái)判斷請(qǐng)求的來(lái)源是否是安全的，但是鑒于 Referer 本身是可以被修改的，因?yàn)椴荒軆H依賴(lài)于 Referer
3.使用Token(主流)
CSRF攻擊之所以能夠成功，是因?yàn)榉?wù)器誤把攻擊者發(fā)送的請(qǐng)求當(dāng)成了用戶(hù)自己的請(qǐng)求。那么我們可以要求所有的用戶(hù)請(qǐng)求都攜帶一個(gè)CSRF攻擊者無(wú)法獲取到的Token。服務(wù)器通過(guò)校驗(yàn)請(qǐng)求是否攜帶正確的Token，來(lái)把正常的請(qǐng)求和攻擊的請(qǐng)求區(qū)分開(kāi)。跟驗(yàn)證碼類(lèi)似，只是用戶(hù)無(wú)感知。
服務(wù)端給用戶(hù)生成一個(gè)token，加密后傳遞給用戶(hù)
用戶(hù)在提交請(qǐng)求時(shí)，需要攜帶這個(gè)token
服務(wù)端驗(yàn)證token是否正確
4.Samesite Cookie屬性
為了從源頭上解決這個(gè)問(wèn)題，Google起草了一份草案來(lái)改進(jìn)HTTP協(xié)議，為Set-Cookie響應(yīng)頭新增Samesite屬性，它用來(lái)標(biāo)明這個(gè) Cookie是個(gè)“同站 Cookie”，同站Cookie只能作為第一方Cookie，不能作為第三方Cookie，Samesite 有兩個(gè)屬性值，分別是 Strict 和 Lax。
部署簡(jiǎn)單，并能有效防御CSRF攻擊，但是存在兼容性問(wèn)題。
Samesite=Strict
Samesite=Strict 被稱(chēng)為是嚴(yán)格模式,表明這個(gè) Cookie 在任何情況都不可能作為第三方的 Cookie，有能力阻止所有CSRF攻擊。此時(shí)，我們?cè)贐站點(diǎn)下發(fā)起對(duì)A站點(diǎn)的任何請(qǐng)求，A站點(diǎn)的 Cookie 都不會(huì)包含在cookie請(qǐng)求頭中。
Samesite=Lax
Samesite=Lax 被稱(chēng)為是寬松模式，與 Strict 相比，放寬了限制，允許發(fā)送安全 HTTP 方法帶上 Cookie，如 Get / OPTIONS 、HEAD 請(qǐng)求.
但是不安全 HTTP 方法，如： POST, PUT, DELETE 請(qǐng)求時(shí)，不能作為第三方鏈接的 Cookie
為了更好的防御CSRF攻擊，我們可以組合使用以上防御手段。
點(diǎn)擊劫持
點(diǎn)擊劫持是指在一個(gè)Web頁(yè)面中隱藏了一個(gè)透明的iframe，用外層假頁(yè)面誘導(dǎo)用戶(hù)點(diǎn)擊，實(shí)際上是在隱藏的frame上觸發(fā)了點(diǎn)擊事件進(jìn)行一些用戶(hù)不知情的操作。
典型點(diǎn)擊劫持攻擊流程
攻擊者構(gòu)建了一個(gè)非常有吸引力的網(wǎng)頁(yè)【不知道哪些內(nèi)容對(duì)你們來(lái)說(shuō)有吸引力，我就不寫(xiě)頁(yè)面了，偷個(gè)懶】
將被攻擊的頁(yè)面放置在當(dāng)前頁(yè)面的 iframe 中
使用樣式將 iframe 疊加到非常有吸引力內(nèi)容的上方
將iframe設(shè)置為100%透明
你被誘導(dǎo)點(diǎn)擊了網(wǎng)頁(yè)內(nèi)容，你以為你點(diǎn)擊的是*，而實(shí)際上，你成功被攻擊了。
點(diǎn)擊劫持防御
frame busting
Frame busting
if ( top.location != window.location ){
? ? top.location = window.location
? ? }
需要注意的是: HTML5中iframe的 sandbox 屬性、IE中iframe的security 屬性等，都可以限制iframe頁(yè)面中的JavaScript腳本執(zhí)行，從而可以使得 frame busting 失效。
X-Frame-Options
X-FRAME-OPTIONS是微軟提出的一個(gè)http頭，專(zhuān)門(mén)用來(lái)防御利用iframe嵌套的點(diǎn)擊劫持攻擊。并且在IE8、Firefox3.6、Chrome4以上的版本均能很好的支持。
可以設(shè)置為以下值:
DENY: 拒絕任何域加載
SAMEORIGIN: 允許同源域下加載
ALLOW-FROM: 可以定義允許frame加載的頁(yè)面地址
URL跳轉(zhuǎn)漏洞
URL 跳轉(zhuǎn)漏洞是指后臺(tái)服務(wù)器在告知瀏覽器跳轉(zhuǎn)時(shí)，未對(duì)客戶(hù)端傳入的重定向地址進(jìn)行合法性校驗(yàn)，導(dǎo)致用戶(hù)瀏覽器跳轉(zhuǎn)到釣魚(yú)頁(yè)面的一種漏洞。
URL跳轉(zhuǎn)一般有以下幾種實(shí)現(xiàn)方式
·Header頭跳轉(zhuǎn)
·Javascript跳轉(zhuǎn)
·META標(biāo)簽跳轉(zhuǎn)
URL跳轉(zhuǎn)漏洞防御
之所以會(huì)出現(xiàn)跳轉(zhuǎn) URL 漏洞，就是因?yàn)榉?wù)端沒(méi)有對(duì)客戶(hù)端傳遞的跳轉(zhuǎn)地址進(jìn)行合法性校驗(yàn)，所以，預(yù)防這種攻擊的方式，就是對(duì)客戶(hù)端傳遞過(guò)來(lái)的跳轉(zhuǎn) URL 進(jìn)行校驗(yàn)。
1.referer的限制
如果確定傳遞URL參數(shù)進(jìn)入的來(lái)源，我們可以通過(guò)該方式實(shí)現(xiàn)安全限制，保證該URL的有效性，避免惡意用戶(hù)自己生成跳轉(zhuǎn)鏈接
2.加入有效性驗(yàn)證Token
保證所有生成的鏈接都是來(lái)自于可信域，通過(guò)在生成的鏈接里加入用戶(hù)不可控的token對(duì)生成的鏈接進(jìn)行校驗(yàn)，可以避免用戶(hù)生成自己的惡意鏈接從而被利用。
安全掃描工具
上面我們介紹了幾種常見(jiàn)的前端安全漏洞，也了解一些防范措施，那么我們?nèi)绾伟l(fā)現(xiàn)自己網(wǎng)站的安全問(wèn)題呢？沒(méi)有安全部門(mén)的公司可以考慮下面幾款開(kāi)源掃碼工具：
Arachni
Arachni是基于Ruby的開(kāi)源，功能全面，高性能的漏洞掃描框架，Arachni提供簡(jiǎn)單快捷的掃描方式，只需要輸入目標(biāo)網(wǎng)站的網(wǎng)址即可開(kāi)始掃描。它可以通過(guò)分析在掃描過(guò)程中獲得的信息，來(lái)評(píng)估漏洞識(shí)別的準(zhǔn)確性和避免誤判。
Arachni默認(rèn)集成大量的檢測(cè)工具，可以實(shí)施 代碼注入、CSRF、文件包含檢測(cè)、SQL注入、命令行注入、路徑遍歷等各種攻擊。
同時(shí)，它還提供了各種插件，可以實(shí)現(xiàn)表單爆破、HTTP爆破、防火墻探測(cè)等功能。
針對(duì)大型網(wǎng)站，該工具支持會(huì)話保持、瀏覽器集群、快照等功能，幫助用戶(hù)更好實(shí)施滲透測(cè)試。
Mozilla HTTP Observatory
Mozilla HTTP Observatory，是Mozilla最近發(fā)布的一款名為Observatory的網(wǎng)站安全分析工具，意在鼓勵(lì)開(kāi)發(fā)者和系統(tǒng)管理員增強(qiáng)自己網(wǎng)站的安全配置。用法非常簡(jiǎn)單：輸入網(wǎng)站URL，即可訪問(wèn)并分析網(wǎng)站HTTP標(biāo)頭，隨后可針對(duì)網(wǎng)站安全性提供數(shù)字形式的分?jǐn)?shù)和字母代表的安全級(jí)別。
檢查的主要范圍包括：
Cookie
跨源資源共享（CORS）
內(nèi)容安全策略（CSP）
HTTP公鑰固定（Public Key Pinning）
HTTP嚴(yán)格安全傳輸（HSTS）狀態(tài)
是否存在HTTP到HTTPs的自動(dòng)重定向
子資源完整性（Subresource Integrity）
X-Frame-Options
X-XSS-Protection
w3af
W3af是一個(gè)基于Python的Web應(yīng)用安全掃描器?？蓭椭_(kāi)發(fā)人員，有助于開(kāi)發(fā)人員和測(cè)試人員識(shí)別Web應(yīng)用程序中的漏洞。
掃描器能夠識(shí)別200多個(gè)漏洞，包括跨站點(diǎn)腳本、SQL注入和操作系統(tǒng)命令。
————————————————
版權(quán)聲明：本文為CSDN博主「HBohan」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/HBohan/article/details/118310688
