提升安全性的最佳 Nginx 配置

因爲安全問題一直是重中之重，這裏整理下 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;

該指令用三個可用的配置

• X-Frame-Options: DENY
• X-Frame-Options: SAMEORIGIN
• X-Frame-Options: ALLOW-FROM https://example.com/

當設置爲 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=<reporting-uri>

說明

• 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。