HTML 编码可以防止各种 XSS 攻击吗？

https://stackoverflow.com/questions/53728

09-06-2019
|

题

我不担心其他类型的攻击。只是想知道HTML Encode是否可以防止各种XSS攻击。

即使使用 HTML 编码，是否有某种方法可以进行 XSS 攻击？

解决方案

不。

抛开允许某些标签的主题（这并不是问题的重点），HtmlEncode 根本不涵盖所有 XSS 攻击。

例如，考虑服务器生成的客户端 javascript - 服务器动态地将 htmlencoded 值直接输出到客户端 javascript，htmlencode 将 不停止 执行注入的脚本。

接下来，考虑以下伪代码：

<input value=<%= HtmlEncode(somevar) %> id=textbox>

现在，如果它不是很明显，如果 somevar （当然由用户发送）设置为

a onclick=alert(document.cookie)

结果输出是

<input value=a onclick=alert(document.cookie) id=textbox>

这显然会起作用。显然，这可以是（几乎）任何其他脚本......和 HtmlEncode 没有多大帮助。

还有一些额外的向量需要考虑......包括第三种类型的 XSS，称为基于 DOM 的 XSS（其中恶意脚本是在客户端动态生成的，例如基于 # 个值）。

另外不要忘记 UTF-7 类型的攻击 - 攻击看起来像

+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-

那里没什么可编码的......

当然，解决方案（除了适当和限制性的白名单输入验证之外）是执行 上下文相关的 编码：如果您的输出上下文是 HTML，或者您可能需要 JavaScriptEncoding、VBScriptEncoding、AttributeValueEncoding，或者...，HtmlEncoding 非常有用。ETC。

如果您使用的是 MS ASP.NET，则可以使用他们的 Anti-XSS 库，它提供了所有必要的上下文编码方法。

请注意，所有编码不应仅限于用户输入，还应包括数据库、文本文件等中的存储值。

哦，不要忘记在 HTTP 标头和 META 标记中显式设置字符集，否则您仍然会遇到 UTF-7 漏洞...

更多信息和相当明确的列表（不断更新），请查看 RSnake 的备忘单： http://ha.ckers.org/xss.html

其他提示

如果您在显示之前对所有用户输入进行系统编码 ~~那么是的，你安全了~~ 你仍然不是 100% 安全。
（有关更多详细信息，请参阅@Avid 的帖子）

此外，当您需要让一些标签未编码，以便您允许用户发布图像或粗体文本或任何需要将用户输入处理为（或转换为）未编码标记的功能。

你必须建立一个决策系统来决定哪些标签是允许的，哪些是不允许的，并且总是有可能有人会想出一种方法让不允许的标签通过。

如果你遵循乔尔的建议，这会有所帮助让错误的代码看起来错误或者如果你的语言可以帮助你当您输出未处理的用户数据（静态类型）时，通过警告/不编译。

如果你对所有内容进行编码，它就会编码。（取决于您的平台和 htmlencode 的实现）但是任何有用的 Web 应用程序都非常复杂，以至于很容易忘记检查它的每个部分。或者第三方组件可能不安全。或者也许您执行编码的某些代码路径并未执行此操作，因此您将其忘记在其他地方。

所以你可能还想检查输入端的东西。您可能想检查从数据库中读取的内容。

正如其他人提到的，只要您编码，您就是安全的全部显示之前的用户输入。这包括所有请求参数和从数据库检索的可以通过用户输入更改的数据。

作为帕特提到的有时您会想要显示一些标签，而不是所有标签。一种常见的方法是使用标记语言，例如纺织品, 降价, ，或者 BB代码. 。然而，即使是标记语言也可能容易受到 XSS 攻击，请注意。

# Markup example
[foo](javascript:alert\('bar'\);)

如果您确实决定让“安全”标签通过，我建议您在输出之前找到一些现有的库来解析和清理您的代码。有很多 XSS 向量在你的消毒剂相当安全之前，你必须检测到这一点。

我赞同 metavida 的建议，即寻找第三方库来处理输出过滤。中和 HTML 字符是阻止 XSS 攻击的好方法。然而，用于转换元字符的代码可能容易受到逃避攻击；例如，如果它不能正确处理 Unicode 和国际化。

自制输出过滤器犯的一个典型的简单错误是只捕获 < 和 >，但错过了诸如 " 之类的东西，它可以将用户控制的输出分解到 HTML 标签的属性空间中，其中 Javascript 可以附加到 DOM。

不，仅对常见的 HTML 令牌进行编码并不能完全保护您的网站免受 XSS 攻击。例如，请参阅 google.com 中发现的 XSS 漏洞：

http://www.securiteam.com/securitynews/6Z00L0AEUE.html

关于此类漏洞的重要一点是，攻击者能够使用 UTF-7 对其 XSS 有效负载进行编码，并且如果您没有在页面上指定不同的字符编码，则用户的浏览器可以解释 UTF-7 有效负载并执行攻击脚本。

您需要检查的另一件事是您的输入来自哪里。您可以使用引荐来源网址字符串（大多数情况下）来检查它是否来自您自己的页面，但是在表单中放入隐藏的随机数或其他内容，然后检查它（可能使用会话集变量）也有助于了解输入来自您自己的网站，而不是某个网络钓鱼网站。

我想推荐 HTML Purifier (http://htmlpurifier.org/）它不只是过滤 html，它基本上是对其进行标记并重新编译。这是真正的工业实力。

它还有一个额外的好处，可以让您确保有效的 html/xhtml 输出。

还有 n'thing 纺织，它是一个很棒的工具，我一直使用它，但我也会通过 html 净化器运行它。

我认为您不明白我的意思是重新标记。HTML Purifier 不只是“过滤”，它实际上重建了 html。 http://htmlpurifier.org/comparison.html

我不相信是这样。Html Encode 将所有功能字符（可以被浏览器解释为代码的字符）转换为无法被浏览器解析并因此无法执行的实体引用。

&lt;script/&gt;

浏览器无法执行上述内容。

**当然，除非它们是浏览器中的错误。*

许可以下： CC-BY-SA 和归因

不隶属于 StackOverflow