可以通过更改语言编码来引入XSS吗？

假设我有一个使用Latin1或某种默认英语编码的Web应用程序。我想要将应用程序更改为使用UTF-8或其他语言编码。你能否证明这个改变会引入XSS？可以通过更改语言编码来引入XSS吗？

这不是一个PHP的具体问题，但在PHP中可以显示一个案例，其中htmlspecialchars($var,ENT_QUOTES);容易受到XSS的影响，而htmlspecialchars($var,ENT_QUOTES,'UTF-8');则不是。

来源

2011-01-07 rook

从RFC 3629：

10.安全考虑

的UTF-8需要实施者考虑他们如何处理非法的UTF-8序列的安全方面。它是可以想象，在某些情况下，攻击者通过发送一个不是由UTF-8语法允许的不是的八位字节序列，就能够利用不谨慎的UTF-8解析器。

特别微妙此攻击的形式可以针对解析器执行安全关键的有效性检验针对其输入的UTF-8编码的形式来进行，但解释某些非法八位位组序列为字符。对于例如，当作为单八位组序列00编码的解析器可能禁止 NUL字符，但错误地允许非法两个八位字节序列C0 80和解释它作为一个NUL字符。另一个例子可能是解析器，它禁止八位位组序列2F 2E 2E 2F（“/../”），但允许非法的八位位组序列2F C0 AE 2E 2F。这最后的利用实际上已被用于广泛的病毒在2001年攻击Web 服务器;因此，安全威胁是非常真实的。

因此，确定您的数据是有效的UTF-8至关重要。

但是一旦你完成了这个工作，与编码相关的安全问题就会变得很小。所有的HTML特殊字符都是ASCII格式，ISO-8859-1等UTF-8格式完全兼容ASCII。 htmlspecialchars将按照您的预期行事。

对非ASCII兼容编码有更多关注。例如，在GB18030中，ASCII字节0x30及以上可能发生在多字节字符的编码中。 HYPHEN字符‐（U + 2010）编码为A9 5C，其中包含ASCII反斜杠。这使得正确处理反斜杠转义变得更加困难，邀请SQL injection。

来源

2011-01-09 15:11:13 dan04

这是一个愚蠢的例子，通过误用htmlspecialchars从你的意图。

<?php 
$s = htmlspecialchars($_GET['x'], ENT_QUOTES); 
$s_utf8 = htmlspecialchars($_GET['x'], ENT_QUOTES, 'UTF-8'); 

if(!empty($s)) 
    print "default: " . $_GET['x'] . "<br>\n"; 

if(!empty($s_utf8)) 
    print "utf8: " . $_GET['x'] . "<br>\n" 
?>

提交任何XSS负载并添加无效的UTF-8字节，例如，对无效UTF-8字节序列

http://site/silly.php?x=<script>alert(0)</script>%fe

htmlspecialchars箍架和返回一个空字符串。打印$_GET值是一个明显的漏洞，但我确实有一点要说明。

简而言之，你将得到Latin1和UTF-8的逐字节检查，所以我不知道一个语言相关的例子，其中htmlspecialchars将在一个编码中错过危险字节，但不会另一个。

我的例子的要点在于，在更改编码方案时，您的问题更一般化（也可能有点太模糊）以适应XSS的危险。当内容开始处理不同的多字节编码时，开发人员可能会根据strchr(),strlen()或类似的检查来验证过滤器，这些检查不是多字节感知的，并且可能会受到有效载荷中％00的阻碍。（嘿，一些开发者仍然坚持使用正则表达式来解析和消毒HTML。）

原则上，我认为问题中的两个示例行在切换编码方面具有相同的安全性。在实践中，仍然有很多方法可以用模糊编码来弥补其他错误。

来源

2011-01-07 23:51:10 Mike

+1，很有意思。 – rook 2011-01-08 00:46:20

我想我可以提出的另一点是“知道你的错误处理” - 它可以非常棘手地处理无效的字节代码或被意外的行为感到惊讶。 – Mike 2011-01-08 10:22:43

可以通过更改语言编码来引入XSS吗？

回答

相关问题