Я ищу лучшие практики для выполнения строгой (белый список) проверки / фильтрации HTML-кода, отправленного пользователем.
Основная цель - отфильтровать XSS и подобные гадости, которые могут быть введены через веб-формы. Вторичная цель - ограничить повреждение HTML-контента, введенного нетехническими пользователями, например. через редактор WYSIWYG, имеющий представление HTML.
Я рассматриваю возможность использования Очиститель HTML или собственного использования с помощью парсера HTML DOM для прохождения процесса вроде HTML (грязный) -> DOM (грязный) -> фильтр-> DOM (чистый) -> HTML (чистый).
Можете ли вы описать успехи этих или каких-либо более простых стратегий, которые также эффективны? Какие ловушки нужно остерегаться?






Отправленный пользователем HTML не всегда действителен или действительно не полон. Браузеры будут интерпретировать широкий спектр недопустимого HTML, и вы должны убедиться, что вы можете его поймать.
Также обратите внимание на выглядящие корректно:
<img src = "http://www.mysite.com/logout" />
и
<a href = "javascript:alert('xss hole');">click</a>
Первый пример (который является ссылкой на статью codinghorror: codinghorror.com/blog/archives/001171.html) на самом деле не актуален, поскольку «дыра» зависит от природы этого URL-адреса, а не от синтаксиса этого конкретного фрагмента HTML.
Есть еще полезные правила, которые можно применить к первому, например, "разрешить тег <img> только тогда, когда атрибут src совпадает с регулярным выражением /^http://localsite.com/uploaded_images/[\w- ] * \. (png | jpg | gif) $ / i ".
У W3C есть большой пакет с открытым исходным кодом для проверки HTML, доступный здесь:
Вы можете скачать пакет для себя и, вероятно, реализовать то, что они делают. К сожалению, похоже, что многие парсеры DOM, похоже, готовы изменить правила, чтобы выделить для HTML-кода «в дикой природе», так что неплохо позволить мастерам сказать вам, что не так, и не оставлять это на усмотрение более практичный инструмент - существует множество веб-сайтов, на которых не является идеальным, совместимым с HTML, но которые мы по-прежнему используем каждый день.
Валидация против DTD вообще не защищает от XSS.
Точно, я не думаю, что Барри имел в виду валидацию - подумайте о проверке или проверке данных, а не о проверке стандартов. Это поможет против искаженного HTML;)
Я протестировал все известные мне эксплойты на HTML Purifier, и он очень хорошо себя показал. Он фильтрует не только HTML, но также CSS и URL-адреса.
Как только вы сузите элементы и атрибуты до невинных, подводные камни будут в содержимом атрибута - псевдо-URL javascript: (IE допускает символы табуляции в имени протокола - java	script: все еще работает) и свойствах CSS, запускающих JS.
Разбор URL-адресов может быть сложным, например они действительны: http://spoof.com:[email protected] или //evil.com.
Интернационализированные домены (IDN) могут быть записаны двумя способами - Unicode и punycode.
Пойдите с Очиститель HTML - он сработал большинство из них. Если вы просто хотите исправить сломанный HTML, используйте HTML Tidy (он доступен как расширение PHP).
Оказалось, что в 2008 году было далеко не безопасно, эти эксплойты были обнаружены в 2011 году: secunia.com/advisories/43907, 2010: secunia.com/advisories/39613 Урок: обязательно обновляйте установку фильтра.
Я успешно использовал HTML Purifier, и у меня не было никаких xss или других нежелательных входных фильтров. Я также запускаю дезинфицирующий HTML-код через расширение Tidy, чтобы убедиться, что он также проходит проверку.
Спасибо Росс, это отличные примеры входных данных, которые следует отфильтровать. Но ответ, который я ищу, также будет включать методы и решения.