前端安全13條，除了XSS/CSRF你還知道哪些？

沐華發表於2023-05-15
前端

大家好，我是沐華。最近面了一些前端，發現每次問到安全相關的問題，一些面試者只能說上來 XSS、CSRF、中間人攻擊，就沒了，於是寫了這篇文章，總結了前端安全相關的點，給大家查缺補漏

瀏覽器

XSS

XSS 攻擊是一種程式碼注入攻擊，透過惡意注入指令碼在瀏覽器執行，然後盜取使用者資訊。本質上其實是因為網站沒有過濾惡意程式碼，與正常程式碼混在一起之後，瀏覽器沒有辦法分辨哪些是可信的，然後導致惡意程式碼也被執行

結果是可能會導致：頁面資料或使用者資訊被竊取、偽造登入視窗或在頁面生成浮窗廣告、監聽鍵盤事件竊取賬號密碼、流量被支援到其他網站等

XSS 攻擊有三種型別：

  1. 儲存型：透過輸入框把惡意程式碼提交到網站資料庫中，然後比如在顯示評論的頁面就會從資料獲取，並直接執行
  2. 反射型：和儲存型不同的是不會儲存在伺服器裡。比如開啟包含帶惡意指令碼的連結，當開啟後會向伺服器請求後，伺服器會獲取URL中的資料然後拼接在HTML上返回，然後執行
  3. 基於DOM型：是透過一些劫持手段，在頁面資源傳輸過程中劫持並修改頁面的資料，插入惡意程式碼

防範：比如對輸入框內容進行過濾和用轉義符進行轉碼、新增白名單、關閉 Cookie 訪問許可權、使用驗證碼防止指令碼偽裝成使用者執行操作等

CSRF

CSRF 就是跨站請求偽造攻擊，主要就是利用使用者的登入狀態發起跨站請求

比如郵箱裡的亂七八糟的連結，開啟連結的時候郵箱肯定是處於登入狀態，然後駭客就可以用這個登入狀態，偽造帶有正確 Cookie 的 http 請求，直接繞過後臺的登入驗證，然後冒充使用者執行一些操作，本質是利用 Cookie 在同源請求中攜帶傳送給伺服器的特點，來實現冒充使用者

發起 CSRF 攻擊有幾個必要條件：

  1. 目標網站一定要有 CSRF 漏洞
  2. 使用者登入過目標網站，並且瀏覽器儲存了登入狀態
  3. 需要使用者主動開啟第三方站點

CSRF 攻擊也有三種型別：

  • 自動發GET型別：比如img或iframe標籤等，當使用者開啟這個網站時會自動發起帶 Cookie 的資源請求
  • 自動發POST型別：比如整一個隱藏的表單，在使用者進入頁面的時候自動提交表單
  • 誘導連結型：就是誘導使用者主動點選連結，比如a標籤

防範：比如 Token 驗證、雙重 Cookie、透過 origin/referer 驗證請求來源等

CSP

CSP 就是白名單，作用是可以禁止載入外域的程式碼，禁止外域的提交，只允許本域下的請求表單提交之類的，簡單說就是告訴瀏覽器哪些資源可以載入執行，讓那些真的插入進入的惡意程式碼也不會被執行；或者允許向哪些第三方站點提交資料，因為攻擊者竊取資訊的根本還是向外域提交

開啟 CSP 的方式有兩種

1. meta

<meta http-equiv="content-security-policy" content="policy">
<meta http-equiv="content-security-policy-report-only" content="policy">

2. http request header

如果不支援 Content-Security-Policy，可以用 X-XSS-Proterction 代替

# 所載入的內容必須來自同源站點
Content-Security-Policy: default-src "self"
# 新增可信域名
Content-Security-Policy: *.baidu.com
# 和上面同理
Content-Security-Policy-Report-Only: policy

HSTS

HSTS 是 HTTP 嚴格傳輸安全協議，作用是強制客戶端使用 https 與伺服器建立連線，以避免因為 http 而被中間人攻擊

HSTS 設定須新增在請求頭中，如下

Strict-Transport-Security: max-age=12345;includeSubDomains;

引數：

  • max-age: 指定該設定過期的時間，單位毫秒
  • includeSubDomains: 可選引數，表示所有子域名也必須透過 https 訪問
  • preload: 可選引數，可以設定一個使用 https 的域名列表

設定 HSTS 後，再使用 http 訪問時，只要 max-age 沒有過期，客戶端內部會進行跳轉，會出現 307 Redirect Internel 狀態碼，變成 https 後，再訪問請求的資源伺服器

X-Frame-Options

X-Frame-Options 是用於控制當前頁面是否可以被嵌入到 iframe 中，以防盜鏈及點選劫持攻擊

X-Frame-Options 設定須新增在請求頭中，如下

X-Frame-Options: DENY

