Фильтрация XSS

    Все мы знаем о таком типе атаки как XSS (о их видах и способах применения было написано много), все мы знаем какую опасность может нанести такая атака, а также о том, что всегда нужно проверять входящие данные на наличие XSS — об этом пишут везде.

    Но о том, чем именно и как именно защититься – информации практически нет.

    Я веб-разработчик, который создал собственную СMS на основе которой и создаю сайты (почему я изобрел велосипед? – это не тема для данного обсуждения), проделав детальный анализ понял, что защита откровенно слабая и попытался найти решение проблемы. Нашел большой детальный сборник возможных вариантов XSS атак — это будут тестовые атаки, которые должны фильтроваться.

    Результатом поисков и тестирования определил для себя что полностью справился с поставлено задачей – только HTML Purifier. Библиотека фильтров написана на PHP с огромными возможностям конфигураций.
    Все в этой библиотеке отлично, кроме одного момента – в работе библиотека использует 4.2Mb памяти, что, по моему мнению, слишком много.

    Остальные претенденты или не справились полностью со всеми тестами, или устарели настолько, что на них остались только нерабочие ссылки.

    Я понимаю, что данный фильтр будет запускаться редко (исключительно для проверки входящих данных от потенциально опасных посетителей), но в силу собственных убеждений стараюсь все совершенствовать максимально.

    Возможно, кто-то владеет информацией о лучшем и более оптимизированном фильтре?
    Не проблема, если он написан на другом языке.

    В идеале разыскивается простая и быстрая функция, которая могла бы четко выполнить фильтрацию XSS атак.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 34

      0
      исключительно для проверки входящих данных от потенциально опасных посетителей

      по какому критерию вы собираетесь разделять ваших посетителей на опасных и не очень?

      В идеале разыскивается простая и быстрая функция, которая могла бы четко выполнить фильтрацию XSS атак.

      htmlspecialchars() ;)
        0
        например: админам фильтровать не обязательно, а обычным пользователям обязательно.

        htmlspecialchars() ;) — не подходит так как разметка теряется.
    • НЛО прилетело и опубликовало эту надпись здесь
        +1
        А если получится один раз при входе все проверить и зачистить, то зачем тогда при каждом выводе перепроверять?
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            То что текст на входе может содержать неправильное HTML (незакрытый тег например) может испортить вид страницы — это действительно проблема.
            Спасибо что обратили мое внимание на это.
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                Tidy — спасибо, записал =)

                Суть в том что зачистить код совсем непросто, а наоборот сложно.
                И картинку можно «заразить» — ну это вообще %) А в IE8 это тоже есть или вылечили?
          +1
          А если не получится. Сегодня у вас одни правила обработки, завтра другие.

          Правила изменились, контент уже в базе, если вы применяете свои фильты/обработчике при выводе то новый и старый контент будет обрабатываться одинаково.
            0
            Такое реализую если только заказчик захочет такую возможность.
            Для большинства сайтов/портал достаточно «красиво» убрать подозрительный код.

            Работа фильтров тестируется до сдачи проекта.
          0
          Задача: обезопасить ввод с WYSIWYG редакторов.
          • НЛО прилетело и опубликовало эту надпись здесь
              0
              Когда возможности ограничены то Вы полностью правы достаточно проверить на допустимость теги и их атрибуты.
              А если WYSIWYG с полным набором как в TinyMCE здесь и просто в HTML можно писать и очень хитро спрятать JS код.
        • НЛО прилетело и опубликовало эту надпись здесь
            +2
            У Вас есть готовоє решение?
            0
            Фильтровать входящие данные по моему мнению неправильно. Пусть пользователь вводит все что захочет.

            Фильтровать, тоже не правльно, если пользователь захотел видеть в своем профиле/тексте скрипт с алертом внутри, пусть это будет текст(а не xss).

            Как было замечено выше htmlspecialchars сделает свою работу.

            Так же HTML Purifier кэширует результат, и не будет жрать память каждый раз при выводе текста.
              +1
              Я например не представляю как определить безопасный или не безопасный скрипт который написал пользователь.

              htmlspecialchars — не подходит так как разметка теряется.
                0
                я хотел сказать, что нужно не фильтровать, а обрабатывать вывод. Определять безопасный или нет не нужно, нужно рассчитывать что любой текст может содержать что угодно.
                HTML Purifier сделает как надо, это конечно зависит от проекта.

                Насчет какой разметки вы говорите?
                • НЛО прилетело и опубликовало эту надпись здесь
                    0
                    Вот и стоит задача — узнать есть ли там скрипт или нет, если да то убрать.
                0
                ІМХО зловредный код там не должен находиться.

                Нужно сохранить разметку WYSIWYG редакторов.
                  –1
                  tidy + xslt + десяток простых шаблонов = но пасаран
                    0
                    Хотите сначала проверить на правильность HTML
                    потом перевести в XSLT убрать там JS, снова перевести в HTML…

                    думаете так будет лучше по производительности и надежности?

                    и про какие шаблоны Вы говорили?
                      0
                      нет, тиди чисто для исправления невалидного xhtml, чтобы потом преобразовать в domdocument и наложить сверху xslt, который обезвредит все опасные конструкции.

                      по надёжности — определённо. большинство дырок на упомянутом сайте связаны с тем, что text-шаблонизаторы просто соединяют строчки и им глубоко наплевать на то, что в результате получается невалидный документ. xml-шаблонизаторы этим не страдают и формируют сначала модель документа, а потом сериализуют её в соответствиями со всеми правилами.

                      производительность libxml+libxslt не думаю, что меньше, чем велосипед на пхп.
                        0
                        А можете показать пример такой реализации?
                          0
                          неа =) это клозет-сорц…
                            0
                            Тогда и за такую информацию спасибо, буду пробовать =)
                              0
                              вот правила: pastebin.mozilla-russia.org/97914
                                0
                                Оставляет только текст, а всю HTML разметку отрезает.
                                  0
                                  эм… покажи код =)
                                    0
                                    подозреваю ты не указал для хмл-ки дэфолтным неймспейсов ххтмл…
                    0
                    я понимаю, что у меня очень специфическая задача, но всё же решение заслуживает внимание.
                    Итак есть веб-мейл. Аджакс, вебдваноль — все дела. Задача — подгрузить текст письма по XHR и отобразить его в браузере. Попутно убрав оттуда все попытки XSS.
                    Решение — препроцессинг HTML через DOM парсинг. То есть — создаю ноду, но не добавляю её в документ. Так и висит без парента. Браузеры это понимают и поэтому всё содержимое этой ноды вообще никак не влияет на документ (ну почти все браузеры — попутно нашёл баг в webkit — он таки добавляет некоторые элементы в основном документ).
                    После этого запихиваю в эту ноду текст ХТМЛ-письма и прохожусь по нему парсером, вырезая оттуда всё, что мне не нравится — весь JS и все способы его туда запихнуть.
                    После этой обработки — беру ХТМЛ письма через innerHTML и со спокойной совестью вставляю его в основной документ.
                    Плюсы:
                    — DOM-парсинг самый надёжный — ему плевать на незакрытые теги, зашифрованное содержимое аттрибутов и прочие приколы, которые должны обмануть HTML purifier'ов и иже с ними.
                    — это всё делается на клиенте, а не на сервере — снижается нагрузка на сервер.
                    Минусы: наверное только то, что это решение можно применять только в очень специфических задачах типа моей — когда контент выводится относительно нечасто (выводить так сотни писем в секунду будет уже несколько напряжно для клиента).

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое