Можно ли ввести XSS, изменив кодировку языка? - PullRequest
5 голосов
/ 07 января 2011

Допустим, у меня есть веб-приложение, которое использует Latin1 или некоторую кодировку по умолчанию на английском языке. Я хочу изменить приложение, чтобы использовать UTF-8 или, возможно, другую кодировку языка. Можете ли вы доказать , что это изменение представит XSS?

Это не специфический вопрос PHP, но в PHP вы можете показать случай, когда htmlspecialchars($var,ENT_QUOTES); уязвим для XSS, а htmlspecialchars($var,ENT_QUOTES,'UTF-8'); - нет.

Ответы [ 2 ]

4 голосов
/ 08 января 2011

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

В принципе, я думаю, что две строки примера в вопросе имеют одинаковую безопасность в отношении переключения кодирования.На практике все еще есть много способов сделать другие ошибки с неоднозначным кодированием.

1 голос
/ 09 января 2011

С 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. это последний подвиг был фактически использован в широко распространенный вирус, атакующий сеть серверы в 2001 г .; таким образом, безопасность угроза очень реальна.

Поэтому жизненно важно убедиться, что ваши данные являются действительными UTF-8.

Но как только вы это сделаете, проблемы безопасности, связанные с кодировкой, станут минимальными. Все специальные символы HTML находятся в ASCII, а UTF-8, такой как ISO-8859-1, полностью совместим с ASCII. htmlspecialchars будет вести себя так, как вы ожидаете.

Больше проблем с не-ASCII-совместимыми кодировками. Например, в GB18030 байты ASCII 0x30 и выше могут появляться в кодировке многобайтового символа. Символ HYPHEN (U + 2010) кодируется как A9 5C , что включает обратную косую черту ASCII. Это затрудняет правильную обработку экранирования от обратной косой черты, вызывая SQL-инъекцию .

...