Может ли str_replace ('<') защитить нас от введенного пользователем кода?

Question

Хорошо, поэтому у меня есть некоторый пользовательский ввод, и я делаю echo str_replace('<', '&lt;', str_replace('&','&amp;',$_POST['input']));

Мне интересно, есть ли в любом случае пользователь может сломать этот фильтр?

Первоначально я думал, что этот скрипт довольно пуленепробиваемый, но я начал подозревать его надежность после прочтения некоторой статьи о php, наборах символов и безопасности.

Answer 1

Зависит от того, где заканчивается этот вход.

Например, если в какой-то момент вы столкнетесь с шаблоном, который (плохо) сконструирован следующим образом ...

<a href="<?php echo $somevar; ?>">a link</a>

Тогда кто-то может ввести код, просто используя следующий ввод:

javascript:do_whatever()

Даже если вывод обычно не отображается в поле href, что-то вроде этого ...

<a title="<?php echo $somevar; ?>" href="http://www.google.com">Google</a>

все еще может быть уязвимым, если ввод ...

" href="javascript:do_whatever()

Так что в основном ... фильтры должны быть чувствительны к контексту, в котором они используются. Обычно используемая функция - htmlspecialchars(), которая обрабатывает множество общих случаев.

Answer 2

Да.В некоторых многобайтовых наборах символов (наиболее заметным является UTF-7) есть и другие символы, которые можно использовать в качестве угловых скобок в html.

Кроме того, они не будут защищать атрибуты html, так как они могут внедрять JavaScriptс помощью цитаты.Итак, где бы вы ни делали:

<input value="<?= $replaced_value ?>" />

они могут передать значение

" onclick="alert(5)" x="

, что приведет к

<input value="" onclick="alert(5)" x="" />

Есть много разных способов, которымикто-то может использовать ваш код, если вы не используете правильные методы.Используя библиотеку кодирования OWASP Reform , вы можете кодировать все, что вам нужно.

Суть в том, что вы никогда не должны ни при каких обстоятельствах бросать свой собственный защитный код, если вам это абсолютно не нужно.Сторонние библиотеки, в которых несколько экспертов по безопасности потратили много времени на решение этой проблемы, - это лучшее, что вы можете сделать как с точки зрения эффективности, так и с точки зрения ответственности.

Answer 3

Быстрый взгляд на функцию htmlspecialchars() :

Выполнены следующие переводы:

'&' (ampersand) becomes '&'
'"' (double quote) becomes '"' when ENT_NOQUOTES is not set.
"'" (single quote) becomes ''' only when ENT_QUOTES is set.
'<' (less than) becomes '&lt;'
'>' (greater than) becomes '&gt;'

Итак, большойв том, что > недопустим в HTML, если он не является частью тега, но, вероятно, браузеры проигнорируют это.

Экранирование кавычек необходимо, если вы помещаете это в некоторые кавычки, например:

echo "<input name='x' value='" . htmlspecialchars($input) . "'/>";

Тем не менее, почему бы просто не использовать htmlspecialchars?