引數：

  • DENY: 不允許，同域名巢狀也不行
  • SAMEORIGIN: 允許同域名巢狀
  • ALLOW_FORM url: 可以指定允許巢狀訪問的來源

設定 X-Frame-Options 後，可以確保我們的網站沒有被嵌入到別人的站點裡去（以防內容被惡意巢狀，並且在表面加一個透明層，誘導使用者點選)，從而避免點選劫持攻擊及惡意盜鏈

SRI

SRI 指子資源完整性，該方案的作用是確保我們站點的資原始檔永遠不會被改變，如果被改變，瀏覽器會拒絕執行

比如我們打包的時候有一個 xxx.js 檔案，被 index.html 引用，並上傳 CDN，使用者在訪問的時候，會去請求 xxx.js，而這個檔案可能被劫持篡改，或者由於網路等原因，接收到的檔案不完整，怎麼辦？

而設定了 SRI 就可以確保當請求的檔案被篡改或不完整的時候就拒絕執行該檔案，設定如下：

<link href="https://xxx/x.css" intergrity="sha1/asdhfkjasdf">
<script src="https://xxx/x.js" intergrity="sha1/asdhfkjasdf"></script>

標籤上的 intergrity 屬性值的格式是：雜湊演算法/base64後的雜湊值

原理：

打包的時候會根據檔案內容生成 hash，並且把 hash 作為 intergrity 屬性注入到標籤上，客戶端接收到檔案後，根據檔案內容生成 hash 與 intergrity 上的進行對比是否一致，如果不一致就會認為是不安全的，拒絕執行

Referrer-Policy

Referrer-Policy 是一種 HTTP 安全方案，用於控制 referer 攜帶策略，用於監管哪些訪問來源資訊會在 referer 中傳送

注意 referer 實際上是單詞 referrer 的錯誤拼寫。而 Referrer-Policy 這個首部並沒有延續這個錯誤拼寫

開啟 Referrer-Policy 的方式有兩種

1. meta

<meta name="referrer" content="same-origin">

2. http general

Referrer-Policy: same-origin

引數：

  • no-referrer：不傳送 referer
  • no-referrer-when-downgrade：預設值，同安全級別傳送 referrer 並且是完整 url，不同安全級別則不傳送
  • origin：只傳送協議、域名、埠，不傳送完整 url，比如 https://juejin.cn/index.html，會變成https//juejin.cn/
  • origin-when-cross-origin：同源才傳送完整 url，不同源只傳送協議、域名、埠
  • same-origin：同源才傳送 referer，並且是完整的 url
  • strict-origin：同安全級別和 origin 是一樣的，比如 https 請求 https，如 https 請求 http 是不同安全級別了，就不傳送
  • strict-origin-when-cross-origin：同源傳送完整 url，同安全級別才傳送協議、域名、埠，不同源或不同安全級別不傳送 referer
  • unsafe-url：這是最不安全的策略，不管同不同源都傳送完整 url

HTTPS

由於 http 是明文傳輸，是不安全的，所以在 http 傳輸過程中資訊可能被竊取、偽造、篡改，這種攻擊方式被稱為中間人攻擊

避免中間人攻擊的方法就是用 https，在應用層與傳輸層之間新增一個安全層 TLS，但也不是就絕對安全了

安全層會透過加密演算法和公鑰私鑰加密傳遞的資料，好處是即使被劫持，中間人沒有私鑰就拿不到加密生成的隨機數，就無法生成最終金鑰

但問題是：假如一開始就被 DNS 劫持，或者說域名劫持攻擊，拿到的公鑰就是中間人的，中間人解密拿到資料後，再請求實際伺服器，拿到伺服器公鑰，再把資訊發給伺服器，這樣不知不覺間資訊還是會被竊取

所以，還需要搭配數字證照，來幫我們驗證伺服器身份。可 https 還有一個安全問題就是偽造證照的存在，比如

  • 比如 CA 機構沒有正確校驗申請者的身份而無意簽發了一些錯誤的證照
  • 比如 CA 機構在利益的驅使下，發放的證照
  • 比如冒充或偽造某個域名的擁有者，申請到一張證照，畢竟域名擁有者是無法知曉哪些 CA 機構給他簽發了證照，也不知道是否有人冒充他的身份申請了證照的
  • ...

而 CA 證照公鑰可信度是靠作業系統裡面預置的 CA 證照公鑰列表來保證的，就像白名單，使用者一般也不知道 CA 證照公鑰的真假，那如果有駭客有能力把自己的公鑰放到使用者系統的 CA 證照公鑰列表裡，那也可以偽造數字證照放到使用者的電腦上，而使用者卻無法感知就信任了這個證照，然後你懂的

為了解決證照問題，有一個解決方案，就是證照透明度(CT)，能夠審計、監控證照的簽發和使用，一旦發現偽造的證照，可以快速聯絡到 CA 機構，吊銷該證照

