前端的安全問題與防禦策略

子非魚丶發表於2019-05-12
前端

在前端的開發中，安全是我們必須要了解的一環，即使前端很難說有真正的安全，但是瞭解這些攻擊有助於我們如何去規避問題，畢竟安全問題都是需要提前預防，而不能等到真正發生的時候才來解決。

ClickJacking（點選劫持）

1.什麼是ClickJacking？

ClickJacking（點選劫持）是一種視覺上的欺騙手段。大概有兩種方式，一是攻擊者使用一個透明的iframe，覆蓋在一個網頁上，然後誘使使用者在該頁面上進行操作，此時使用者將在不知情的情況下點選透明的iframe頁面；二是攻擊者使用一張圖片覆蓋在網頁，遮擋網頁原有位置的含義。

2.如何防禦ClickJacking

對於第一種情況我們可以通過設定http響應頭標記X-Frame-Option來防止點選劫持。

X-Frame-Options：X-Frame-Options HTTP 響應頭是用來給瀏覽器指示允許一個頁面可否在<frame>,<iframe>或者<object>中展現的標記。網站可以使用此功能，來確保自己網站的內容沒有被嵌到別人的網站中去，也從而避免了點選劫持 (clickjacking) 的攻擊。

標記值 說明
DENY 表示該頁面不允許在 frame 中展示，即便是在相同域名的頁面中巢狀也不允許。
SAMEORIGIN 表示該頁面可以在相同域名頁面的 frame 中展示。
ALLOW-FROM uri 表示該頁面可以在指定來源的 frame 中展示。

除此之外我們還可以使用CSP（Content-Security-Policy）裡的frame-ancestors或frame-src來指定頁面允許嵌入哪些頁面。

對於不使用X-Frame—Options或CSP，參考網上的解決方法，在開啟頁面的時候檢查一下window.top和window.self是否相等來決定是否重定向。

if (window.self != window.top) {
    top.location.href = self.location.href
}
複製程式碼

至於第二種情況使用圖片遮擋網頁原有位置的含義，這種站點本身就是一個惡意站點，而不是來自第三方的攻擊，這裡不做討論。

CSRF（跨站偽造請求）

1.什麼是CSRF？

CSRF（跨站偽造請求）全稱為 Cross-site request forgery，CSRF是通過偽裝成受信任使用者的請求來利用受信任的網站。例如：一位使用者在站點A登入了，並且站點A把資訊儲存在使用者本地，之後當使用者開啟站點B，站點B的惡意程式碼竊取了這位使用者在站點A的個人使用者資訊，就可以假裝成這位使用者去請求站點A。

2.如何防禦CSRF

  • cookie不儲存重要資訊
  • cookie設定httpOnly，secure，此外path和domain儘量不使用預設值
  • cookie設定SameSite（這個屬性還不是一個規範，不確定是否有用）
  • 服務端增加多重安全校驗
  • 使用https協議或其他安全協議傳送請求

XSS（跨站指令碼攻擊）

1.什麼是XSS？

XSS（跨站指令碼攻擊）全稱為Cross Site Scripting，為了和CSS檔案（Cascading Style Sheets）區分，故稱為XSS。XSS通過往Web頁面插入惡意程式碼，當使用者訪問該頁面時，執行嵌入的惡意程式碼，以此來達到惡意攻擊使用者的目的。

XSS攻擊又分為儲存型和反射型。

儲存型：一般是指我們頁面中表單提交的資料存在惡意程式碼被儲存到資料庫中。

反射型：需要欺騙使用者自己去點選連結才能觸發XSS程式碼

2.如何防禦XSS

  • CSP（Content-Security-Policy）

CSP（Content-Security-Policy）允許站點管理者在指定的頁面控制使用者代理的資源。

設定CSP可以極大程度上提高頁面安全，CSP允許我們設定一套非常完善的資源允許請求規則，在此只大概羅列幾個。

標記值 說明
script-src 限制javascript 源。
style-src 限制層疊樣式表檔案源。
img-src 限制圖片和圖示源。
media-src 限制通過<audio> 或<video> 標籤載入的媒體檔案源。
  • SRI（Subresource Integrity）

在專案中我們可能會引入一些第三方的檔案，因為檔案在第三方的伺服器裡，理論上第三方是有可能篡改檔案對使用第三方的檔案的站點進行攻擊。在這種情況下我們可以使用SRI來保證我們引入的檔案不被篡改。

SRI（子資源完整性 Subresource Integrity ）用於讓瀏覽器檢查所下載的來自第三方的資源（例如 CDN）未被惡意篡改。它使用雜湊值檢查確保第三方資源的完整性。只要開發者提供了被需下載資源的雜湊值，瀏覽器就可以檢查實際下載的檔案是否與預期的雜湊值匹配。

如何使用SRI？只需給 script 或 style 標籤新增integrity屬性即可。

<script crossorigin="anonymous" integrity="shaxxx-xxxxxx" src="xxx.com/xxx.js"></script>
複製程式碼

要注意的是因為瀏覽器需要下載資源內容進行計算，所以如果引用第三方的檔案需要第三方伺服器支援跨域請求（CORS），客戶端則需要加上crossorigin="anonymous"屬性。

另外，我們還可以使用CSP設定require-sri-for強制頁面請求js或css檔案使用SRI。

  • X-XSS-Protection

X-XSS-Protection響應頭是瀏覽器檢測到頁面存在XSS攻擊時，設定瀏覽器的行為。通常預設值為1，檢測到XSS攻擊瀏覽器將會刪除不安全的部分。

標記值 說明
0 禁止XSS過濾。
1 啟用XSS過濾（通常瀏覽器是預設的）。 如果檢測到跨站指令碼攻擊，瀏覽器將清除頁面（刪除不安全的部分）。
1; mode=block 啟用XSS過濾。 如果檢測到攻擊，瀏覽器將不會清除頁面，而是阻止頁面載入。
1; report=<reporting-uri> 啟用XSS過濾。 如果檢測到跨站指令碼攻擊，瀏覽器將清除頁面並使用CSP report-uri指令的功能傳送違規報告。
  • 對提交的資料encode或過濾

在頁面裡提交的資料需要儲存到資料庫的場景下，我們需要對提交的資料進行encode或者某些特殊字元進行過濾，特別是某些資料我們需要用在src或href裡使用的情況。

除此之外，富文字也是XSS經常發生的重災區，對於富文字提交的資料是一定要進行過濾的。

總結

上文所述基本上是我們前端裡常見的安全問題，其實對於前端來說很難有真正的安全所言，畢竟我們的程式碼都是明文跑在瀏覽器上。

而現在基本上不使用https協議的請求全部都是不安全的，對於頁面上資料提交進行過濾校驗也是常規操作，大部分場景我們都是使用瀏覽器的機制來幫助我們防禦攻擊，增加第三方攻擊的成本。

相關文章