Вот глупый пример, который обманывает, используя не по назначению 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.)
В принципе, я думаю, что две строки примера в вопросе имеют одинаковую безопасность в отношении переключения кодирования.На практике все еще есть много способов сделать другие ошибки с неоднозначным кодированием.