伺服器漏洞修復：TLS 1.0 已啟用、HSTS、CSP

sowler發表於2024-11-11
伺服器TLS

1、TLS 1.0 已啟用

描述：

此 Web 伺服器支援透過 TLS 1.0 加密。TLS 1.0 不被認為是“強密碼術”。根據 PCI 資料安全標準 3.2(.1) 的定義和要求，在保護從網站往返的敏感資訊時，TLS 1.0 並不被認為是 "強加密"。根據 PCI，"2018 年 6 月 30 日是禁用 SSL/早前 TLS 並實施更安全的加密協議 TLS 1.1 或更高版本（強烈建議 TLS v1.2） 的最後期限，以便滿足 PCI 資料安全標準 (PCI DSS)，保障支付資料的安全。

影響：

攻擊者可能能夠利用此問題實施中間人攻擊，以及解密受影響的服務與客戶端之間的通訊。

推薦 ：

建議禁用 TLS 1.0 並替換為 TLS 1.2 或更高版本。

解決方法：

Nginx 配置 TLSv1.2 或 TLSv1.3

首先檢視openssl版本：

 openssl version

 # 輸出
 OpenSSL 1.0.2k-fips  26 Jan 2017
 
 #Linux Centos7.9預設為以上版本， OpenSSL 1.1.1 及以上版本才支援TLS v1.3。

檢測是否支援TLS1.2

openssl s_client -connect xxxx.xxx.com.cn:443 -tls1_2

Nginx配置:

ssl_protocols TLSv1.2; 
# 這裡只使用1.2即可

# ssl_protocols TLSv1.2 TLSv1.3;

2、Nginx訪問靜態頁面顯示目錄列表

描述：

目錄列表是一個 Web 伺服器功能，在特定網站目錄中無索引檔案時顯示目錄內容。Web 伺服器上保 持此功能開啟會導致資訊洩露，因此相當危險。

影響：

使用者可以從受影響的目錄檢視所有檔案的列表，這可能會暴露敏感資訊。

例如：

解決：

Nginx中預設不會開啟目錄瀏覽功能，若發現當前已開啟該功能，可以編輯 nginx.conf檔案，刪除如下兩行：

autoindex on;
autoindex_exact_size on;

重啟Nginx。

3、未實施 HTTP 嚴格傳輸安全 (HSTS）

描述：

HTTP 嚴格傳輸安全 (HSTS) 規定，瀏覽器只能使用 HTTPS 訪問網站。檢測到您的 Web 應用程式未實 施 HTTP 嚴格傳輸安全 (HSTS)，因為響應中缺少嚴格傳輸安全報頭。

影響：

HSTS 可以用於預防和/或緩解某些型別的中間人 (MitM) 攻擊

解決：

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
add_header Strict-Transport-Security  'max-age=63072000; includeSubDomains; preload';
#或者
add_header X-Frame-Options SAMEORIGIN always;
add_header Strict-Transport-Security  'max-age=63072000; includeSubDomains; preload' always;


# max-age=31536000 指定了 HSTS 策略的有效期，這裡是一年。您可以根據需求調整有效期。
# includeSubDomains 表示 HSTS 策略將適用於所有的子域名。

4、未實施內容安全策略 (CSP)

描述：

內容安全策略 (CSP) 增加了額外的安全層，有助於檢測和緩解某些型別的攻擊，包括跨站指令碼 (XSS) 和資料注入攻擊。 內容安全策略 (CSP) 可透過新增 Content-Security-Policy 報頭實施。此報頭的值是一個字串，其中 13 包含描述內容安全策略的策略指令。要實施 CSP，您應該為站點使用的所有資源型別定義允許的來源列表。例如，如果您有一個簡單的站點，需要從 CDN 載入本地託管和 jQuery 庫中的指令碼、樣式表和 影像，則 CSP 報頭可能如下所示： Content-Security-Policy: default-src 'self'; script-src 'self' https://code.jquery.com; 檢測到您的 Web 應用程式未實施內容安全策略 (CSP)，因為響應中缺少 CSP 報頭。建議在您的 Web 應 用程式中實施內容安全策略 (CSP)。

影響：

CSP 可用於預防和/或緩解涉及內容/程式碼注入的攻擊，例如跨站指令碼/XSS 攻擊、需要嵌入惡意資源的 攻擊、涉及惡意使用 iframe 的攻擊（例如點選劫持攻擊）等。

推薦 ：

建議在您的 Web 應用程式中實施內容安全策略 (CSP)。配置內容安全策略涉及新增 Content-SecurityPolicy HTTP 報頭到 Web 頁面併為其賦值，以控制允許使用者代理為該頁面載入的資源。

解決：

在nginx配置檔案中新增請求頭 Content-Security-Policy：

# 新增 CSP 頭部
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';";

default-src 'self': 指定預設允許載入資源的來源為當前域名（'self'），這是一個基本的設定，確保只有當前網站的資源可以載入。
script-src 'self' 'unsafe-inline' 'unsafe-eval': 指定允許載入 JavaScript 的來源為當前域名，並允許內聯指令碼和使用 eval() 等不安全的 JavaScript 執行方式。注意，'unsafe-inline' 和 'unsafe-eval' 存在安全風險，建議儘量避免使用，而是優先考慮使用嚴格的 CSP 策略，如使用外部指令碼載入方式。
style-src 'self' 'unsafe-inline': 指定允許載入樣式表的來源為當前域名，並允許內聯樣式。同樣地，'unsafe-inline' 也應該儘量避免使用，可以透過外部 CSS 檔案載入來提高安全性。

# 根據以上資訊，新增以下程式碼
# 新增 CSP 頭部
add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://xxx.xxxx.com.cn; style-src 'self' https://xxx.xxx.com.cn cdn.jsdelivr.net ; img-src 'self' https://xxx.xxx.com.cn data:; font-src 'self' data: https://xxx.com cdn.jsdelivr.net;";

#多個地址以空格後面拼接即可

相關文章