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

sowler發表於2024-11-11

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;";

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

相關文章