使用證照透明度服務就是新增請求頭 Expect-CT 用來告訴瀏覽器期望使用證照透明度服務的，這能更有效的避免中間人攻擊等

但誰也不能說這就有 100% 的絕對安全了，只是現行架構下的這些解決方案，已經大大增加了中間人的攻擊成本，一般都是可以放心的

Node(服務端)

本地檔案操作

指由於本地檔案操作相關或路徑拼接導致的檔案資源洩露，所帶來的安全問題

  • 比如提供了一個靜態服務，透過請求的引數 url 來給客戶端返回想要資源，而使用者手動修改 url 上的路徑卻可以訪問到
  • 比如暴露了一個服務或介面也可以操作檔案的話，如果對它的校驗不是那麼安全的，就會有攻擊者能訪問到我們的檔案，比如 ssh 檔案、密碼之類的

預防：express-static、koa-static、resolve-path，都可以解決這個

WebShell

WebShell 是指一種惡意指令碼，或者指令碼木馬

原理：

利用檔案上傳漏洞、SQL隱碼攻擊漏洞等等，把惡意檔案放到伺服器中，作為後門，然後透過伺服器開放的埠+後門獲取伺服器的操作許可權，比如竊取使用者資料、修改許可權、檔案管理 修改甚至刪除 web 頁面、資料庫管理等等

常見的 WebShell 編寫語言是 jsp、asp、php

攻擊方式：

  • 上傳漏洞。網站上有上傳檔案的功能，過濾又不嚴，就可以直接把 jsp、asp、php 檔案直接上傳到伺服器
  • 上傳檔案型別。專案上有新增上傳型別或重新命名檔案功能的，比如把 WebShell 檔案重新命名成.jpg之類的允許上傳的檔案，上傳完成後，再重新命名改回如 .jsp 這樣型別的檔案
  • 隱藏到合法檔案。比如把 php 程式碼放到 jpg 檔案裡，再使用@運算子防止發生錯誤，或者刪除空格換行等，導致程式碼比較混亂，再使用編碼或者加密來隱藏惡意函式等
  • 隱藏到日誌。修改傳送資料包的頭部，新增 WebShell 。 web 伺服器一般會儲存訪問記錄到Web日誌，如果找到web日誌，且放到可執行目錄下，可能獲得 shell
  • .....

ReDos

ReDos 就是正規表示式攻擊，利用正規表示式攻擊或者利用開發者正則寫的不規範，而瘋狂佔用伺服器資源，造成伺服器當機

正規表示式匹配規則是：會先匹配第一種要能性，每當一次匹配不成功，就會嘗試回溯到上一個字元，看看能不能有其他組合來匹配到這個字串，比如，匹配 aaa 會向下面這樣匹配

aaa
aa + a
a + aa
a + a + a

再看下圖三條正規表示式執行時間，第一條 0.198ms，第二條 26.445ms，第三條沒有結果，因為跑不完，會一直瘋狂佔用資源

時序攻擊

時序攻擊由於條件非常嚴荷，所以瞭解一下即可，哪怕只能說出時序攻擊這四個字，但知道有這麼回事就比不知道的強

比如攻擊者嘗試 arr = [1,2]、arr = [1,3]，發現響應時間幾乎一致，則可以認為第一個數字不是 1，再嘗試 arr = [2,1]，依此類推，不斷碰撞嘗試，直到最後碰撞出來真實的 arr

像是對比兩個陣列是否相同，下面程式碼看似沒什麼問題，業務效果完全能達到，但是在絕對安全層面上是不安全的

當然業務程式碼中沒必要這麼嚴苛，因為比如上述程式碼上如果還有其他 if else 判斷，就完全沒辦法碰撞出來了

爬蟲

爬蟲就是一種按照一定規則自動抓取資源的程式或者指令碼，搜尋引擎可以用爬蟲抓取網頁、圖片、影片、音訊等

對於有一些沒有防範的系統，透過爬蟲，甚至可以把人家會員才能看或者付費下載的資源直接給爬下來，假設網站上有一個 10MB 的檔案，使用爬蟲抓取上千上萬次，就會導致網站產生大量出站流量，很可能還會使伺服器癱瘓無法訪問了

防範其實主要就是服務端安全校驗的問題，比如設定 robots.txt 檔案、比如對請求中的 User Agent 識別和限制，說到底防爬蟲主要是防範這幾個點：ip、origin、referer、request headers

如果沒有併發的去請求去爬蟲的時候，它不會針對 ip 做校驗，只會判斷後面幾個，而如果沒有後幾點就會認為你是不安全的系統，就給爺爬

結語

如果本文對你有一點點幫助，點個贊支援一下吧，你的每一個【贊】都是我創作的最大動力 ^_^

更多前端文章，或者加入前端交流群，歡迎關注公眾號【沐華說技術】，大家一起共同交流和進步呀

相關文章