來了解下前端安全問題的那些事嗎？

導言

記錄下最近有關於安全問題的學習，主要從XSS,CSRF,HTTPS,CSP,SRI,頁面劫持幾個方面來講

XSS

概述

跨域腳本攻擊(cross-site scripting)
錯誤地將用戶輸入的內容當作了代碼的一部分進行執行

場景

防護措施（永遠不要相信用戶的任何輸入）

• 對於後端渲染：
  一、HTML標籤內容轉義
  二、內聯JavaScript轉義
  三、URL轉義

• 對於前端渲染：
  一、使用專業框架規避XSS風險
  二、使用.innerHTML/.outerHTML/document.write注意Encode
  三、拼接字符串做爲代碼執行時注意Encode
  四、儘可能不使用setTimeout(字符串)/new Function/eval

CSRF

概述

跨站請求僞造
攻擊者誘導受害者進入第三方網站
在第三方網站中向被攻擊網站發送跨站請求
利用受害者在被攻擊網站已經獲取的登陸態，冒充用戶對被攻擊的網站執行某項操做

攻擊原理

場景

防護措施

• 禁止跨站
  Samesite Cookie

Set-Cookie: foo=1; Samesite=Strict
Set-Cookie: foo=1; Samesite=Lax
複製代碼

嚴格模式： 任何狀況的跨站請求都不會攜帶該Cookie
寬鬆模式： 形成頁面刷新且是GET請求才會攜帶該Cookie

嚴格模式重新標籤進入/打開子域頁面都會丟失登陸態，用戶體驗較差                          
寬鬆模式安全性較低Samesite不支持子域，且目前兼容性較差
複製代碼

• 防止僞造
  使用CSRF Token
  服務端輸出CSRF Token到頁面
  頁面在發起請求時攜帶CSRF Token
  服務端收到請求時同時校驗CSRF Token和登陸態

• 隱藏令牌
  和Token有點像，好比說放在HTTP的header頭中，不放在連接上，這樣子會比較隱蔽，本質差很少，只是使用方式有所差異。

頁面劫持

概述

其實就是被誤導跑到別的地方去了，好比經常在一些電影資源網站點擊播放的時候跳到貪玩藍嶽的頁面之類的。

劫持場景

防護措施

防止頁面被放入iframe
1.使用JS代碼判斷 判斷當前parent是否爲top
window.top === window.parent

2.X-Frame-Options 指示瀏覽器是否容許該頁面被放入frame/iframe/embed/object

X-Frame-Options: deny
X-Frame-Options: sameorigin
X-Frame-Options: allow-from https://example.com/
複製代碼

HTTPS

概述

HTTPS = HTTP + SSL/TLS

• 客戶端請求服務端HTTPS端口
• 服務端向客戶端發送公鑰
• 客戶端校驗公鑰
• 客戶端生成隨機對稱加密祕鑰
• 客戶端使用公鑰加密對稱加密祕鑰併發送給服務端
• 服務端收到後解密得到對稱加密祕鑰
• 客戶端與服務端使用對稱加密祕鑰加密消息傳輸

場景

防護措施

• HTTP Strict-Transport-Security
  使用HTTP訪問時強制使用HTTPS 第一次成功HTTPS訪問後返回HSTS響應頭 之後max-age時間內瀏覽器均會內部307到HTTPS站點
  Strict-Transport-Security: <max-age=>[; includeSubDomains][; preload]

• HSTS Preload
  向谷歌提交HTTPS預加載列表
  獲取不通過第一次HTTPS的強行調整

CSP

概述

Content Security Policy
內容安全策略
用於檢測/阻止/削弱某類攻擊
使用HTTP Header/meta進行配置

場景

• 跨站腳本攻擊
  CSP 的主要目標是減小和報告 XSS 攻擊 ，XSS 攻擊利用了瀏覽器對於從服務器所獲取的內容的信任。惡意腳本在受害者的瀏覽器中得以運行，由於瀏覽器信任其內容來源，即便有的時候這些腳本並不是來自於它本該來的地方。

  CSP經過指定有效域——即瀏覽器承認的可執行腳本的有效來源——使服務器管理者有能力減小或消除XSS攻擊所依賴的載體。一個CSP兼容的瀏覽器將會僅執行從白名單域獲取到的腳本文件，忽略全部的其餘腳本 (包括內聯腳本和HTML的事件處理屬性)。

  做爲一種終極防禦形式，始終不容許執行腳本的站點能夠選擇全面禁止腳本執行

• 數據包嗅探攻擊
  除限制能夠加載內容的域，服務器還可指明哪一種協議容許使用；好比 (從理想化的安全角度來講)，服務器可指定全部內容必須經過HTTPS加載。一個完整的數據安全傳輸策略不只強制使用HTTPS進行數據傳輸，也爲全部的cookie標記安全標識 cookies with the secure flag，而且提供自動的重定向使得HTTP頁面導向HTTPS版本。網站也可使用 Strict-Transport-Security HTTP頭部確保鏈接它的瀏覽器只使用加密通道。

使用方法

• 限制文檔內加載各種資源的來源域名
• 限制文檔內容許提交的表單、訪問類型
• 當CSP違規時上報到指定地址
• 指定某些資源使用SRI校驗
• 阻止加載和執行外部JS
• 減小XSS和注入劫持
• 防止資源污染
• 統計站點的安全程度

使用示例

Content-Security-Policy: default-src 'self'
複製代碼

Content-Security-Policy: default-src 'self' *.trusted.com
複製代碼

Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com
複製代碼

SRI

概述

子資源完整性 Subresource Integrity 簡稱 SRI 是一種安全機制，它用於讓瀏覽器檢查所下載的來自第三方的資源（例如 CDN）未被惡意篡改。它使用哈希值檢查確保第三方資源的完整性。只要開發者提供了被需下載資源的哈希值，瀏覽器就能夠檢查實際下載的文件是否與預期的哈希值匹配。

場景

• CDN劫持
  靜態資源在CDN被污染/替換/追加額外惡意代碼
  額外加入的代碼可能會致使頁面跳轉/追加廣告/打開APP等
  即便是HTTPS也有可能被劫持
  CDN劫持一般偶發，難以復現和定位

使用方法

• 只需給 script 或 style 標籤添加 integrity 屬性便可

• 使用CSP控制SRI的開啓
  你可使用 內容安全政策 （CSP）強制要求當前頁面全部腳本加載標籤啓用 SRI。例如
  Content-Security-Policy: require-sri-for script;
  強制要求全部 script 標籤啓用 SRI，瀏覽器會拒絕加載未啓用 SRI 的 script 標籤。
  對應的還有 CSS 版本：
  Content-Security-Policy: require-sri-for style;