%3Cscript%3Ealert%28123%29%3C%2Fscript%3E - это закодированная в URL форма <script>alert(123);</script>. Каждый раз, когда вы включаете < в значение формы, оно будет отправлено на сервер как %3C. PHP будет читать и декодировать это обратно до <, прежде чем что-либо в вашем приложении увидит это.
То есть, нет особой кодировки, которую вы должны обрабатывать; на самом деле вы не увидите %3C в своем вводе, вы увидите <. Если вам не удается закодировать это для отображения на странице, то у вас нет даже самых простых средств защиты от XSS.
Мы удалили большинство наших проблем с XSS. Мы разработали сайт с Zend. Мы добавляем фильтры StripTags, StringTrim и HtmlEntities к элементам формы заказа.
Боюсь, вы вообще не исправили свои проблемы с XSS. Возможно, вы их просто запутали.
Входная фильтрация - удручающе распространенная, но совершенно неправильная стратегия для блокировки XSS.
Проблема не во вводе. Как говорит ваш начальник, нет причины, по которой вы не сможете ввести O'Brien. Или даже <script>, как я только что в этом поле для комментариев. Вы не должны пытаться удалять теги во входных данных или даже кодировать их HTML, потому что кто знает во время ввода, что данные окажутся на HTML-странице? Вы не хотите, чтобы ваша база данных была заполнена бессмыслицей, такой как 'Fish&Chips', которая затем заканчивается в электронном письме или другом не HTML-контексте с странными HTML-выходами в нем.
HTML-кодирование - это проблема output-stage . Оставьте входящие строки в покое, сохраните их как необработанные строки в базе данных (конечно, если вы объединяете запросы в строках, чтобы поместить данные в базу данных вместо параметризованных запросов, вам нужно будет SQL-экранировать содержимое именно в этом месте. точка). Тогда только при вставке значений в HTML , кодируйте их:
Name: <?php echo htmlspecialchars($row['name']); ?>
Если у вас есть куча хитрого кода, например echo "Name: $name";, то, боюсь, вам придется много переписать, чтобы сделать его безопасным.
Подсказка: рассмотрите возможность определения функции с коротким именем, например h, чтобы вам не приходилось так много печатать htmlspecialchars. Не используйте htmlentities, который обычно излишне кодирует символы, не входящие в ASCII, что также приводит к их путанице, если вы не предоставите правильный $charset аргумент.
(или, если вы используете Zend_View, $this->escape().)
Проверка ввода полезна на уровне приложения, например, для обеспечения того, чтобы поля телефонных номеров содержали цифры, а не буквы. Это , а не , что вы можете применять глобально, чтобы избежать необходимости думать о проблемах, возникающих, когда вы помещаете строку в контекст другой строки - будь то внутри строковых литералов HTML, SQL, JavaScript или одного из многие другие контексты, которые требуют экранирования.