Если следующие утверждения верны,
Content-Type: text/html; charset=UTF-8 Content-Type: text/html; charset=UTF-8 . <script> . есть ли случаи, когда htmlspecialchars($input, ENT_QUOTES, 'UTF-8') (преобразование & , " , ' , < , > в соответствующие именованные объекты HTML) недостаточно для защиты от межсайтового скриптинга при создании HTML на веб-сервер?
htmlspecialchars() достаточно, чтобы предотвратить 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 является «безопасным» (и, конечно же, без учета внутреннего кода в качестве упоминаний @Royal Bg)
В более ранних версиях PHP были обнаружены некорректные символы UTF-8, которые сделали эту функцию уязвимой ( http://www.securityfocus.com/bid/37389 )
Мои 2 цента: просто всегда санируйте / проверяйте свои входы, рассказывая, что разрешено, вместо того, чтобы просто избегать всего / кодировать все
т.е. если кто-то должен ввести номер телефона, я могу представить, что допустимы следующие символы: 0123456789 () + -. и пространство, но все остальные просто игнорируются / удаляются
То же самое относится к адресам и т. Д. Кто-то, указывающий символы UTF-8 для точек / блоков / сердец и т. Д. В своем адресе, должен быть психически больным …
Насколько я знаю, да. Я не могу представить случай, когда он не избегает xss. Если вы хотите быть в полной безопасности, используйте strip_tags ()