提高安全性的最佳 Nginx 配置

godruoyi發表於2018-04-09
Nginx

file

由於安全問題一直是重中之重，這裡整理下 nginx 的安全配置。文章大部分參考了 Best nginx configuration for improved security(and performance). 及 Jerry Qu，更多關於 HTTP 安全及效能可前往 Jerry Qu 檢視。

server_tokens

該響應頭用於禁止 nginx 在響應中報文中包含版本資訊。因為具體的版本可能會存在未知 bug。

server_tokens off;

X-Frame-Options

該響應頭用於是否允許瀏覽器載入 frame、 iframe、 object 等屬性。可以使用該功能來避免 點選劫持

add_header X-Frame-Options SAMEORIGIN;

該指令用三個可用的配置

當設定為 DENY 時，站點禁止任何頁面被嵌入。

當設定為 SAMEORIGIN 時，只允許載入同源的 fram/iframe/object。

當設定為 ALLOW-FROM 時，只允許載入指定的源。

X-Content-Type-Options

在我們通常的請求響應中，瀏覽器會根據 HTTP 響應的 Content-Type 來分辨響應的型別。如 text/html 代表 html 文件。 但當響應型別未指定或錯誤指定時，瀏覽會嘗試啟用 MIME-sniffing 來猜測資源的響應型別。

如通過精心製作一個影像檔案，並在其中嵌入可以被瀏覽器所展示和執行的 HTML 和 JavaScript 程式碼。由於未關閉資源的型別猜測，瀏覽器將直接執行嵌入的 JavaScript 程式碼，而不是顯示圖片。

add_header X-Content-Type-Options nosniff;

用來指定瀏覽器對未指定或錯誤指定 Content-Type 資源真正型別的猜測行為，nosniff 表示不允許任何猜測。（Jerry Qu）

這個響應頭的值只能是 nosniff，可用於 IE8+ 和 Chrome。

X-XSS-Protection

add_header X-XSS-Protection "1; mode=block";

該響應頭是用於防範及過濾 XSS 的。可用的幾個指令如下：

  • X-XSS-Protection: 0
  • X-XSS-Protection: 1
  • X-XSS-Protection: 1; mode=block
  • X-XSS-Protection: 1; report=

說明

  • 0，禁用 XSS 過濾
  • 1，開啟 XSS 過濾
  • 1; mode=block，開啟 XSS 過濾，並且若檢查到 XSS 攻擊，停止渲染頁面。
  • X-XSS-Protection: 1; report=<reporting-uri>，開啟 XSS 過濾，並且若檢查到 XSS 攻擊，將使用指導的 url 來傳送報告。

Content-Security-Policy

該響應頭主要用於規定頁面可以載入那些資源（css/js/img 等）。看一個簡單的配置

# 定義所有資原始檔的預設載入規則為self，表示允許
# 相同來源的內容（相同的協議、域名和埠）
add_header Content-Security-Policy: default-src 'self';

更多 Content-Security-Policy 的指令及規則及介紹可參考 Jerry Qu 的 Content Security Policy 介紹。

Strict-Transport-Security

Strict-Transport-Security，簡稱 HSTS。該響應頭用於標識瀏覽器用 HTTPS 替代 HTTP 的方式去訪問目標站點。

我們知道 HTTPS 相對於 HTTP 有更好的安全性，而很多 HTTPS 網站，也可以通過 HTTP 來訪問。開發人員的失誤或者使用者主動輸入地址，都有可能導致使用者以 HTTP 訪問網站，降低了安全性。一般，我們會通過 Web Server 傳送 301/302 重定向來解決這個問題。 （Jerry Qu）

我們可以使用下面方式啟用 HSTH。

add_header strict-transport-security: max-age=16070400; includeSubDomains;

當使用者第一次訪問後，將返回一個包含了 strict-transport-security 響應頭的欄位。他將告訴瀏覽器，在接下來的 16070400 秒內，當前網站的所有請求都強制使用 HTTPS 的方式訪問。即使使用者手動輸入 http://，瀏覽器也會強制使用 HTTPS 方式訪問。

引數 includeSubDomains 是可選的，當指定了該引數，所有子域名將採用同樣的 HSTS 規則。

可以看到 HSTS 可以很好的解決 HTTPS 降級攻擊，但是對於 HSTS 生效前的首次 HTTP 請求，依然無法避免被劫持。瀏覽器廠商們為了解決這個問題，提出了 HSTS Preload List 方案：內建一份可以定期更新的列表，對於列表中的域名，即使使用者之前沒有訪問過，也會使用 HTTPS 協議。 （Jerry Qu）

如果你想把自己的域名加入這個列表，可通過 hstspreloa.org 檢視是否滿足申請條件。更多關於 HSTS 的配置，可檢視 關於啟用 HTTPS 的一些經驗分享。

目前 godruoyi.com 已成功加入 Preload List。

本作品採用《CC 協議》，轉載必須註明作者和本文連結

二楞徐的閒談雜魚

相關文章