Question

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

这不是PHP特定的问题，但在PHP中，您可以展示htmlspecialchars($var,ENT_QUOTES);易受XSS攻击且htmlspecialchars($var,ENT_QUOTES,'UTF-8');不受攻击的情况。

Answer 1

这是一个愚蠢的例子，因为误用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字节，例如

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

htmlspecialchars对无效的UTF-8字节序列进行保释并返回空字符串。打印$_GET值是一个明显的漏洞，但我确实有一点要做。

简而言之，您将使用Latin1和UTF-8进行逐字节检查，因此我不知道一个语言相关的示例htmlspecialchars将错过一个编码中的危险字节，但不是另一个。

我的例子的一点是，在改变编码方案时，你的问题对于XSS的危险更为笼统（也许有点过于模糊）。当内容开始处理不同的多字节编码时，开发人员可能会根据strchr()，strlen()或类似的检查来清除验证过滤器，这些检查不是多字节感知的，并且可能被％00阻止在有效载荷中。（嘿，一些开发人员仍然坚持使用正则表达式来解析和清理HTML。）

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

Answer 2

来自RFC 3629：

<强> 10。安全注意事项

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

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

因此，确定您的数据有效的UTF-8非常重要。

但是一旦完成此操作，与编码相关的安全问题就很少了。所有HTML特殊字符均为ASCII，而ISO-8859-1等UTF-8完全与ASCII兼容。 htmlspecialchars将按照您的预期行事。

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

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

2 个答案: