1）XSS：跨站腳本攻擊

就是攻擊者想盡一切辦法將可以執(zhí)行的代碼注入到網(wǎng)頁中朋凉。

存儲型（server端）：

場景：見于帶有用戶保存數(shù)據(jù)的網(wǎng)站功能，如論壇發(fā)帖醋安、商品評論杂彭、用戶私信等。

攻擊步驟：

????i）攻擊者將惡意代碼提交到目標(biāo)網(wǎng)站的數(shù)據(jù)庫中

????ii）用戶打開目標(biāo)網(wǎng)站時吓揪，服務(wù)端將惡意代碼從數(shù)據(jù)庫中取出來盖灸，拼接在HTML中返回給瀏覽器

????iii）用戶瀏覽器在收到響應(yīng)后解析執(zhí)行，混在其中的惡意代碼也同時被執(zhí)行

????iv）惡意代碼竊取用戶數(shù)據(jù)磺芭，并發(fā)送到指定攻擊者的網(wǎng)站赁炎，或者冒充用戶行為，調(diào)用目標(biāo)網(wǎng)站的接口钾腺，執(zhí)行惡意操作

反射型（Server端）

與存儲型的區(qū)別在于徙垫，存儲型的惡意代碼存儲在數(shù)據(jù)庫中，反射型的惡意代碼在URL上

場景：通過 URL 傳遞參數(shù)的功能放棒，如網(wǎng)站搜索姻报、跳轉(zhuǎn)等。

攻擊步驟：

????i）攻擊者構(gòu)造出特殊的 URL间螟，其中包含惡意代碼吴旋。

????ii）用戶打開帶有惡意代碼的 URL 時，網(wǎng)站服務(wù)端將惡意代碼從 URL 中取出厢破，拼接在 HTML 中返回給瀏覽器荣瑟。

????iii）用戶瀏覽器接收到響應(yīng)后解析執(zhí)行，混在其中的惡意代碼也被執(zhí)行摩泪。

????iv）惡意代碼竊取用戶數(shù)據(jù)并發(fā)送到攻擊者的網(wǎng)站笆焰，或者冒充用戶的行為，調(diào)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作见坑。

