Defaults.Exposed

Defaults.Exposed修復 › MIME 嗅探防護(X-Content-Type-Options)

如何修復 MIME 嗅探防護(X-Content-Type-Options)

一條簡單的回應標頭,阻止瀏覽器去猜測某個檔案到底是什麼。少了它,有人上傳到你網站的檔案——或你自己頁面上的檔案——可能被瀏覽器誤判並當作程式碼執行,而這正是某些攻擊把一個看似無害的上傳變成竊取客戶工作階段手段的方式。

對您業務的關鍵影響: 缺少這條回應標頭,是一個清晰、可被掃描出來的信號,說明基礎沒做到位。單憑它本身很少會讓網站癱瘓,但一旦配合檔案上傳表單或使用者產生的內容,它就為攻擊者打開了一條路:在訪客瀏覽器中執行惡意程式碼——劫持已登入工作階段、竊取刷卡或登入資訊,並把你推到資料洩露這場對話的被動一方。它是安全領域裡最便宜的修復之一:一行設定,免費,約五分鐘。

這會讓您付出什麼代價

為什麼它重要。 當伺服器對一個檔案是什麼含糊其辭時,瀏覽器會試圖去猜(嗅探)它的內容類型。攻擊者正是利用這種猜測:上傳一個被伺服器標為圖片的檔案,卻精心構造其內容,讓瀏覽器判定它實際是 JavaScript——並執行它。X-Content-Type-Options: nosniff 這條回應標頭告訴每個瀏覽器停止猜測、信任伺服器聲明的類型,從而堵住一整類伎倆。它是一項計 25 分的計分檢查,缺失時定為中等嚴重級。

給業主的簡短版

每個網頁瀏覽器裡都內建著一個不動聲色的假設:當它從你的網站下載一個檔案時,它會去判斷這是哪類檔案。通常它會信任你的伺服器。但如果你的伺服器含糊不清,瀏覽器就會去猜——這種猜測叫 MIME 嗅探。

問題在於,攻擊者能操縱這個猜測。他們可以構造一個檔案,讓你的伺服器真心相信它是一張無害的圖片,但瀏覽器在自行猜測時卻判定它其實是一段程式碼——然後就在你客戶的瀏覽器裡、在你的網域名稱下執行了它。

有一條單行指令可以關掉這種猜測:X-Content-Type-Options: nosniff。它告訴每個瀏覽器:別猜了——完全信任我伺服器告訴你的。這就是全部的修復。它免費,約五分鐘,在一個正確建置的網站上不會弄壞任何東西。

這項檢查就是在找這條回應標頭。如果它缺失,你會失去 25 分,並被定為中等嚴重級的問題——不是因為單憑這條回應標頭就是災難,而是因為它的缺失可靠地表明:基礎並未被鎖好。

這會讓你付出什麼代價

下面是真實、商業層面的場景——不是最壞情況的戲劇化渲染。

這些都不需要一個高深的攻擊者。MIME 嗅探濫用被充分研究、已被自動化——這正是為什麼掃描器對缺失的回應標頭標記得如此堅決。

它實際上是什麼

當瀏覽器收到一個檔案時,伺服器本應給它打上一個內容類型標籤(例如 PNG 圖片是 image/png,網頁是 text/html)。歷史上,瀏覽器並不完全信任這個標籤——部分原因是有些伺服器標錯了——所以它們會偷看檔案的實際位元組,自行判斷。這種偷看就是 MIME 嗅探。

它本是一種便利,卻變成了隱患。如果攻擊者能把一個檔案弄到你網站上(透過上傳表單、留言框、匯入的文件)並影響其內容,他們就能構造出一個被伺服器標得無害、卻被瀏覽器嗅探為可執行腳本的東西。瀏覽器隨後就在你的網域下、帶著你網域所擁有的全部信任,執行了它。

X-Content-Type-Options: nosniff 徹底消除了這種猜測。設定它之後,瀏覽器被告知:**使用伺服器聲明的類型,別無其他。**一個被標為圖片的檔案就當圖片處理,到此為止——哪怕它的內容看起來像腳本。攻擊路徑就此關閉。

**良好的狀態長什麼樣:**你網站的每個回應——頁面和資源一律如此——都帶著這一條回應標頭:

X-Content-Type-Options: nosniff

沒有別的有效取值,也沒什麼要調的。如果你的 CDN 和伺服器都加了它(於是你看到 nosniff, nosniff),這沒問題,仍算通過。

如何修復(免費,約 5 分鐘)

