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