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或…等。

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

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

哦,别忘了在HTTP头和meta标签中显式地设置字符集,否则您仍然会有utf-7漏洞…

更多信息,以及相当明确的列表(不断更新),请查看rsnake的备忘表: http://ha.ckers.org/xss.html

如果在显示前对所有用户输入进行系统编码 那么是的,你很安全 你仍然不是百分之百的安全。
(详情请参见@avid's post)

此外,当你需要 一些 标签将被取消编码,这样您就可以允许用户发布图像、粗体文本或任何需要用户输入的功能作为(或转换为)未编码的标记进行处理。

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

如果你听从乔尔的建议 Making Wrong Code Look Wrong 或如果 your language helps you 通过在输出未处理的用户数据(静态键入)时发出警告/不编译。

如果你把所有的东西都编码了。(取决于您的平台和htmlencode的实现)但是任何有用的Web应用程序都是如此复杂,以至于很容易忘记检查它的每个部分。或者第三方组件不安全。或者可能是一些编码时使用的代码路径没有做到这一点,所以你把它忘在了其他地方。

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

正如其他人所说,只要你编码,你就安全了。 全部的 显示前的用户输入。这包括所有请求参数和从数据库中检索到的可由用户输入更改的数据。

AS mentioned by Pat 有时您会希望显示一些标记,而不是所有标记。一种常见的方法是使用标记语言 Textile , Markdown 或 BBCode . 但是,即使标记语言也可能容易受到XSS的攻击,请注意。

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

如果您决定让“安全”标签通过,我建议您查找一些现有的库,以便在输出前分析和清理代码。有 a lot of XSS vectors 在你的消毒液相当安全之前,你必须先检测出来。

我建议第二个metavida找到第三方库来处理输出过滤。中和HTML字符是阻止XSS攻击的好方法。但是,用于转换元字符的代码可能容易受到规避攻击;例如,如果它不能正确处理Unicode和国际化。

自制输出过滤器所犯的一个典型的简单错误是只捕获<和>,但忽略了类似这样的事情,这会将用户控制的输出分解为HTML标记的属性空间,在该空间中可以将javascript附加到DOM。

不,仅仅编码普通的HTML令牌并不能完全保护您的站点免受XSS攻击。例如,请参见google.com中发现的XSS漏洞:

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

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

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

我想推荐HTML净化器( http://htmlpurifier.org/ )它不只是过滤HTML,它基本上是标记化并重新编译它。这是真正的工业实力。

它还有一个额外的好处,可以确保有效的HTML/XHTML输出。

另外,纺织,它是一个伟大的工具,我一直使用它,但我会运行它虽然HTML净化器。

我觉得你不明白我的意思是代币。HTML净化器不仅仅是“过滤”,它还可以重建HTML。 http://htmlpurifier.org/comparison.html

我不相信。HTML Encode将中的所有功能字符(浏览器可以将其解释为代码的字符)转换为浏览器无法分析因而无法执行的实体引用。

<script/>

浏览器无法执行上述操作。

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