依賴Content-Type：text / plain來緩解惡意javascript執行是否安全？

Question

我們有一個返回的Web應用程序

---

HTTP/1.1 400 Bad Request
...
Content-Type: text/plain;charset=UTF-8
Content-Length: 57
Date: Tue, 14 Apr 2015 19:24:54 GMT
Connection: close

Invalid project area item id 

<script>alert(1086)</script>

---

我的理解是依賴Content-Type：text / plain; charset = UTF-8作為防止javascript執行的防御是不夠的。 相反，輸出應該被編碼，並且輸入應該被輸入驗證並且垃圾被拋出。

我正在尋找的是關於處理具有javascript的響應的正確方法的一些清晰和正式的答案，其中Content-Type已被設置為text / plain。

任何人都有這個場景的官方示例的鏈接（或答案）和處理它的正確方法？ 或者是Content-Type：text / plain; charset = UTF-8需要什么？

Answer 1

這是兩個場景。

頂級XSS

如果攻擊者可以操縱頂級URL來響應格式錯誤的請求，例如

HTTP/1.1 400 Bad Request
...
<script>alert(document.cookie)</script>

然后設置Content-Type: text/plain 減輕 XSS攻擊（參見下面的詳細答案）。

AJAX XSS

但是，如果攻擊者可以操縱目標網頁中的某些AJAX函數並欺騙它執行類似$("#result").html(xss_request_result)那么它會有效地將文本加載到Web上下文中，並且它將被解析為瀏覽器（包括JS）， 所有的賭注都關閉了 。

對這些錯誤消息的響應進行實體編碼或標記剝離是明智的。

---

關於第一種情況，根據w3.org ，

文本的主要子類型是“普通”。 這表示普通（未格式化）文本。 Internet郵件的默認Content-Type，“text / plain; charset = us-ascii”，描述了現有的Internet實踐，也就是說，它是RFC 822定義的主體類型。

這意味着不應解釋text / plain，也不應處理。 但是， Google （2011年3月30日更新）聲明，

如果Content-Type匹配其中一個通用值，例如application / octet-stream，application / unknown，甚至text / plain ，許多瀏覽器會將此視為根據上述信號對值進行二次猜測的權限，並嘗試想出更具體的東西。 此步驟的基本原理是，一些配置不當的Web服務器會在所有返回的內容上回退到這些類型。

根據對瀏覽器嗅探的調查，題為“ 是否在文本/普通文檔上嗅探HTML”（URL中是否有文件擴展名）？ ，結果是：

• Internet Explorer 9+：沒有
• FireFox：沒有
• 歌劇院：沒有
• Chrome：沒有
• Android：沒有
• Safari： 是的

所以，是的，使用顯式字符集設置將內容類型設置為text / plain將減輕XSS攻擊，但從上述調查中，Safari可能是一個支持。

測試瀏覽器是否存在此漏洞。 轉到更慷慨的在線PHP小提琴網站（例如http://phptester.net/ ）並執行以下操作。 你不應該得到一個彈出窗口。

<?php
header("Content-Type: text/plain");
echo "<script>alert(1)</script>";

---

關於內容嗅探XSS攻擊的更多閱讀（PDF）

Answer 2

德雷克斯回答上面困擾我，所以我創建了一個簡單的概念證明，看看我是否正確。 我是。 即使使用Content-Type: text/plain;charset=UTF-8 ，也可以通過簡單的XSS攻擊來破壞應用程序。

正如我第一次嘗試在下面解釋的那樣，原因在於數據處理是重要的，以及數據的最終目標和渲染上下文。 運輸不是那么重要。 我創建了一個簡單的servlet，它返回一個與OP類似的響應，包括Content-Type標頭。 這是響應：

HTTP/1.1 400 Bad Request
Server: Apache-Coyote/1.1
Cache-Control: no-cache
Content-Type: text/plain;charset=UTF-8
Content-Length: 73
Date: Thu, 18 Jun 2015 22:49:01 GMT
Connection: close


Invalid project area item id <iframe src=javascript:alert(1)></iframe> 

這是結果的圖像。 請注意，執行了攻擊有效負載： https ： //flic.kr/p/uRnSgo

再一次，原因很簡單。 數據不是在AJAX請求中呈現，而是在消費Web應用程序頁面中呈現，這是一個HTML頁面。

無論如何，我希望在某些情況下消除對易受攻擊的任何疑問......特別是當響應是一個將在消費頁面中呈現的AJAX請求時。

-----以下是我原來的回復。 -----

帶有錯誤消息的400響應有點像我的REST API響應。

如果這是一個REST請求（請求標頭中的X-Requested-With: XMLHttpRequest或Accept: application/json ），那么您將遇到嚴重問題。 雖然此響應不受影響，但數據可能會被消費頁面拾取並顯示在最終用戶的UI中。 由於它不正確編碼， 它將執行。 您不必擔心這個響應，但最終會對攻擊有效負載進行處置。 假設這是對XMLHttpRequest或REST調用的響應，這是一個嚴重的錯誤。

您可以使用<iframe src=javascript:alert(1)></iframe>的攻擊負載進行測試，我打賭您會在使用的應用程序中看到該彈出窗口。

我建議： Invalid project area item id無效，並忽略無效值。 最便宜的解決方案

所以，不，你通常不能依靠Content-Type來拯救你。 數據可以顯示在將執行的另一個上下文中。

始終驗證輸入並正確處理輸出，這可能包括某種格式或其他格式的編碼，具體取決於它將在其中呈現的上下文。 任何告訴你的人都試圖擺脫一些必要的工作。 :-)

Answer 3

https://tools.ietf.org/html/rfc2046'text / plain'不應處理指令類型，並且簡單地看作是線性字符序列。