Question

在HTML中，有几个特殊字符< > & ' "对DOM解析器有意义。这些是流行函数的字符，例如PHP的htmlspecialchars转换为HTML实体，因此它们在解析时不会意外触发。

执行的翻译是：


'＆安培;' （＆符号）变为&

"（双引号）变为"   当没有设置ENT_NOQUOTES时。

'（单引号）仅变为'   设置ENT_QUOTES时。

'＆LT;' （小于）变为<

'＆GT;' （大于）变为>

但是，我记得在IE6等旧浏览器中，还有其他字节序列导致浏览器的DOM解析器interpret content as HTML。

今天这仍然是一个问题吗？如果单独过滤这些5就足以阻止XSS了？

例如，以下是字符“＆lt;”的所有已知组合在HTML和JavaScript（UTF-8）中。

<
%3C
&lt
&lt;
&LT
&LT;
&#60
&#060
&#0060
&#00060
&#000060
&#0000060
&#60;
&#060;
&#0060;
&#00060;
&#000060;
&#0000060;
&#x3c
&#x03c
&#x003c
&#x0003c
&#x00003c
&#x000003c
&#x3c;
&#x03c;
&#x003c;
&#x0003c;
&#x00003c;
&#x000003c;
&#X3c
&#X03c
&#X003c
&#X0003c
&#X00003c
&#X000003c
&#X3c;
&#X03c;
&#X003c;
&#X0003c;
&#X00003c;
&#X000003c;
&#x3C
&#x03C
&#x003C
&#x0003C
&#x00003C
&#x000003C
&#x3C;
&#x03C;
&#x003C;
&#x0003C;
&#x00003C;
&#x000003C;
&#X3C
&#X03C
&#X003C
&#X0003C
&#X00003C
&#X000003C
&#X3C;
&#X03C;
&#X003C;
&#X0003C;
&#X00003C;
&#X000003C;
\x3c
\x3C
\u003c
\u003C

Answer 1

没有。当我研究使用CSS和属性来自动根据内容（my question）分配样式时，我实际上研究了这个，简短的答案是否定的。现代浏览器不允许将“字节序列”用作HTML。我轻易使用'字节序列'，因为风险最大的代码不使用字节编码值。

XSS网站上列出的示例是关于使用属性并将javascript解释为需要执行的字符串。但是也列出了像&{alert('XSS')}这样的东西，它在括号内运行代码，并且该代码在现代浏览器中不起作用。

但是要回答你的第二个问题，不，过滤那些5并不足以阻止 XSS攻击。通过PHP HTML特殊字符代码抛出您的代码，但有一个hundreds of byte codes that can be used，您实际上无法保证任何东西。通过PHP过滤器（特别是htmlentities()）发送它将为您输入输出到HTML（IE «而不是«）时输入的确切文本。也就是说，在大多数情况下，根据您的使用情况，使用htmlspecialchars足以涵盖大多数攻击。取决于您将如何使用输入，但在大多数情况下它将是安全的。

XSS是一个棘手的问题。一般规则总是过滤用户将输入的所有内容。并使用白名单而不是黑名单。你在这里谈论的将是黑名单这些价值观，当假设你的用户是恶意的并且只允许某些事情总是更安全的时候。

Answer 2

这是一个例子： <button onclick="confirm('Are you sure you want to delete ');alert('xss')> 攻击者输入的内容是“删除”之后和“）＆gt;

之前的内容

这种转义在这种情况下不起作用，因为我们逃脱了错误的上下文。

简而言之，xss预防意味着逃避给定的上下文。在上面的示例中，我们处于HTML属性上下文中的javascript上下文中。参见OWASP XSS预防备忘单。

Answer 3

在HTML中转义文本就足够了，但HTML中有一些上下文甚至文本都很危险：

不允许用户创建任意网址（<a>，<img>等），因为他们可以插入javascript:或其中的多种变体。仅列入白名单^https?://。
HTML转义在<script>（它无论如何都使用实体转义）或执行脚本（onclick等）的属性中都不够。对于那些您需要json_encode()。

是否有其他序列浏览器解释为HTML特殊字符？

3 个答案: