HSTS Missing From HTTPS Server：一次搞懂弱掃原因與 IIS 處理方式

這個弱點不是說網站沒有 HTTPS，也不是說憑證一定錯誤。它真正指出的是，網站雖然可以用 HTTPS 開啟，但 HTTPS 回應沒有告訴瀏覽器「這個網域之後只能走 HTTPS」。

HSTS 是什麼

HSTS 全名是 HTTP Strict Transport Security。

它是一個由伺服器透過 HTTPS response header 回傳給瀏覽器的安全政策

Strict-Transport-Security: max-age=31536000

Strict-Transport-Security: max-age=31536000

瀏覽器收到後，會記住這個網域在指定時間內只能使用 HTTPS。

之後即使使用者輸入 http:// 網址，瀏覽器也會在送出 request 前自動改成 https://。

HSTS 不是等伺服器收到 HTTP request 後再 redirect，而是在瀏覽器端就先阻止 HTTP 連線。

為什麼缺少 HSTS 會被列為弱點

很多人會以為「網站已經支援 HTTPS」就足夠了，但實際上使用者仍可能透過 HTTP 進站。

如果沒有 HSTS，流程可能是：

使用者輸入 HTTP 網址。
瀏覽器先送出一個未加密的 HTTP request。
伺服器回應 redirect，要求改走 HTTPS。
使用者最後看到的是 HTTPS 頁面。

表面上看起來正常，但第 2 步的 HTTP request 已經經過不安全通道。如果攻擊者位在中間網路，就可能攔截或改寫這段流量，造成 SSL stripping 或中間人攻擊風險。

HSTS 的目的，就是讓瀏覽器在送出 request 前就知道，這個網域不能使用 HTTP。

Redirect 和 HSTS 的差異

HTTP redirect 是伺服器端行為。

使用者先連 HTTP，伺服器收到後才回應「請改去 HTTPS」。

HSTS 是瀏覽器端行為。

瀏覽器記住政策後，使用者就算輸入 HTTP 網址，瀏覽器也會直接改成 HTTPS，不會先送出 HTTP request。

所以 redirect 有幫助，但不能完全取代 HSTS。弱掃通常會檢查 HTTPS 回應中是否存在 Strict-Transport-Security header。

為什麼一定要用 HTTPS 測試

HSTS 只對 HTTPS 回應有效。

如果在 HTTP 回應裡加入 HSTS，瀏覽器也不會信任。原因是 HTTP 本身可以被中間人竄改，如果瀏覽器相信 HTTP 傳來的 HSTS 政策，反而會產生新的安全問題。

因此驗證時要測 HTTPS：

curl.exe -k -I ``[https://your-domain.example/path](https://your-domain.example/path)

成功時要看到：

Strict-Transport-Security: max-age=31536000

[圖片位置 3：curl 驗證成功截圖，請遮蔽網址、IP、Cookie、內部 header]

max-age=31536000 是什麼意思

max-age 是瀏覽器記住 HSTS 政策的秒數。

31536000 秒等於 365 天，也就是一年

365 * 24 * 60 * 60 = 31536000

365 * 24 * 60 * 60 = 31536000

這不是伺服器設定一年後失效，也不是一年後要重新設定。

只要網站每次 HTTPS 回應都持續帶出 HSTS header，瀏覽器每次收到都會重新計算有效時間。

做法一：使用 IIS 站台層 HSTS 設定

這是建議優先採用的方式，因為它是 IIS 原生設定，集中在站台層管理。

操作概念如下：

開啟 IIS 管理員。
選擇要設定的站台。
先確認站台有 HTTPS 繫結，並使用正確的 SSL 憑證。
回到站台層，開啟 HSTS 設定。
啟用 HSTS。
最大壽命填入 31536000。
IncludeSubDomains 先不勾，除非所有子網域都確定支援 HTTPS。
預先載入 先不勾，除非確定要加入瀏覽器 HSTS preload list。
將 Http 重新導向至 Https 依現場規範決定是否啟用。
套用後重新啟動站台或 Application Pool。

設定完成後，再用 curl 驗證 HTTPS 回應是否有 Strict-Transport-Security header。

做法二：使用 web.config 加上 response header

如果無法使用 IIS 站台層 HSTS 設定，或設定後 HTTPS 回應仍沒有帶出 header，可以改用 web.config 作為備援方式。

這個方式是在網站根目錄的 web.config 裡，透過 customHeaders 補上 Strict-Transport-Security。

<httpProtocol>
  <customHeaders>
    <remove name="Strict-Transport-Security" />
    <add name="Strict-Transport-Security" value="max-age=31536000" />
  </customHeaders>
</httpProtocol>

<httpProtocol>
  <customHeaders>
    <remove name="Strict-Transport-Security" />
    <add name="Strict-Transport-Security" value="max-age=31536000" />
  </customHeaders>
</httpProtocol>

建議放在 system.webServer 區塊內，通常可放在既有站台設定後方、</system.webServer> 前方。

如果 IIS 站台層已經成功設定 HSTS，就不要再用 web.config 加一次，避免重複 header。

驗證方式

不論採用 IIS 站台層設定，或 web.config 備援設定

最後都要用 HTTPS 網址驗證：

curl.exe -k -I https://你的位置/path

curl.exe -k -I https://你的位置/path

回應中只要有以下 header，就代表 HSTS 已經生效：

Strict-Transport-Security: max-age=31536000

此時即可重新進行弱點掃描確認。

實務上判斷

HSTS Missing From HTTPS Server 的重點不是網站能不能開 HTTPS，而是 HTTPS 回應是否有宣告 HSTS 政策。

它要解決的是使用者第一次或後續誤走 HTTP 時，可能被中間人攔截或降級連線的風險。

在 IIS 環境中，建議先使用站台層 HSTS 設定

如果站台層無法使用或驗證無效，再用 web.config 補 response header。

完成後用 curl 檢查 HTTPS 回應是否包含 Strict-Transport-Security，即可確認修正是否有效。

Contents