配置安全響應頭可以有效地防止客戶端被入侵
檢測網址#
介紹與配置#
HTTP 嚴格傳輸安全(HSTS)#
http 是明文傳輸,完全沒有任何加密,這意味著任何人都可以從傳輸數據中獲取瀏覽器到伺服器間的所有內容。所以 https 使用的 TLS 加密十分值得推崇。然而,除非特殊指定 https,否則每次用域名訪問時,會首先向伺服器發送 http 請求,再由伺服器發送重定向到瀏覽器,接著瀏覽器才會升級為 https。
HSTS 就是解決這一問題的方法。
當瀏覽器接收到 https 站點發送的Strict-Transport-Security
頭,瀏覽器便會遵守參數規定的時間執行 https 訪問,當瀏覽器再次訪問該站且未過規定時間時,瀏覽器便不會再發出 HTTP 請求,而是直接轉用 https 連接,這防止了 SSL 剝離等針對尚未升級為 https 連接的攻擊。
e.g.
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
該頭具有三個參數:max-age=63072000
、includeSubDomains
、preload
。
max-age=
表明保持 HTTPS 連接的時間,後跟秒數,如max-age=31536000
含義為一年內僅使用 https 連接includeSubDomains
表示該域名下所有子域名皆使用 https 訪問
HSTS 很好,但最原始最開始的那次連接始終是 http,如果有個圖謀已久的腳本小子滲透專家始終盯著一舉一動,那該怎麼辦?
preload
參數便是用於解決這一問題。瀏覽器會從Chrome或Firefox預加載列表裡獲取應直接使用 https 連接的站點。該列表可在HSTSpreload主動提交
該列表可用chrome://net-internals/#hsts在本地 Chrome 上查詢和刪改
X-Frame-Options#
建議使用 CSP 參數代替
Content-Security-Policy
响应头有一个frame-ancestors
参数可以完美替代X-Frame-Options
响应头且具有更多特性
X-Frame-Options HTTP 响应头是用来给浏览器指示允许一个页面可否在
<frame>
、<iframe>
、<embed>
或者<object>
中展现的标记。站点可以通过确保网站没有被嵌入到别人的站点里面,从而避免点击劫持攻击。
e.g.
X-Frame-Options: SAMEORIGIN
該頭僅有兩個參數,SAMEORIGIN
和DENY
。
SAMEORIGIN
表明該頁面只允許同源域名展示 frameDENY
表明完全不允許任何 frame
X-Content-Type-Options#
該頭的主要作用是要求客戶端嚴格遵守響應頭Content-Type
中規定的文件MIME類型。否則瀏覽器會使用MIME-sniffing
猜測返回文件的內容並執行
如果該頭沒有被配置,那麼隱藏在圖片或其他媒體文件中的javascript
和css
就可能被攻擊者利用來滲透系統
e.g.
X-Content-Type-Options: nosniff
該頭僅有nosniff
一個參數來提示客戶端
nosniff
將阻止請求與 MIME 類型不符的情況發生。
X-XSS-Protection#
瀏覽器兼容性
目前僅 Safari 瀏覽器仍支持
該頭可被完全配置的 CSP 頭取代
該頭的作用和其名字一樣一目了然,基於瀏覽器防護 XSS 攻擊,因此不屬於任何規範和草案中。
e.g.
X-XSS-Protection: 1; mode=block
該頭有四個參數引用自 Mdn
-
0
禁止 XSS 過濾。 -
1
表明啟用 XSS 過濾。如果檢測到跨站腳本攻擊,瀏覽器將清除頁面(刪除不安全的部分)。 -
1;mode=block
表明啟用 XSS 過濾。如果檢測到攻擊,瀏覽器將不會清除頁面,而是阻止頁面加載。 -
1; report=<reporting-URI>
僅 chrome 4-77 版本支持。該參數表明啟用 XSS 過濾。如果檢測到跨站腳本攻擊,瀏覽器將清除頁面並使用 CSP report-uri 的功能發送違規報告。
Permissions Policy#
該頭可用來控制頁面可訪問的瀏覽器功能,這可以讓站點先一步為自身劃定可能使用權限範圍
e.g.
Permissions-Policy: geolocation=()
該頭具有很多個參數,參數語法為<directive>=<allowlist>
,前半部分表示權限,後半部分表示允許的白名單。
權限列表
是否允許設置document.domain
是否允許使用加密媒體擴展 API (EME)
任務在未呈現時是否應在框架中執行
任務在可見視口之外時是否應在幀中執行
是否允許使用Element.requestFullscreen()
是否允許使用Gamepad API
是否允許使用Geolocation API
是否允許通過界面收集有關設備方向的信息
是否允許使用WebHID API
連接到不常見或奇異的人機界面設備,例如備用鍵盤或遊戲手柄。
是否允許使用空閒檢測 API 來檢測用戶何時與他們的設備交互
是否允許收集有關用戶本地安裝字體的數據
是否允許通過界面收集有關設備方向的信息
是否允許使用音頻輸入設備
是否允許使用 Web MIDI API
是否允許使用Payment Request API
是否允許通過相應的 API 以畫中畫模式播放視頻。
是否允許使用Web Authentication API
來檢索已存儲的公鑰憑據
是否允許使用屏幕喚醒鎖定 API 來指示設備不應關閉或調暗屏幕
是否允許使用Web Serial API
與串行設備通信,通過串行端口直接連接,或通過 USB 或藍牙設備模擬串行端口
是否允許使用音頻輸出設備 API 來列出和選擇揚聲器
是否允許使用Web USB API
是否允許使用Navigator.share()
,Web Share API 將文本、鏈接、圖像和其他內容共享到用戶選擇的任意目的地,例如移動應用程序
是否允許使用 WebXR 設備 API 與 WebXR 會話進行交互
是否允許收集有關設備加速度信息
是否允許收集有關設備周圍環境中的亮度信息
是否允許自動播放通過HTMLMediaElement
請求的媒體。
是否允許使用電池狀態 API
是否允許使用視頻輸入設備
是否允許使用該getDisplayMedia()
方法捕獲螢幕內容
白名單則具有三種值:
*
: 允許當前頁面及所有呈現在頁中的內容使用該功能()
: 不允許使用該功能(self "https://example.org")
: 該種參數允許使用通配符,每個允許站點間以空格隔開,self
表示本頁面
內容安全策略(CSP)#
該頭定義了哪些內容允許被該頁面使用並執行。
CSP 配置很複雜,詳情可以看看阮一峰老師的博客 Content Security Policy 入門教程
我可不想重造輪子絕不是因為懶得寫
配置好 CSP 頭後也可以使用 Google 提供的CSP Evaluator檢測一下自己的 CSP 策略是否強力
跑分#
最上面的兩個檢測網址均可對響應頭進行檢測,Securityheaders 的檢測沒有 Mozilla 家的那麼嚴苛,一般來講檢測如果能達到 A + 就表明安全性響應頭配置得差不多了。