nginx安全加固

 

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 時，只允許加載指定的源。

Content-Security-Policy CSP防護

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

# 定義所有資源文件的默認加載規則為self，表示允許
# 相同來源的內容（相同的協議、域名和端口）
add_header Content-Security-Policy "default-src 'self';";

或

add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline';font-src 'self' data:; img-src 'self' data: 'unsafe-inline' https:; style-src 'self' 'unsafe-inline';frame-ancestors 'self'; frame-src 'self';connect-src https:";

X-XSS-Protection 開啟XSS防護

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 來發送報告。

 

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。

Strict-Transport-Security HSTS防護

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。

CSRF跨站偽請求防護

CSRF的一般防護策略：

1、限制referer請求來源

 

 代碼如下：

server {
     listen       7001;
     server_name  iot-test.cddpi.com;
     root   /var/html/;
     client_max_body_size 1024M;

     add_header X-Frame-Options 'SAMEORIGIN';

     location / {
        alias   /var/html/iot-admin-ui/;
        try_files $uri $uri/ /index.html;
        index  index.html;
     }
     location /cloud/ {
         proxy_set_header Host $http_host;
         proxy_pass http://192.168.0.76:7000/cloud/;
     }
     location /iot/ {
        valid_referers none blocked 192.168.0.41;   #現在referer源
        if ($invalid_referer) {
          return 403;
        }
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:5005/iot/;
     }
}

 

2、增加字段token驗證

3、在程序中增加filter，獲取referer之后，進行判斷
String verifyRefererStr=“http://localhost:8889/,http://localhost:8090/,http://localhost:80/”;
HttpServletRequest req = (HttpServletRequest) servletRequest;
String referer=req.getHeader(“referer”);
System.out.println(“referer:”+referer);
String[] verifyReferer = verifyRefererStr.split(",");
boolean csrfFlag=false;
for (String vReferer : verifyReferer) {
if (referer == null || referer.trim().startsWith(vReferer)) {
csrfFlag = true;
break;
}
}
if (!csrfFlag) {
System.out.println(“疑似CSRF攻擊，referer:” + referer);
return;
}
filterChain.doFilter(servletRequest, servletResponse);