依赖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'不应处理指令类型，并且简单地看作是线性字符序列。