Dom 型(瀏覽器端）

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

場景：通過 URL 傳遞參數(shù)的功能，如網(wǎng)站搜索熊楼、跳轉(zhuǎn)等霹娄。

攻擊步驟：

????i）攻擊者構(gòu)造出特殊的 URL，其中包含惡意代碼。

????ii）用戶打開帶有惡意代碼的 URL项棠。

????iii）用戶瀏覽器接收到響應(yīng)后解析執(zhí)行，前端 JavaScript 取出 URL 中的惡意代碼并執(zhí)行挎峦。

????iv）惡意代碼竊取用戶數(shù)據(jù)并發(fā)送到攻擊者的網(wǎng)站香追，或者冒充用戶的行為，調(diào)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作坦胶。

預(yù)防方案：（防止攻擊者提交惡意代碼透典，防止瀏覽器執(zhí)行惡意代碼）

????i）對數(shù)據(jù)進(jìn)行嚴(yán)格的輸出編碼：如HTML元素的編碼，JS編碼顿苇，CSS編碼峭咒，URL編碼等等

避免拼接 HTML；Vue/React 技術(shù)棧纪岁，避免使用 v-html / dangerouslySetInnerHTML

????ii）CSP HTTP Header凑队，即 Content-Security-Policy、X-XSS-Protection

增加攻擊難度幔翰，配置CSP(本質(zhì)是建立白名單漩氨，由瀏覽器進(jìn)行攔截)

Content-Security-Policy: default-src 'self'?-所有內(nèi)容均來自站點的同一個源（不包括其子域名）

Content-Security-Policy: default-src 'self' *.trusted.com-允許內(nèi)容來自信任的域名及其子域名 (域名不必須與CSP設(shè)置所在的域名相同)

Content-Security-Policy: default-src https://yideng.com-該服務(wù)器僅允許通過HTTPS方式并僅從yideng.com域名來訪問文檔

????iii）輸入驗證：比如一些常見的數(shù)字、URL遗增、電話號碼叫惊、郵箱地址等等做校驗判斷

????iv）開啟瀏覽器XSS防御：Http Only cookie，禁止 JavaScript 讀取某些敏感 Cookie做修，攻擊者完成 XSS 注入后也無法竊取此 Cookie霍狰。

????v）驗證碼

2）CSRF：跨站請求偽造

攻擊者誘導(dǎo)受害者進(jìn)入第三方網(wǎng)站，在第三方網(wǎng)站中饰及，向被攻擊網(wǎng)站發(fā)送跨站請求蔗坯。利用受害者在被攻擊網(wǎng)站已經(jīng)獲取的注冊憑證，繞過后臺的用戶驗證燎含，達(dá)到冒充用戶對被攻擊的網(wǎng)站執(zhí)行某項操作的目的步悠。

攻擊流程舉例

????i）受害者登錄 a.com，并保留了登錄憑證（Cookie）

????ii）攻擊者引誘受害者訪問了b.com

????iii）b.com 向 a.com 發(fā)送了一個請求：a.com/act=xx瀏覽器會默認(rèn)攜帶a.com的Cookie

????iv）a.com接收到請求后瘫镇，對請求進(jìn)行驗證鼎兽，并確認(rèn)是受害者的憑證，誤以為是受害者自己發(fā)送的請求

????v）a.com以受害者的名義執(zhí)行了act=xx

????vi）攻擊完成铣除，攻擊者在受害者不知情的情況下谚咬，冒充受害者，讓a.com執(zhí)行了自己定義的操作

攻擊類型

????i）GET型：如在頁面的某個 img 中發(fā)起一個 get 請求

????ii）POST型：通過自動提交表單到惡意網(wǎng)站

????iii）鏈接型：需要誘導(dǎo)用戶點擊鏈接

預(yù)防方案：

CSRF通常從第三方網(wǎng)站發(fā)起尚粘，被攻擊的網(wǎng)站無法防止攻擊發(fā)生择卦，只能通過增強(qiáng)自己網(wǎng)站針對CSRF的防護(hù)能力來提升安全性。）

????i）同源檢測：通過Header中的Origin Header 、Referer Header 確定秉继，但不同瀏覽器可能會有不一樣的實現(xiàn)祈噪，不能完全保證

????ii）CSRF Token 校驗：將CSRF Token輸出到頁面中（通常保存在Session中），頁面提交的請求攜帶這個Token尚辑，服務(wù)器驗證Token是否

正確

????iii）雙重cookie驗證：

流程：

????步驟1：在用戶訪問網(wǎng)站頁面時辑鲤，向請求域名注入一個Cookie，內(nèi)容為隨機(jī)字符串（例如csrfcookie=v8g9e4ksfhw）

步驟2：在前端向后端發(fā)起請求時杠茬，取出Cookie月褥，并添加到URL的參數(shù)中（接上例POSThttps://www.a.com/comment?csrfcookie=v8g9e4ksfhw）

????步驟3：后端接口驗證Cookie中的字段與URL參數(shù)中的字段是否一致，不一致則拒絕瓢喉。

優(yōu)點：

? ? - 無需使用Session宁赤，適用面更廣，易于實施栓票。

? ? - Token儲存于客戶端中决左，不會給服務(wù)器帶來壓力。

? ? - 相對于Token走贪，實施成本更低哆窿，可以在前后端統(tǒng)一攔截校驗，而不需要一個個接口和頁面添加厉斟。

缺點：

? ? - Cookie中增加了額外的字段挚躯。

????- 如果有其他漏洞（例如XSS），攻擊者可以注入Cookie擦秽，那么該防御方式失效码荔。

????- 難以做到子域名的隔離。

????- 為了確保Cookie傳輸安全感挥，采用這種防御方式的最好確保用整站HTTPS的方式缩搅，如果還沒切HTTPS的使用這種方式也會有風(fēng)險。

????iv）Samesite Cookie屬性：Google起草了一份草案來改進(jìn)HTTP協(xié)議触幼，那就是為Set-Cookie響應(yīng)頭新增Samesite屬性硼瓣，它用來標(biāo)明這個 Cookie是個“同站 Cookie”，同站Cookie只能作為第一方Cookie置谦，不能作為第三方Cookie堂鲤，Samesite 有兩個屬性值，Strict 為任何情況下都不可以作為第三方 Cookie 媒峡，Lax 為可以作為第三方 Cookie , 但必須是Get請求

3）iframe 安全

說明：

????i）嵌入第三方 iframe 會有很多不可控的問題瘟栖，同時當(dāng)?shù)谌?iframe 出現(xiàn)問題或是被劫持之后，也會誘發(fā)安全性問題

