提醒：本文最後更新於 1326 天前，文中所描述的資訊可能已發生改變，請謹慎使用。

之前有細心的朋友問我，為什麼你的部落格副標題是「專注 WEB 端開發」，是不是少了「前端」的「前」。我想說的是，儘管我從畢業到現在七年左右的時間一直都在專業前端團隊從事前端相關工作，但這並不意味著我的知識體系就必須侷限於前端這個範疇內。現在比較流行「全棧工程師」的概念，我覺得全棧意味著一個專案中，各個崗位所需要的技能你都具備，但並不一定意味著你什麼都需要做。你需要做什麼，更多是由能力、人員配比以及成本等各個因素所決定。儘管我現在的工作職責是在 WEB 前端領域，但是我的關注點在整個 WEB 端。

我接觸過的有些前端朋友，從一開始就把自己侷限在一個很小的範圍之中，這在大公司到也無所謂，大公司分工明確，基礎設施齊全，你只要做好自己擅長的那部分就可以了。但是當他們進入創業公司之後，會發現一下子來了好多之前完全沒有接觸過的東西，十分被動。

去年我用 Lua + OpenResty 替換了線上千萬級的 PHP + Nginx 服務，至今穩定執行，算是前端之外的一點嘗試。我一直認為學習任何知識很重要的一點是實踐，所以我一直都在折騰我的 VPS，進行各種 WEB 安全、優化相關的嘗試。我打算從安全和效能兩方面介紹一下本部落格所用 Nginx 的相關配置，今天先寫安全相關的。

隱藏不必要的資訊

大家可以看一下我的部落格請求響應頭，有這麼一行 server: nginx，說明我用的是 Nginx 伺服器，但並沒有具體的版本號。由於某些 Nginx 漏洞只存在於特定的版本，隱藏版本號可以提高安全性。這隻需要在配置里加上這個就可以了：

server_tokens
 
   off;

如果想要更徹底隱藏所用 Web Server，可以修改 Nginx 原始碼，把 Server Name 改掉再編譯，具體步驟可以自己搜尋。需要提醒的是：如果你的網站支援 SPDY，只改動網上那些文章寫到的地方還不夠，跟 SPDY 有關的程式碼也要改。更簡單的做法是改用 Tengine 這個 Nginx 的增強版，並指定 server_tag 為 off 或者任何想要的值就可以了。另外，既然想要徹底隱藏 Nginx，404、500 等各種出錯頁也需要自定義。

同樣，一些 WEB 語言或框架預設輸出的 x-powered-by 也會洩露網站資訊，他們一般都提供了修改或移除的方法，可以自行檢視手冊。如果部署上用到了 Nginx 的反向代理，也可以通過 proxy_hide_header 指令隱藏它：

proxy_hide_header        X-Powered-By;

禁用非必要的方法

由於我的部落格只處理了 GET、POST 兩種請求方法，而 HTTP/1 協議還規定了 TRACE 這樣的方法用於網路診斷，這也可能會暴露一些資訊。所以我針對 GET、POST 以及 HEAD 之外的請求，直接返回了 444 狀態碼（444 是 Nginx 定義的響應狀態碼，會立即斷開連線，沒有響應正文）。具體配置是這樣的：

if ($request_method !~ ^(GET|HEAD|POST)$ ) {
    return    444;
}

合理配置響應頭

我的部落格是由自己用 ThinkJS 寫的 Node 程式提供服務，Nginx 通過 proxy_pass 把請求反向代理給 Node 繫結的 IP 和埠。在最終輸出時，我給響應增加了以下頭部：

add_header  Strict-Transport-Security  "max-age=31536000";
add_header  X-Frame-Options  deny;
add_header  X-Content-Type-Options  nosniff;
add_header  Content-Security-Policy  "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://a.disquscdn.com; img-src 'self' data: https://www.google-analytics.com; style-src 'self' 'unsafe-inline'; frame-src https://disqus.com";

Strict-Transport-Security（簡稱為 HSTS）可以告訴瀏覽器，在指定的 max-age 內，始終通過 HTTPS 訪問我的部落格。即使使用者自己輸入 HTTP 的地址，或者點選了 HTTP 連結，瀏覽器也會在本地替換為 HTTPS 再發送請求。另外由於我的證書不支援多域名，我沒有加上 includeSubDomains。關於 HSTS 更多資訊，可以檢視我之前的介紹。

X-Frame-Options 用來指定此網頁是否允許被 iframe 巢狀，deny 就是不允許任何巢狀發生。關於這個響應頭的更多介紹可以看這裡。

X-Content-Type-Options 用來指定瀏覽器對未指定或錯誤指定 Content-Type 資源真正型別的猜測行為，nosniff 表示不允許任何猜測。這部分內容更多介紹見這裡。

Content-Security-Policy（簡稱為 CSP）用來指定頁面可以載入哪些資源，主要目的是減少 XSS 的發生。我允許了來自本站、disquscdn 的外鏈 JS，還允許內聯 JS，以及在 JS 中使用 eval；允許來自本站和 google 統計的圖片，以及內聯圖片（Data URI 形式）；允許本站外鏈 CSS 以及內聯 CSS；允許 iframe 載入來自 disqus 的頁面。對於其他未指定的資源，都會走預設規則 self，也就是隻允許載入本站的。關於 CSP 的詳細介紹請看這裡。

之前的部落格中，我還介紹過 X-XSS-Protection 這個響應頭，也可以用來防範 XSS。不過由於有了 CSP，所以我沒配置它。

需要注意的是，以上這些響應頭現代瀏覽器才支援，所以並不是說加上他們，網站就可以不管 XSS，萬事大吉了。但是鑑於低廉的成本，還是都配上。

HTTPS 安全配置

啟用 HTTPS 並正確配置了證書，意味著資料傳輸過程中無法被第三者解密或修改。有了 HTTPS，也得合理配置好 Web Server，才能發揮最大價值。我的部落格關於 HTTPS 這一塊有以下配置：

ssl_certificate      /home/jerry/ssl/server.crt;
ssl_certificate_key  /home/jerry/ssl/server.key;
ssl_dhparam          /home/jerry/ssl/dhparams.pem;

ssl_ciphers          ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:DES-CBC3-SHA;

ssl_prefer_server_ciphers  on;

ssl_protocols        TLSv1 TLSv1.1 TLSv1.2;

最終效果是我的部落格在 ssllabs 的測試中達到了 A+，如下圖：

如何配置 ssl_ciphers 可以參考這個網站。需要注意的是，這個網站預設提供的加密方式安全性較高，一些低版本客戶端並不支援，例如 IE9-、Android2.2- 和 Java6-。如果需要支援這些老舊的客戶端，需要點一下網站上的「Yes, give me a ciphersuite that works with legacy / old software」連結。

另外，我在 ssl_ciphers 最開始加上了 CHACHA20，這是因為我的 Nginx 支援了 CHACHA20_POLY1305 加密演算法，這是由 Google 開發的新一代加密方式，它有兩方面優勢：更好的安全性和更好的效能（尤其是在移動和可穿戴裝置上）。下面有一張移動平臺上它與 AES-GCM 的加密速度對比圖（via）：

啟用 CHACHA20_POLY1305 最簡單的方法是在編譯 Nginx 時，使用 LibreSSL 代替 OpenSSL。下面是用 Chrome 訪問我的部落格時，點選位址列小鎖顯示的資訊，可以看到加密方式使用的就是 CHACHA20_POLY1305：

關於 CHACHA20_POLY1305 安全性和效能的詳細介紹可以檢視本文。

補充：使用 CHACHA20_POLY1305 的最佳實踐是「僅針對不支援 AES-NI 的終端使用 CHACHA20 演算法，否則使用 AES-GCM」。關於這個話題的詳細解釋和配置方法，請參考我的這篇文章：使用 BoringSSL 優化 HTTPS 加密演算法選擇。

SSLv3 已被證實不安全，所以在 ssl_protocols 指令中，我並沒有包含它。

將 ssl_prefer_server_ciphers 配置為 on，可以確保在 TLSv1 握手時，使用服務端的配置項，以增強安全性。

好了，本文先就這樣，後面再寫跟效能有關的配置。

--EOF--

發表於 2015-05-24 20:02:42 ，並被新增「 Nginx 、 Web安全 」標籤 ，最後修改於 2015-05-25 14:30:53 。檢視本文 Markdown 版本 »

提醒：本文最後更新於 1326 天前，文中所描述的資訊可能已發生改變，請謹慎使用。