При правильном использовании достаточно htmlspecialchars для защиты от всех XSS?

Если выполняются следующие утверждения:

  • Все документы подаются с заголовком HTTP Content-Type: text/html; charset=UTF-8.
  • Все атрибуты HTML заключены в одиночные или двойные кавычки.
  • В документе нет тегов <script>.

существуют ли случаи, когда htmlspecialchars($input, ENT_QUOTES, 'UTF-8') (преобразование &, ", ', <, > в соответствующие именованные объекты HTML) недостаточно для защиты от межсайтовых скриптов, когда создание HTML на веб-сервере?

Ответы

Ответ 1

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)

Ответ 2

Предполагая, что вы не используете более старые версии PHP (5.2 или около того), htmlspecialchars является "безопасным" (и, конечно же, с учетом кода backend в качестве упоминаний @Royal Bg)

В более ранних версиях PHP были обнаружены некорректные символы UTF-8, которые сделали эту функцию уязвимой (http://www.securityfocus.com/bid/37389)

Мои 2 цента: просто всегда санируйте/проверяйте свои входы, сообщая, что разрешено, а не просто избегайте всего/кодирования всего.

то есть. если кто-то должен ввести номер телефона, я могу представить, что допустимы следующие символы: 0123456789() + -. и пробел, но все остальные просто игнорируются/удаляются

То же самое относится к адресам и т.д. кто-то, указывающий символы UTF-8 для точек/блоков/сердец и т.д. в своем адресе, должен быть психически больным...

Ответ 3

Как упоминал @Ronald Swets, вам лучше санировать ваш ввод, так как санирование - это комбинация экранирования, фильтрации и проверки, которая гарантирует, что вход в системную функцию не вызовет неожиданного и несанкционированного поведения.

http://php.net/manual/fr/filter.filters.sanitize.php

Ответ 4

Насколько я знаю, да. Я не могу представить случай, когда он не избегает xss. Если вы хотите быть в полной безопасности, используйте strip_tags()