????ii）點擊劫持

攻擊者將目標(biāo)網(wǎng)站通過 iframe 嵌套的方式嵌入自己的網(wǎng)頁中谅阿，并將 iframe 設(shè)置為透明半哟，誘導(dǎo)用戶點擊酬滤。

????iii）禁止自己的 iframe 中的鏈接外部網(wǎng)站的JS

預(yù)防方案：

????i）為 iframe 設(shè)置 sandbox 屬性，通過它可以對iframe的行為進(jìn)行各種限制寓涨，充分實現(xiàn)“最小權(quán)限“原則

????ii）服務(wù)端設(shè)置 X-Frame-Options Header頭驾茴，拒絕頁面被嵌套捐顷，X-Frame-Options 是HTTP 響應(yīng)頭中用來告訴瀏覽器一個頁面是否可以嵌入?

eg.X-Frame-Options: SAMEORIGIN

SAMEORIGIN: iframe 頁面的地址只能為同源域名下的頁面

ALLOW-FROM: 可以嵌套在指定來源的 iframe 里

DENY: 當(dāng)前頁面不能被嵌套在 iframe 里

????iii）設(shè)置 CSP 即 Content-Security-Policy 請求頭

????iv）減少對 iframe 的使用

4）錯誤的內(nèi)容推斷

說明：

文件上傳類型校驗失敗后玄柏，導(dǎo)致惡意的JS文件上傳后鼻种，瀏覽器 Content-Type Header 的默認(rèn)解析為可執(zhí)行的 JS 文件

預(yù)防方案：

設(shè)置 X-Content-Type-Options 頭

5）第三方依賴包

減少對第三方依賴包的使用稍途，如之前 npm 的包如：event-stream 被爆出惡意攻擊數(shù)字貨幣索绪；

6）HTTPS

描述：

黑客可以利用SSL Stripping這種攻擊手段斤贰，強(qiáng)制讓HTTPS降級回HTTP佑淀，從而繼續(xù)進(jìn)行中間人攻擊耗拓。

預(yù)防方案：

使用HSTS（HTTP Strict Transport Security）拇颅，它通過下面這個HTTP Header以及一個預(yù)加載的清單，來告知瀏覽器和網(wǎng)站進(jìn)行通信的時候強(qiáng)制性的使用HTTPS乔询，而不是通過明文的HTTP進(jìn)行通信樟插。這里的“強(qiáng)制性”表現(xiàn)為瀏覽器無論在何種情況下都直接向務(wù)器端發(fā)起HTTPS請求，而不再像以往那樣從HTTP跳轉(zhuǎn)到HTTPS竿刁。另外黄锤，當(dāng)遇到證書或者鏈接不安全的時候，則首先警告用戶食拜，并且不再

用戶選擇是否繼續(xù)進(jìn)行不安全的通信鸵熟。

7）本地存儲數(shù)據(jù)

避免重要的用戶信息存在瀏覽器緩存中

8）靜態(tài)資源完整性校驗

描述

使用 內(nèi)容分發(fā)網(wǎng)絡(luò) (CDNs) 在多個站點之間共享腳本和樣式表等文件可以提高站點性能并節(jié)省帶寬。然而负甸，使用CDN也存在風(fēng)險流强，如果攻擊者獲得對 CDN 的控制權(quán)，則可以將任意惡意內(nèi)容注入到 CDN 上的文件中 （或完全替換掉文件）呻待，因此可能潛在地攻擊所有從該 CDN 獲取文件的站點打月。

