[研究]Nessus 對 HSTS 誤判可能分析

[研究]Nessus 對 HSTS 誤判可能分析

2025-11-07

Nessus Pro 為何產生這種誤判，以下面網址測試 HSTS 是正常的，Nessus Pro 無法判斷首頁 default.aspx 轉址到 login.aspx 的情況嗎 ? 

Domsignal 網站 HSTS (HTTP Strict Transport Security) 測試 https://domsignal.com/hsts-test

弱點名稱	HSTS Missing From HTTPS Server (RFC 6797)
IP	(略)
風險等級	Medium
弱點描述	The remote web server is not enforcing HSTS, as defined by RFC 6797.
建議修補方式	Configure the remote web server to use HSTS. HSTS is an optional response header that can be configured on the server to instruct the browser to only communicate via HTTPS. The lack of HSTS allows downgrade attacks,SSL-stripping man-in-the-middle attacks, and weakens cookie-hijacking protections.
CVE Score	6.5
弱點ID	(略)
HSTS Missing From HTTPS Server (RFC 6797)
Port Number	Plugin_Output
443	HTTP/1.1 404 Not Found Content-Type: text/html; charset=us-ascii Server: Microsoft-HTTPAPI/2.0 Date:(略) Connection: close Content-Length:(略) The remote HTTPS server does not send the HTTP "Strict-Transport-Security" header.

ChatGPT

✅ Domsignal 測試顯示 HSTS 正常

但 ❌ Nessus Pro 卻回報 “HSTS Missing From HTTPS Server (RFC 6797)”，這種情況在實務上其實相當常見，而且屬於 Nessus 的「誤判（False Positive）」 類型之一。

下面我詳細說明 為何 Nessus Pro 會誤報 HSTS 缺失，以及它在遇到 default.aspx → login.aspx 轉址時的行為限制。

🧩 一、Nessus 偵測 HSTS 的邏輯

1.Nessus 的 plugin（通常是 Plugin ID 150437 或相近）會：

向目標的 Port 443 發送 一個 HTTPS GET 要求，例如：

GET / HTTP/1.1

Host: example.com

2. 只分析這個 第一個回應（HTTP Response Header） 是否包含：

Strict-Transport-Security: max-age=xxxx

3.如果這個回應：

是 301/302 轉址；

或是 404/403 頁面；

或是伺服器使用 Microsoft-HTTPAPI/2.0 回覆（表示不是 IIS 正常網站回應）；

那 Nessus 不會再自動追蹤轉址或執行第二次要求。

→ 因此，它會誤以為「HSTS header 不存在」。

⚙️ 二、你網站的狀況推測

根據你提供的資訊：

項目	狀況	說明
首頁 /	可能是 HTTPAPI 回覆 404 或轉址到 /default.aspx	Nessus 掃描可能命中這頁
/default.aspx	再轉址到 /login.aspx	Nessus 預設不追蹤第二層轉址
/login.aspx	正常載入並送出 Strict-Transport-Security: 標頭	Domsignal 測試會看到這個 header，所以判定正常
結果	Nessus 未抵達這層頁面	導致「誤報」HSTS 缺失

🧠 三、誤判的原因歸納

Nessus Plugin 報告中：

HTTP/1.1 404 Not Found

Server: Microsoft-HTTPAPI/2.0

這其實是關鍵。

這代表 Nessus 掃描的是：

一個不存在的路徑（例如 / 沒有 Default Document，或沒有正確映射到 IIS）。

或是 IIS 沒接手該請求，而是 Windows HTTPAPI（例如 URL ACL 沒綁定、IIS 沒在該 port 處理）回應的錯誤頁面。

👉 也就是說：

Nessus 沒有實際掃到你網站的 IIS 回應，而是掃到系統層的 HTTP.sys 回覆。

HTTPAPI/2.0 這行就代表它沒有看到你網站的 HSTS header。

🧩 四、驗證方式建議

你可以用 curl 指令驗證 Nessus 的視角：

curl -I https://yourdomain.com/

如果回傳是：

HTTP/1.1 404 Not Found

Server: Microsoft-HTTPAPI/2.0

→ 代表 Nessus 看到的就是這個頁面，而不是 login.aspx。

這樣 HSTS 當然不會被偵測到。

如果你用：

curl -I https://yourdomain.com/login.aspx

看到：

HTTP/1.1 200 OK

Strict-Transport-Security: max-age=31536000; includeSubDomains

→ 那 HSTS 實際上是正確設定的，只是 Nessus 沒追到這層。

🧩 五、解法建議

✅ 解法 1：讓首頁 / 就回應 HSTS Header

即使會轉址，也建議首頁加上：

Strict-Transport-Security: max-age=31536000; includeSubDomains

在 所有回應（含 301/302） 都送出這個 Header，

可以在 IIS 內設定：

HTTP 回應標頭 → 新增：

名稱：Strict-Transport-Security

值：max-age=31536000; includeSubDomains

✅ 解法 2：確認 Default Document 與轉址處理

在 IIS → 網站 → Default Document 功能中，確認：

default.aspx

位於清單中並啟用，確保 / 不會直接 404。

✅ 解法 3：忽略此誤報（在報告註記中）

若是政府資安稽核報告要求，只要附上：

curl 實測畫面

Domsignal / SecurityHeaders.com 測試結果

就可佐證為「誤報（False Positive）」。

📘 總結

項目	說明
掃描工具	Nessus Pro
問題原因	Nessus 不追蹤 302/404、未看到 login.aspx header
誤判條件	default.aspx / login.aspx 轉址、HTTPAPI 回應
驗證方式	curl / SecurityHeaders.com / Domsignal
解決方式	在所有回應包含 HSTS、確認 IIS Default Document

(完)