**把這一節交給負責你網站的人——你的 IT 人員、網頁開發人員或主機服務商。修復既免費又快;沒有任何東西要花錢買。**你要求的事很簡單:給網站上每個頁面和資源加上回應標頭 X-Content-Type-Options: nosniff

下面按常見平台給出細節。

Cloudflare(或類似的 CDN/代理)——往往是最快的地方,一次涵蓋全站:

Nginx——加在相關的 server(或 location)區塊內:

add_header X-Content-Type-Options "nosniff" always;

always 關鍵字確保它在錯誤回應上也會發送。儲存後重載 Nginx。

Apache——需啟用 mod_headers;在站點設定或 .htaccess 中:

Header always set X-Content-Type-Options "nosniff"

IIS / Windows 主機——在 web.config<system.webServer> 下:

<httpProtocol>
  <customHeaders>
    <add name="X-Content-Type-Options" value="nosniff" />
  </customHeaders>
</httpProtocol>

Node / Express——對每個回應都設定它:

app.use((req, res, next) => {
  res.setHeader('X-Content-Type-Options', 'nosniff');
  next();
});

(或使用 helmet 套件,它預設會設定這條以及其他幾個安全回應標頭。)

**Google Workspace / Microsoft 365 網站:**這些管理的是你的信箱和文件,不是你的公開網站主機,所以回應標頭不設在那裡——它要設在你網站本身實際提供服務的地方(你的 CDN、Web 伺服器或建站平台)。如果你用的是託管建站平台(Squarespace、Wix、Shopify 等),不少會自動替你加上這條回應標頭;與其假設,不如去核對結果,缺了就問他們的支援。

**部署後,驗證一下。**重新執行你的掃描,或讓開發人員在瀏覽器開發者工具裡檢查回應標頭(網路標籤頁 → 點任意請求 → 回應標頭),確認 X-Content-Type-Options: nosniff 存在。簡單測一下網站,確認沒有任何樣式或腳本壞掉——在一個正確建置的網站上,什麼都不會壞。

常見錯誤

把這一段交給你的 IT 人員

技術摘要:本檢查查驗 HTTP 回應標頭,當 X-Content-Type-Options 存在且其(不區分大小寫的)取值包含 nosniff 時通過——包括 CDN 與來源端都設定時的多源 nosniff, nosniff 情況。缺失或任何非 nosniff 的取值即不通過。它是一項計分的 P2 檢查,計 25 分,失敗時定為中等嚴重級,對應 OWASP Top 10 A05(安全設定錯誤)。補救措施是在所有回應上套用一條靜態回應標頭;沒有參數,也沒有有效的替代取值。在邊緣(CDN)設定以涵蓋全站,或在 Web 伺服器上以 always 語義設定,使其在錯誤回應上也會發出,然後在回應標頭中確認。

常見問題

我們不允許任何人上傳檔案。還需要這個嗎?

需要,而且仍然值得做。這條回應標頭是縱深防禦:它還能阻止瀏覽器誤讀你自己網站提供的腳本、樣式表和資料檔案,從而在沒有上傳表單的網站上也能抵禦幾種跨站腳本伎倆。它不花一分錢,而且在設定正確的網站上從不會出問題,所以沒理由略過。

加上這個會弄壞我網站上的東西嗎?

幾乎從不會。nosniff 只是讓瀏覽器尊重你伺服器本就發送的內容類型。它唯一可能惹麻煩的情況,是你的伺服器把檔案標錯了——比如把樣式表或腳本發成了錯誤的類型。如果真有東西壞了,那是 nosniff 暴露出來、而非造成的真實問題,本來就值得修。部署後測試一次即可。

良好的狀態到底長什麼樣?

每個頁面和資源上都有這一條回應標頭:X-Content-Type-Options: nosniff。這就是完整且正確的設定——沒有別的有效取值,也沒有什麼要調的。

我們的 CDN(Cloudflare 之類)和伺服器都加了它——這有問題嗎?

沒有。因為 CDN 和來源端都設定了它,所以看到該值出現兩次(nosniff, nosniff)完全沒問題,仍然算通過。你不需要去掉其中一個。

修這個要花錢嗎?

不要。修復只是在你 Web 伺服器或 CDN 上加一行免費設定。有誰為加一條回應標頭向你收費,那是漫天要價。這個領域裡真正值得付費的只有持續監控、跨多個網站的組合視圖,或一次正式稽核——而不是修復本身。

這跟內容安全策略(CSP)有什麼不同?

它們是互補的。CSP 控制哪些腳本和資源被允許載入;nosniff 則阻止瀏覽器對它確實載入的檔案做錯誤分類。兩者你都想要。nosniff 加起來簡單得多、快得多,所以是邁向完整 CSP 路上很好的第一步。