預(yù)防方案

將使用 base64 編碼過后的文件哈希值寫入你所引用的 <script> 或 標(biāo)簽的 integrity 屬性值中即可啟用子資源完整性能。

9）網(wǎng)絡(luò)劫持

描述：

DNS劫持（涉嫌違法）：修改運行商的 DNS 記錄蚕捉，重定向到其他網(wǎng)站奏篙。DNS 劫持是違法的行為，目前 DNS 劫持已被監(jiān)管迫淹，現(xiàn)在很少見 DNS 劫持

HTTP劫持：前提有 HTTP 請求秘通。因 HTTP 是明文傳輸，運營商便可借機(jī)修改 HTTP 響應(yīng)內(nèi)容（如加廣告）敛熬。

預(yù)防方案

全站 HTTPS

10）中間人攻擊：

中間人攻擊（Man-in-the-middle attack, MITM）充易，指攻擊者與通訊的兩端分別創(chuàng)建獨立的聯(lián)系，并交換其所收到的數(shù)據(jù)荸型，使通訊的兩端認(rèn)為他們正在通過一個私密的連接與對方直接對話盹靴，但事實上整個會話都被攻擊者竊聽炸茧、篡改甚至完全控制。沒有進(jìn)行嚴(yán)格的證書校驗是中間人攻擊著手點稿静。目前大多數(shù)加密協(xié)議都提供了一些特殊認(rèn)證方法以阻止中間人攻擊梭冠。如 SSL （安全套接字層）協(xié)議可以驗證參與通訊的用戶的證書是否有權(quán)威、受信任的數(shù)字證書認(rèn)證機(jī)構(gòu)頒發(fā)改备，并且能執(zhí)行雙向身份認(rèn)證控漠。攻擊場景如用戶在一個未加密的 WiFi下訪問網(wǎng)站。在中間人攻擊中悬钳，攻擊者可以攔截通訊雙方的通話并插入新的內(nèi)容盐捷。

場景

????i）在一個未加密的Wi-Fi 無線接入點的接受范圍內(nèi)的中間人攻擊者，可以將自己作為一個中間人插入這個網(wǎng)絡(luò)

????ii）Fiddler / Charles （花瓶）代理工具

????iii）12306 之前的自己證書

過程

????i）客戶端發(fā)送請求到服務(wù)端默勾，請求被中間人截獲

????ii）服務(wù)器向客戶端發(fā)送公鑰

????iii）中間人截獲公鑰碉渡，保留在自己手上。然后自己生成一個【偽造的】公鑰母剥，發(fā)給客戶端

????iv）客戶端收到偽造的公鑰后滞诺，生成加密hash值發(fā)給服務(wù)器

????v）中間人獲得加密hash值，用自己的私鑰解密獲得真秘鑰,同時生成假的加密hash值环疼，發(fā)給服務(wù)器

????vi）服務(wù)器用私鑰解密獲得假密鑰,然后加密數(shù)據(jù)傳輸給客戶端

使用抓包工具fiddle來進(jìn)行舉例說明

首先通過一些途徑在客戶端安裝證書

然后客戶端發(fā)送連接請求习霹，fiddle在中間截取請求，并返回自己偽造的證書

客戶端已經(jīng)安裝了攻擊者的根證書炫隶，所以驗證通過

客戶端就會正常和fiddle進(jìn)行通信淋叶，把fiddle當(dāng)作正確的服務(wù)器

同時fiddle會跟原有的服務(wù)器進(jìn)行通信，獲取數(shù)據(jù)以及加密的密鑰伪阶，去解密密鑰

常見攻擊方式

嗅探：嗅探是一種用來捕獲流進(jìn)和流出的網(wǎng)絡(luò)數(shù)據(jù)包的技術(shù)爸吮，就好像是監(jiān)聽電話一樣。比如：抓包工具

數(shù)據(jù)包注入：在這種望门，攻擊者會將惡意數(shù)據(jù)包注入到常規(guī)數(shù)據(jù)中的形娇，因為這些惡意數(shù)據(jù)包是在正常的數(shù)據(jù)包里面的，用戶和系統(tǒng)都很難發(fā)現(xiàn)這個內(nèi)容筹误。

會話劫持：當(dāng)我們進(jìn)行一個網(wǎng)站的登錄的時候到退出登錄這個時候桐早，會產(chǎn)生一個會話，這個會話是攻擊者用來攻擊的首要目標(biāo)厨剪，因為這個會話哄酝，包含了用戶大量的數(shù)據(jù)和私密信息。

SSL剝離：HTTPS是通過SSL/TLS進(jìn)行加密過的祷膳，在SSL剝離攻擊中陶衅，會使SSL/TLS連接斷開，讓受保護(hù)的HTTPS直晨，變成不受

保護(hù)的HTTP（這對于網(wǎng)站非常致命）

DNS欺騙搀军，攻擊者往往通過入侵到DNS服務(wù)器膨俐，或者篡改用戶本地hosts文件，然后去劫持用戶發(fā)送的請求罩句，然后轉(zhuǎn)發(fā)到攻擊者想要轉(zhuǎn)發(fā)到的服務(wù)器

ARP欺騙焚刺，ARP(address resolution protocol)地址解析協(xié)議，攻擊者利用APR的漏洞门烂，用當(dāng)前局域網(wǎng)之間的一臺服務(wù)器乳愉，來冒充客戶端想要請求的服務(wù)端，向客戶端發(fā)送自己的MAC地址屯远，客戶端無從得到真正的主機(jī)的MAC地址蔓姚，所以，他會把這個地址當(dāng)作真正

的主機(jī)來進(jìn)行通信慨丐，將MAC存入ARP緩存表坡脐。

代理服務(wù)器

預(yù)防方案：

????i）用可信的第三方CA廠商

????ii）不下載未知來源的證書，不要去下載一些不安全的文件

????iii）確認(rèn)你訪問的URL是HTTPS的咖气，確保網(wǎng)站使用了SSL挨措，確保禁用一些不安全的SSL挖滤，只開啟：TLS1.1崩溪，TLS1.2

????iv）不要使用公用網(wǎng)絡(luò)發(fā)送一些敏感的信息

????v）不要去點擊一些不安全的連接或者惡意鏈接或郵件信息

11）sql 注入

描述

就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串，最終達(dá)到欺騙數(shù)據(jù)庫服務(wù)器執(zhí)行惡意的SQL命令,從而達(dá)到和服務(wù)器

進(jìn)行直接的交互

預(yù)防方案：

????i）后臺進(jìn)行輸入驗證斩松，對敏感字符過濾伶唯。

????ii）使用參數(shù)化查詢，能避免拼接SQL惧盹，就不要拼接SQL語句乳幸。

12）前端數(shù)據(jù)安全：

描述

反爬蟲。如貓眼電影钧椰、天眼查等等粹断，以數(shù)據(jù)內(nèi)容為核心資產(chǎn)的企業(yè)

預(yù)防方案：

????i）font-face拼接方式：貓眼電影、天眼查

????ii）background 拼接：美團(tuán)

????iii）偽元素隱藏：汽車之家

????iv）元素定位覆蓋式：去哪兒

????v）iframe 異步加載：網(wǎng)易云音樂

13）其他建議

????i）定期請第三方機(jī)構(gòu)做安全性測試嫡霞，漏洞掃描

????ii）使用第三方開源庫做上線前的安全測試瓶埋，可以考慮融合到CI中

????iii）code review 保證代碼質(zhì)量

????iv）默認(rèn)項目中設(shè)置對應(yīng)的 Header 請求頭，如 X-XSS-Protection诊沪、 X-Content-Type-Options 养筒、X-Frame-Options Header、Content-Security-Policy 等等

????v）對第三方包和庫做檢測：NSP(Node Security Platform)端姚，Snyk

第 10 題：前端安全晕粪、中間人攻擊 · Issue #16 · lgwebdream/FE-Interview · GitHub