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

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

解决方案

回答

我不相信Html Encode将所有功能字符(可被浏览器解释为代码的字符)转换为实体引用，这些引用不能被浏览器解析，因此无法执行。

<script/>

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

*除非它们是课程浏览器中的错误。

回答

如果对所有内容进行编码，它将进行编码。 (取决于平台和htmlencode的实现)，但是任何有用的Web应用程序都非常复杂，以至于很容易忘记检查它的每个部分。或者，第三方组件并不安全。或者，也许我们虽然进行了编码的某些代码路径却没有做到这一点，但我们却在其他地方忘记了它。

因此，我们可能也想在输入端检查一下。我们可能想检查从数据库中读取的内容。

回答

如果在显示之前系统地对所有用户输入进行编码，那么可以，那么我们仍然不是100％安全的。
(有关更多详细信息，请参见@Avid的帖子)

另外，当我们需要让一些标签不进行编码时，还会出现问题，以便允许用户发布图像或者粗体文本，或者要求将用户输入作为(或者转换为)未编码标记的任何功能。

我们将必须建立一个决策系统来决定允许哪些标签和哪些不允许，并且总是有可能有人会找到一种方法来允许不允许的标签通过。

如果我们遵循Joel的"使错误的代码看起来错误"的建议，或者在输出未处理的用户数据(静态键入)时语言通过警告/不编译来，则它会有所帮助。

回答

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

正如Pat所提到的，我们有时会希望显示一些标签，而并非所有标签。一种常见的实现方法是使用标记语言，例如Textile，Markdown或者BBCode。但是，请注意，即使标记语言也可能容易受到XSS的攻击。

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

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

回答

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

自制程序输出过滤器的一个典型的简单错误就是仅捕获<和>，但是错过了诸如"之类的东西，它可能会将用户控制的输出分解为HTML标记的属性空间，而Javascript可以添加到DOM。

回答

不。

撇开允许使用某些标签的主题(实际上并不是问题的重点)，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，则HtmlEncoding很棒，或者我们可能需要JavaScriptEncoding，VBScriptEncoding或者AttributeValueEncoding或者...等。

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

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

哦，别忘了在HTTP标头和META标签中显式设置字符集，否则我们仍然会遇到UTF-7漏洞...

有关更多信息以及完整的清单(不断更新)，请查看RSnake的备忘单：http://ha.ckers.org/xss.html

回答

我想建议HTML Purifier(http://htmlpurifier.org/)它不仅过滤html，而且基本上将其标记化并重新编译。这是真正的工业实力。

它具有允许我们确保有效的html / xhtml输出的其他好处。

同样是纺织，它是一个很棒的工具，我一直都在使用它，但是我也会通过html purifier运行它。

我认为我们不理解我所说的重新令牌。 HTML Purifier不仅仅是"过滤器"，它实际上是在重建html。 http://htmlpurifier.org/comparison.html

回答

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

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

此类漏洞的重要之处在于，攻击者能够使用UTF-7对XSS有效载荷进行编码，并且如果我们在页面上未指定其他字符编码，则用户的浏览器可以解释UTF-7有效载荷，并且执行攻击脚本。

回答

我们需要检查的另一件事是输入来自何处。我们可以使用引荐来源网址字符串(大多数情况下)来检查它是否来自我们自己的页面，但是在表格中放入隐藏的随机数或者其他内容，然后对其进行检查(可能带有会话集变量)也可以了解输入来自我们自己的网站，而不是某些网络钓鱼网站。