Если выполняются следующие утверждения:
Content-Type: text/html; charset=UTF-8.<script>.существуют ли случаи, когда htmlspecialchars($input, ENT_QUOTES, 'UTF-8') (преобразование &, ", ', <, > в соответствующие именованные объекты HTML) недостаточно для защиты от межсайтовых скриптов, когда создание HTML на веб-сервере?
htmlspecialchars() достаточно, чтобы предотвратить вставку HTML-версии документа с ограничениями, которые вы указали (т.е. не вставлять в содержимое тега/некотируемый атрибут).
Однако есть и другие виды инъекций, которые могут привести к XSS и:
В документе нет тегов <script> .
это условие не распространяется на все случаи инъекции JS. Например, у вас может быть атрибут обработчика событий (требуется JS-экранирование внутри HTML-экранирования):
<div onmouseover="alert('<?php echo htmlspecialchars($xss) ?>')"> // bad!
или, что еще хуже, ссылка javascript: (требуется JS-экранирование внутри URL-экранирования внутри HTML-экранирования):
<a href="javascript:alert('<?php echo htmlspecialchars($xss) ?>')"> // bad!
Как правило, лучше избегать этих конструкций, но особенно при шаблонизации. Написание <?php echo htmlspecialchars(urlencode(json_encode($something))) ?> довольно утомительно.
И... проблемы с инъекциями могут возникать и на стороне клиента (DOM XSS); htmlspecialchars() не защитит вас от куска написания JavaScript на innerHTML (обычно .html() в бедных сценариях jQuery) без явного экранирования.
И... XSS имеет более широкий диапазон причин, чем просто инъекции. Другие распространенные причины:
позволяет пользователю создавать ссылки, не проверяя известные схемы URL (javascript: - самая известная вредная схема, но есть больше)
преднамеренно позволяет пользователю создавать разметку либо напрямую, либо через схемы легкой маркировки (например, bbcode, который неизменно используется)
позволяет пользователю загружать файлы (которые могут различными способами интерпретироваться как HTML или XML)
Предполагая, что вы не используете более старые версии PHP (5.2 или около того), htmlspecialchars является "безопасным" (и, конечно же, с учетом кода backend в качестве упоминаний @Royal Bg)
В более ранних версиях PHP были обнаружены некорректные символы UTF-8, которые сделали эту функцию уязвимой (http://www.securityfocus.com/bid/37389)
Мои 2 цента: просто всегда санируйте/проверяйте свои входы, сообщая, что разрешено, а не просто избегайте всего/кодирования всего.
то есть. если кто-то должен ввести номер телефона, я могу представить, что допустимы следующие символы: 0123456789() + -. и пробел, но все остальные просто игнорируются/удаляются
То же самое относится к адресам и т.д. кто-то, указывающий символы UTF-8 для точек/блоков/сердец и т.д. в своем адресе, должен быть психически больным...
Как упоминал @Ronald Swets, вам лучше санировать ваш ввод, так как санирование - это комбинация экранирования, фильтрации и проверки, которая гарантирует, что вход в системную функцию не вызовет неожиданного и несанкционированного поведения.
Насколько я знаю, да. Я не могу представить случай, когда он не избегает xss. Если вы хотите быть в полной безопасности, используйте strip_tags()