security - 是否可以通过改变语言编码来引入XSS？

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值(value)是一个明显的漏洞，但我确实有一个观点要说。

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

我的例子的要点是，您的问题对于更改编码方案时 XSS 的危险更为笼统(也许有点太模糊)。当内容开始处理不同的多字节编码时，开发人员可能会弄乱基于 strchr() 的验证过滤器。 , strlen() ，或不支持多字节的类似检查，并且可能会被有效负载中的 %00 阻止。 (嘿，一些开发人员仍然坚持使用正则表达式来解析和清理 HTML。)

原则上，我认为问题中的两个示例行在切换编码方面具有相同的安全性。在实践中，仍然有很多方法会因不明确的编码而犯其他错误。