前端安全 中間人攻擊

1）XSS：跨站腳本攻擊

就是攻擊者想盡一切辦法將可以執行的代碼注入到網頁中。

存儲型（server端）：

• 場景：見於帶有用戶保存數據的網站功能，如論壇發帖、商品評論、用戶私信等。
• 攻擊步驟：
  • i）攻擊者將惡意代碼提交到目標網站的數據庫中
  • ii）用戶打開目標網站時，服務端將惡意代碼從數據庫中取出來，拼接在HTML中返回給瀏覽器
  • iii）用戶瀏覽器在收到響應后解析執行，混在其中的惡意代碼也同時被執行
  • iv）惡意代碼竊取用戶數據，並發送到指定攻擊者的網站，或者冒充用戶行為，調用目標網站的接口，執行惡意操作

反射型（Server端）

與存儲型的區別在於，存儲型的惡意代碼存儲在數據庫中，反射型的惡意代碼在URL上

• 場景：通過 URL 傳遞參數的功能，如網站搜索、跳轉等。
• 攻擊步驟：
  • i）攻擊者構造出特殊的 URL，其中包含惡意代碼。
  • ii）用戶打開帶有惡意代碼的 URL 時，網站服務端將惡意代碼從 URL 中取出，拼接在 HTML 中返回給瀏覽器。
  • iii）用戶瀏覽器接收到響應后解析執行，混在其中的惡意代碼也被執行。
  • iv）惡意代碼竊取用戶數據並發送到攻擊者的網站，或者冒充用戶的行為，調用目標網站接口執行攻擊者指定的操作。

Dom 型(瀏覽器端）

DOM 型 XSS 攻擊中，取出和執行惡意代碼由瀏覽器端完成，屬於前端 JavaScript 自身的安全漏洞，而其他兩種 XSS 都屬於服務端的安全漏洞。

• 場景：通過 URL 傳遞參數的功能，如網站搜索、跳轉等。
• 攻擊步驟：
  • i）攻擊者構造出特殊的 URL，其中包含惡意代碼。
  • ii）用戶打開帶有惡意代碼的 URL。
  • iii）用戶瀏覽器接收到響應后解析執行，前端 JavaScript 取出 URL 中的惡意代碼並執行。
  • iv）惡意代碼竊取用戶數據並發送到攻擊者的網站，或者冒充用戶的行為，調用目標網站接口執行攻擊者指定的操作。

預防方案：（防止攻擊者提交惡意代碼，防止瀏覽器執行惡意代碼）

• i）對數據進行嚴格的輸出編碼：如HTML元素的編碼，JS編碼，CSS編碼，URL編碼等等
  • 避免拼接 HTML；Vue/React 技術棧，避免使用 v-html / dangerouslySetInnerHTML
• ii）CSP HTTP Header，即 Content-Security-Policy、X-XSS-Protection
  • 增加攻擊難度，配置CSP(本質是建立白名單，由瀏覽器進行攔截)
  • Content-Security-Policy: default-src 'self' -所有內容均來自站點的同一個源（不包括其子域名）
  • Content-Security-Policy: default-src 'self' *.trusted.com-允許內容來自信任的域名及其子域名 (域名不必須與CSP設置所在的域名相同)
  • Content-Security-Policy: default-src https://yideng.com-該服務器僅允許通過HTTPS方式並僅從yideng.com域名來訪問文檔
• iii）輸入驗證：比如一些常見的數字、URL、電話號碼、郵箱地址等等做校驗判斷
• iv）開啟瀏覽器XSS防御：Http Only cookie，禁止 JavaScript 讀取某些敏感 Cookie，攻擊者完成 XSS 注入后也無法竊取此 Cookie。
• v）驗證碼

2）CSRF：跨站請求偽造

攻擊者誘導受害者進入第三方網站，在第三方網站中，向被攻擊網站發送跨站請求。利用受害者在被攻擊網站已經獲取的注冊憑證，繞過后台的用戶驗證，達到冒充用戶對被攻擊的網站執行某項操作的目的。

攻擊流程舉例

• i）受害者登錄 a.com，並保留了登錄憑證（Cookie）
• ii）攻擊者引誘受害者訪問了b.com
• iii）b.com 向 a.com 發送了一個請求：a.com/act=xx瀏覽器會默認攜帶a.com的Cookie
• iv）a.com接收到請求后，對請求進行驗證，並確認是受害者的憑證，誤以為是受害者自己發送的請求
• v）a.com以受害者的名義執行了act=xx
• vi）攻擊完成，攻擊者在受害者不知情的情況下，冒充受害者，讓a.com執行了自己定義的操作

攻擊類型

• i）GET型：如在頁面的某個 img 中發起一個 get 請求
• ii）POST型：通過自動提交表單到惡意網站
• iii）鏈接型：需要誘導用戶點擊鏈接

預防方案：

CSRF通常從第三方網站發起，被攻擊的網站無法防止攻擊發生，只能通過增強自己網站針對CSRF的防護能力來提升安全性。）

• i）同源檢測：通過Header中的Origin Header 、Referer Header 確定，但不同瀏覽器可能會有不一樣的實現，不能完全保證
• ii）CSRF Token 校驗：將CSRF Token輸出到頁面中（通常保存在Session中），頁面提交的請求攜帶這個Token，服務器驗證Token是否
  正確
• iii）雙重cookie驗證：
  • 流程：
    • 步驟1：在用戶訪問網站頁面時，向請求域名注入一個Cookie，內容為隨機字符串（例如csrfcookie=v8g9e4ksfhw）
    • 步驟2：在前端向后端發起請求時，取出Cookie，並添加到URL的參數中（接上例POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw）
    • 步驟3：后端接口驗證Cookie中的字段與URL參數中的字段是否一致，不一致則拒絕。
  • 優點：
    • 無需使用Session，適用面更廣，易於實施。
    • Token儲存於客戶端中，不會給服務器帶來壓力。
    • 相對於Token，實施成本更低，可以在前后端統一攔截校驗，而不需要一個個接口和頁面添加。
  • 缺點：
    -Cookie中增加了額外的字段。
    -如果有其他漏洞（例如XSS），攻擊者可以注入Cookie，那么該防御方式失效。
    -難以做到子域名的隔離。
    -為了確保Cookie傳輸安全，采用這種防御方式的最好確保用整站HTTPS的方式，如果還沒切HTTPS的使用這種方式也會有風險。
• iv）Samesite Cookie屬性：Google起草了一份草案來改進HTTP協議，那就是為Set-Cookie響應頭新增Samesite屬性，它用來標明這個 Cookie是個“同站 Cookie”，同站Cookie只能作為第一方Cookie，不能作為第三方Cookie，Samesite 有兩個屬性值，Strict 為任何情況下都不可以作為第三方 Cookie ，Lax 為可以作為第三方 Cookie , 但必須是Get請求

3）iframe 安全

說明：

• i）嵌入第三方 iframe 會有很多不可控的問題，同時當第三方 iframe 出現問題或是被劫持之后，也會誘發安全性問題
• ii）點擊劫持
  • 攻擊者將目標網站通過 iframe 嵌套的方式嵌入自己的網頁中，並將 iframe 設置為透明，誘導用戶點擊。
• iii）禁止自己的 iframe 中的鏈接外部網站的JS

預防方案：

• i）為 iframe 設置 sandbox 屬性，通過它可以對iframe的行為進行各種限制，充分實現“最小權限“原則
• ii）服務端設置 X-Frame-Options Header頭，拒絕頁面被嵌套，X-Frame-Options 是HTTP 響應頭中用來告訴瀏覽器一個頁面是否可以嵌入 <iframe> 中
  • eg.X-Frame-Options: SAMEORIGIN
  • SAMEORIGIN: iframe 頁面的地址只能為同源域名下的頁面
  • ALLOW-FROM: 可以嵌套在指定來源的 iframe 里
  • DENY: 當前頁面不能被嵌套在 iframe 里
• iii）設置 CSP 即 Content-Security-Policy 請求頭
• iv）減少對 iframe 的使用

4）錯誤的內容推斷

說明：

文件上傳類型校驗失敗后，導致惡意的JS文件上傳后，瀏覽器 Content-Type Header 的默認解析為可執行的 JS 文件

預防方案：

設置 X-Content-Type-Options 頭

5）第三方依賴包

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

6）HTTPS

描述：

黑客可以利用SSL Stripping這種攻擊手段，強制讓HTTPS降級回HTTP，從而繼續進行中間人攻擊。

預防方案：

使用HSTS（HTTP Strict Transport Security），它通過下面這個HTTP Header以及一個預加載的清單，來告知瀏覽器和網站進行通信的時候強制性的使用HTTPS，而不是通過明文的HTTP進行通信。這里的“強制性”表現為瀏覽器無論在何種情況下都直接向務器端發起HTTPS請求，而不再像以往那樣從HTTP跳轉到HTTPS。另外，當遇到證書或者鏈接不安全的時候，則首先警告用戶，並且不再
用戶選擇是否繼續進行不安全的通信。

7）本地存儲數據

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

8）靜態資源完整性校驗

描述

使用 內容分發網絡 (CDNs) 在多個站點之間共享腳本和樣式表等文件可以提高站點性能並節省帶寬。然而，使用CDN也存在風險，如果攻擊者獲得對 CDN 的控制權，則可以將任意惡意內容注入到 CDN 上的文件中 （或完全替換掉文件），因此可能潛在地攻擊所有從該 CDN 獲取文件的站點。

預防方案

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

9）網絡劫持

描述：

• DNS劫持（涉嫌違法）：修改運行商的 DNS 記錄，重定向到其他網站。DNS 劫持是違法的行為，目前 DNS 劫持已被監管，現在很少見 DNS 劫持
• HTTP劫持：前提有 HTTP 請求。因 HTTP 是明文傳輸，運營商便可借機修改 HTTP 響應內容（如加廣告）。

預防方案

全站 HTTPS

10）中間人攻擊：

中間人攻擊（Man-in-the-middle attack, MITM），指攻擊者與通訊的兩端分別創建獨立的聯系，並交換其所收到的數據，使通訊的兩端認為他們正在通過一個私密的連接與對方直接對話，但事實上整個會話都被攻擊者竊聽、篡改甚至完全控制。沒有進行嚴格的證書校驗是中間人攻擊着手點。目前大多數加密協議都提供了一些特殊認證方法以阻止中間人攻擊。如 SSL （安全套接字層）協議可以驗證參與通訊的用戶的證書是否有權威、受信任的數字證書認證機構頒發，並且能執行雙向身份認證。攻擊場景如用戶在一個未加密的 WiFi下訪問網站。在中間人攻擊中，攻擊者可以攔截通訊雙方的通話並插入新的內容。

場景

• i）在一個未加密的Wi-Fi 無線接入點的接受范圍內的中間人攻擊者，可以將自己作為一個中間人插入這個網絡
• ii）Fiddler / Charles （花瓶）代理工具
• iii）12306 之前的自己證書

過程

• i）客戶端發送請求到服務端，請求被中間人截獲
• ii）服務器向客戶端發送公鑰
• iii）中間人截獲公鑰，保留在自己手上。然后自己生成一個【偽造的】公鑰，發給客戶端
• iv）客戶端收到偽造的公鑰后，生成加密hash值發給服務器
• v）中間人獲得加密hash值，用自己的私鑰解密獲得真秘鑰,同時生成假的加密hash值，發給服務器
• vi）服務器用私鑰解密獲得假密鑰,然后加密數據傳輸給客戶端

使用抓包工具fiddle來進行舉例說明

• 1. 首先通過一些途徑在客戶端安裝證書
• 2. 然后客戶端發送連接請求，fiddle在中間截取請求，並返回自己偽造的證書
• 3. 客戶端已經安裝了攻擊者的根證書，所以驗證通過
• 4. 客戶端就會正常和fiddle進行通信，把fiddle當作正確的服務器
• 5. 同時fiddle會跟原有的服務器進行通信，獲取數據以及加密的密鑰，去解密密鑰

常見攻擊方式

• 1. 嗅探：嗅探是一種用來捕獲流進和流出的網絡數據包的技術，就好像是監聽電話一樣。比如：抓包工具
• 2. 數據包注入：在這種，攻擊者會將惡意數據包注入到常規數據中的，因為這些惡意數據包是在正常的數據包里面的，用戶和系統都很難發現這個內容。
• 3. 會話劫持：當我們進行一個網站的登錄的時候到退出登錄這個時候，會產生一個會話，這個會話是攻擊者用來攻擊的首要目標，因為這個會話，包含了用戶大量的數據和私密信息。
• 4. SSL剝離：HTTPS是通過SSL/TLS進行加密過的，在SSL剝離攻擊中，會使SSL/TLS連接斷開，讓受保護的HTTPS，變成不受
     保護的HTTP（這對於網站非常致命）
• 5. DNS欺騙，攻擊者往往通過入侵到DNS服務器，或者篡改用戶本地hosts文件，然后去劫持用戶發送的請求，然后轉發到攻擊者想要轉發到的服務器
• 6. ARP欺騙，ARP(address resolution protocol)地址解析協議，攻擊者利用APR的漏洞，用當前局域網之間的一台服務器，來冒充客戶端想要請求的服務端，向客戶端發送自己的MAC地址，客戶端無從得到真正的主機的MAC地址，所以，他會把這個地址當作真正
     的主機來進行通信，將MAC存入ARP緩存表。
• 7. 代理服務器

預防方案：

• i）用可信的第三方CA廠商
• ii）不下載未知來源的證書，不要去下載一些不安全的文件
• iii）確認你訪問的URL是HTTPS的，確保網站使用了SSL，確保禁用一些不安全的SSL，只開啟：TLS1.1，TLS1.2
• iv）不要使用公用網絡發送一些敏感的信息
• v）不要去點擊一些不安全的連接或者惡意鏈接或郵件信息

11）sql 注入

描述

就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串，最終達到欺騙數據庫服務器執行惡意的SQL命令,從而達到和服務器
進行直接的交互

預防方案：

• i）后台進行輸入驗證，對敏感字符過濾。
• ii）使用參數化查詢，能避免拼接SQL，就不要拼接SQL語句。

12）前端數據安全：

描述

反爬蟲。如貓眼電影、天眼查等等，以數據內容為核心資產的企業

預防方案：

• i）font-face拼接方式：貓眼電影、天眼查
• ii）background 拼接：美團
• iii）偽元素隱藏：汽車之家
• iv）元素定位覆蓋式：去哪兒
• v）iframe 異步加載：網易雲音樂

13）其他建議

• i）定期請第三方機構做安全性測試，漏洞掃描
• ii）使用第三方開源庫做上線前的安全測試，可以考慮融合到CI中
• iii）code review 保證代碼質量
• iv）默認項目中設置對應的 Header 請求頭，如 X-XSS-Protection、 X-Content-Type-Options 、X-Frame-Options Header、Content-Security-Policy 等等
• v）對第三方包和庫做檢測：NSP(Node Security Platform)，Snyk