Comments 34
исключительно для проверки входящих данных от потенциально опасных посетителей
по какому критерию вы собираетесь разделять ваших посетителей на опасных и не очень?
В идеале разыскивается простая и быстрая функция, которая могла бы четко выполнить фильтрацию XSS атак.
htmlspecialchars() ;)
А если получится один раз при входе все проверить и зачистить, то зачем тогда при каждом выводе перепроверять?
То что текст на входе может содержать неправильное HTML (незакрытый тег например) может испортить вид страницы — это действительно проблема.
Спасибо что обратили мое внимание на это.
Спасибо что обратили мое внимание на это.
А если не получится. Сегодня у вас одни правила обработки, завтра другие.
Правила изменились, контент уже в базе, если вы применяете свои фильты/обработчике при выводе то новый и старый контент будет обрабатываться одинаково.
Правила изменились, контент уже в базе, если вы применяете свои фильты/обработчике при выводе то новый и старый контент будет обрабатываться одинаково.
Задача: обезопасить ввод с WYSIWYG редакторов.
Когда возможности ограничены то Вы полностью правы достаточно проверить на допустимость теги и их атрибуты.
А если WYSIWYG с полным набором как в TinyMCE здесь и просто в HTML можно писать и очень хитро спрятать JS код.
А если WYSIWYG с полным набором как в TinyMCE здесь и просто в HTML можно писать и очень хитро спрятать JS код.
Фильтровать входящие данные по моему мнению неправильно. Пусть пользователь вводит все что захочет.
Фильтровать, тоже не правльно, если пользователь захотел видеть в своем профиле/тексте скрипт с алертом внутри, пусть это будет текст(а не xss).
Как было замечено выше htmlspecialchars сделает свою работу.
Так же HTML Purifier кэширует результат, и не будет жрать память каждый раз при выводе текста.
Фильтровать, тоже не правльно, если пользователь захотел видеть в своем профиле/тексте скрипт с алертом внутри, пусть это будет текст(а не xss).
Как было замечено выше htmlspecialchars сделает свою работу.
Так же HTML Purifier кэширует результат, и не будет жрать память каждый раз при выводе текста.
Я например не представляю как определить безопасный или не безопасный скрипт который написал пользователь.
htmlspecialchars — не подходит так как разметка теряется.
htmlspecialchars — не подходит так как разметка теряется.
я хотел сказать, что нужно не фильтровать, а обрабатывать вывод. Определять безопасный или нет не нужно, нужно рассчитывать что любой текст может содержать что угодно.
HTML Purifier сделает как надо, это конечно зависит от проекта.
Насчет какой разметки вы говорите?
HTML Purifier сделает как надо, это конечно зависит от проекта.
Насчет какой разметки вы говорите?
ІМХО зловредный код там не должен находиться.
Нужно сохранить разметку WYSIWYG редакторов.
Нужно сохранить разметку WYSIWYG редакторов.
tidy + xslt + десяток простых шаблонов = но пасаран
Хотите сначала проверить на правильность HTML
потом перевести в XSLT убрать там JS, снова перевести в HTML…
думаете так будет лучше по производительности и надежности?
и про какие шаблоны Вы говорили?
потом перевести в XSLT убрать там JS, снова перевести в HTML…
думаете так будет лучше по производительности и надежности?
и про какие шаблоны Вы говорили?
нет, тиди чисто для исправления невалидного xhtml, чтобы потом преобразовать в domdocument и наложить сверху xslt, который обезвредит все опасные конструкции.
по надёжности — определённо. большинство дырок на упомянутом сайте связаны с тем, что text-шаблонизаторы просто соединяют строчки и им глубоко наплевать на то, что в результате получается невалидный документ. xml-шаблонизаторы этим не страдают и формируют сначала модель документа, а потом сериализуют её в соответствиями со всеми правилами.
производительность libxml+libxslt не думаю, что меньше, чем велосипед на пхп.
по надёжности — определённо. большинство дырок на упомянутом сайте связаны с тем, что text-шаблонизаторы просто соединяют строчки и им глубоко наплевать на то, что в результате получается невалидный документ. xml-шаблонизаторы этим не страдают и формируют сначала модель документа, а потом сериализуют её в соответствиями со всеми правилами.
производительность libxml+libxslt не думаю, что меньше, чем велосипед на пхп.
я понимаю, что у меня очень специфическая задача, но всё же решение заслуживает внимание.
Итак есть веб-мейл. Аджакс, вебдваноль — все дела. Задача — подгрузить текст письма по XHR и отобразить его в браузере. Попутно убрав оттуда все попытки XSS.
Решение — препроцессинг HTML через DOM парсинг. То есть — создаю ноду, но не добавляю её в документ. Так и висит без парента. Браузеры это понимают и поэтому всё содержимое этой ноды вообще никак не влияет на документ (ну почти все браузеры — попутно нашёл баг в webkit — он таки добавляет некоторые элементы в основном документ).
После этого запихиваю в эту ноду текст ХТМЛ-письма и прохожусь по нему парсером, вырезая оттуда всё, что мне не нравится — весь JS и все способы его туда запихнуть.
После этой обработки — беру ХТМЛ письма через innerHTML и со спокойной совестью вставляю его в основной документ.
Плюсы:
— DOM-парсинг самый надёжный — ему плевать на незакрытые теги, зашифрованное содержимое аттрибутов и прочие приколы, которые должны обмануть HTML purifier'ов и иже с ними.
— это всё делается на клиенте, а не на сервере — снижается нагрузка на сервер.
Минусы: наверное только то, что это решение можно применять только в очень специфических задачах типа моей — когда контент выводится относительно нечасто (выводить так сотни писем в секунду будет уже несколько напряжно для клиента).
Итак есть веб-мейл. Аджакс, вебдваноль — все дела. Задача — подгрузить текст письма по XHR и отобразить его в браузере. Попутно убрав оттуда все попытки XSS.
Решение — препроцессинг HTML через DOM парсинг. То есть — создаю ноду, но не добавляю её в документ. Так и висит без парента. Браузеры это понимают и поэтому всё содержимое этой ноды вообще никак не влияет на документ (ну почти все браузеры — попутно нашёл баг в webkit — он таки добавляет некоторые элементы в основном документ).
После этого запихиваю в эту ноду текст ХТМЛ-письма и прохожусь по нему парсером, вырезая оттуда всё, что мне не нравится — весь JS и все способы его туда запихнуть.
После этой обработки — беру ХТМЛ письма через innerHTML и со спокойной совестью вставляю его в основной документ.
Плюсы:
— DOM-парсинг самый надёжный — ему плевать на незакрытые теги, зашифрованное содержимое аттрибутов и прочие приколы, которые должны обмануть HTML purifier'ов и иже с ними.
— это всё делается на клиенте, а не на сервере — снижается нагрузка на сервер.
Минусы: наверное только то, что это решение можно применять только в очень специфических задачах типа моей — когда контент выводится относительно нечасто (выводить так сотни писем в секунду будет уже несколько напряжно для клиента).
Sign up to leave a comment.
Фильтрация XSS