前端必須知道的 HTTP 安全頭配置

在本文中，我將介紹常用的安全頭信息設置，並給出一個示例。在本文的最後，我將介紹用於常見應用程序和web服務器的安全頭信息示例設置。

Content-Security-Policy

內容安全策略（CSP）常用來通過指定允許加載哪些資源來防止跨站點腳本攻擊。在接下來所介紹的所有安全頭信息中，CSP 可能是創建和維護花費時間最多的而且也是最容易出問題的。在配置你的網站 CSP 過程中，要小心徹底地測試它，因爲阻止某些資源有可能會破壞你的網站的功能。

功能

CSP 的主要目標是減少和報告 XSS 攻擊， XSS 攻擊利用了瀏覽器對於從服務器所獲取的內容的信任。使得惡意腳本有可能在用戶的瀏覽器中執行，因爲瀏覽器信任其內容來源，即使有時候這些腳本並非來自該站點的服務器當中。

CSP 通過指定允許瀏覽器加載和執行那些資源，使服務器管理者有能力減少或消除 XSS 攻擊的可能性。 一個 CSP 兼容的瀏覽器將會僅執行從白名單域獲取得到的腳本文件，忽略所有其他的腳本（包括內聯腳本）。

示例

一個最佳的 CSP 可能是下面這樣(註釋按照配置值的順序)，在站點包含的每一部分資源請求相關都加入域名限制。

# 所有的內容(比如: JavaScript,image,css,fonts,ajax request, frams, html5 Media等)均來自和站點的同一個源（不包括其子域名）
# 允許加載當前源的圖片和特定源圖片
# 不允許 objects（比如 Flash 和 Java）
# 僅允許當前源的腳本下載和執行
# 僅允許當前源的 CSS 文件下載和執行
# 僅允許當前源的 frames
# 限制 <base> 標籤中的 URL 與當前站點同源
# 僅允許表單提交到當前站點

Content-Security-Policy: default-src 'self'; img-src 'self' https://img.com; object-src 'none'; script-src 'self'; style-src 'self'; frame-ancestors 'self'; base-uri 'self'; form-action 'self';

關於 CSP 更加詳細的介紹可以看 https://content-security-poli...

Strict-Transport-Security

Strict-Transport-Security(HSTS) 告訴瀏覽器該站點只能通過 HTTPS 訪問，如果使用了子域，也建議對任何該站點的子域強制執行此操作。

功能

一個站點如果接受了一個 HTTP 請求，然後跳轉到 HTTPS，用戶可能在開始跳轉前，通過沒有加密的方式和服務器對話。這樣就存在中間人攻擊的潛在威脅，跳轉過程可能被惡意網站利用來直接接觸用戶信息，而不是原來的加密信息。

網站通過HTTP Strict Transport Security通知瀏覽器，這個網站禁止使用HTTP方式加載，瀏覽器應該自動把所有嘗試使用HTTP的請求自動替換爲HTTPS請求。

示例

# 瀏覽器接受到這個請求後的 3600 秒內的時間，凡是訪問這個域名下的請求都是用https請求
# 指定 includeSubDomains 此規則適用該站點下的所有子域名

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

X-Content-Type-Options

X-Content-Type-Options 響應頭相當於一個提示標誌，被服務器用戶提示瀏覽器一定要遵循 Content-Type 頭中 MIME 類型的設定，而不能對其進行修改。

功能

它減少了瀏覽器可能“猜測”某些內容不正確的意外應用程序行爲，例如當開發人員將一個頁面標記爲“HTML”，但瀏覽器認爲它看起來像JavaScript並試圖將其呈現爲JavaScript時。這個頭將確保瀏覽器始終按照服務器設置的MIME類型來解析。

示例

X-Content-Type-Options: nosniff

Cache-Control

Cache-Control 通用消息頭字段，被用於在 http 請求和響應中，通過指定指令來實現緩存機制。緩存指令是單向的，這意味着在請求中設置的指令，不一定被包含在響應中。

功能

這一個比其他的稍微複雜一些，因爲你可能需要針對不同的內容類型使用不同的緩存策略。

任何包含有敏感信息的網頁，例如用戶個人信息頁面或客戶結帳頁面，都應該設置爲 no-cache。原因是防止共享計算機上的某人按下後退按鈕或瀏覽歷史並查看個人信息。

示例

Cache-Control: no-cache

X-Frame-Options

X-Frame-Options 響應頭是用來給瀏覽器指示允許一個頁面可否在 <frame>, <iframe>, <embed> 或者 <object> 中展現的標記。站點可以通過確保網站沒有被嵌入到別人的站點裏面，從而避免點擊劫持攻擊。

功能

如果惡意的站點將你的網頁嵌入到 iframe 標籤中, 在你不知道的情況下打開並點擊惡意網站的某個按鈕，惡意網站能夠執行一個攻擊通過運行一些 JavaScript 將捕獲點擊事件到 iframe 中,然後代表你與網站交互。

將 X-Frame-Options 設置爲 deny 可以禁止該頁面在任何域中的 ifram 標籤中展示。

X-Frame-Options 設置可以由 CSP 的 frame-ancestors 配置所代替。

示例

X-Frame-Options: DENY # 表示該頁面不允許在 frame 中展示，即便是在相同域名的頁面中嵌套也不允許。

X-Frame-Options: SAMEORIGIN # 表示該頁面可以在相同域名頁面的 frame 中展示。

X-Frame-Options: ALLOW-FROM uri # 表示該頁面可以在指定來源的 frame 中展示。

Access-Control-Allow-Origin

Access-Control-Allow-Origin 響應頭指定了該響應的資源是否被允許與給定的 origin 共享。

功能

可以被用來可解決瀏覽器的跨域請求。

比如一個站點 A 頁面中發起一個 AJAX 請求到 站點 B， A B 不同源。正常情況下因爲瀏覽器的同源策略將不會把 B 的響應結果返回給 A, 除非 B 在響應頭中設置允許 A 站點發起請求。

示例

Access-Control-Allow-Origin: * # 允許所有域請求

Access-Control-Allow-Origin: http://someone.com # 允許特定域請求

Set-Cookie

Set-Cookie 響應頭被用來由服務器端向客戶端發送 cookie。

示例

# domain: 指定 cookie 可以送達的域名，默認爲當前域名（不包含子域名）
# Secure: 只有在 https 協議時纔會被髮送到服務端。然而，保密或敏感信息永遠不要在 HTTP cookie 中存儲或傳輸，因爲整個機制從本質上來說都是不安全的
# HttpOnly: cookie 不能使用 JavaScript代碼獲取到

Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly

X-XSS-Protection

X-XSS-Protection 響應頭是Internet Explorer，Chrome和Safari的一個功能，當檢測到跨站腳本攻擊 (XSS)時，瀏覽器將停止加載頁面。

示例

X-XSS-Protection: 1; mode=block  # 啓用XSS過濾。如果檢測到 XSS 攻擊，瀏覽器將不會清除頁面，而是阻止頁面加載。

總結

設置 HTTP 頭信息是相對快速和簡單的對於網站的數據保護、XSS 攻擊和點擊劫持等攻擊。有針對性的設置這些頭信息，你的網站的安全性將會有不錯的提高。

面試題

查看原文

關注github每日一道面試題詳解