popoff.donetsk.ua title

xmlfilter -- Модуль фильтрации и визуального ввода xml-документов

Скачать исходник библиотеки

Ссылка на архив с исходными кодами библиотеки xmlfilter.parse

Введение

Немного о том, откуда возникла идея создания этого модуля

Основные возможности

Обзор основных возможностей системы

Часто задаваемые вопросы

В основном организационного характера: в чем отличие “xmlfilter” от “xmlfilter.parse”, «чем эта библиотека лучше стандартных валидаторов?»

xmlfilter.options

Настройки модуля фильтрации xml-документов

xmlfilter_parse

Проверить разрешения на xml-документ и вернуть документ, в котором содержатся только разрешенные сущности

Расширение возможностей

О том, как расширять возможности модуля фильтрации xml-документов

Смотрите также

Попробовать работу скрипта, описание параметров разрешений и управляющих параметров, перечень и описание ошибок и другая дополнительная информация

Для безопасного программирования интернет-приложений требуется фильтровать информацию, которая поступает от пользователей.

Если в каком-то поле вводится число, то следует проверить, а действительно ли в этом поле передано число. Если такую проверку не выполнить и, считая, что в этом поле может быть только число, подставить значение этого поля без дополнительных преобразований в sql-запрос, то злоумышленники получат возможность выполнить нападение, известное как SQL-Injection. Это нападение опасно тем, что злоумышленник может получить практически любую информацию из базы данных, и, возможно, изменить ее по своему усмотрению.

Но проверить, является ли введенное данное числом - просто. Совсем иначе обстоит дело, если пользователь должен вводить какой-то текст.

Если в каком-то поле неизвестные пользователи вводят текст, который затем отображается на сайте, то этот ввод должен быть ограничен таким образом, что бы в нем не содержался java script. Если разрешить неизвестным пользователям размещать на своем сайте java script, то злоумышленники получат возможность выполнить нападение, известное как XSS. Это нападение опасно, например, тем, что злоумышленник может получить возможность выполнять на сайте действия от имени других пользователей, в том числе от имени администраторов сайта.

Форумы, гостевые книги, служба обмена приватными сообщениями, информация о пользователе, комментарии к статьям, сами статьи - это самые простые примеры, в которых неизвестные пользователи могут вводить текст, который затем отображается на сайте.

Как быть уверенным в том, что пользователь не введет зловредный код, позволяющий выполнить XSS-нападение? Как быть уверенным в том, что пользователь не введет код, который испортит дизайн всей страницы?

Вот как эту задачу решали раньше, да и сейчас обычно именно так и решают:

Третий способ, в котором мы считаем, что пользователь вводит документы в особом формате, который мы затем интерпретируем, мне видится самым перспективным. Только я его немного переформулировал бы и в качестве «специального языка» взял бы не свой собственный язык, а тот язык, который используется везде - разрешить пользователю сразу вводить HTML.

Почему наш «собственный специальный язык» мы можем рассматривать, как отдельный язык, требующий интерпретации, а html - нет? Почему при использовании html в качестве «специального языка» возникает желание выпендриться и решить задачу в пару строк. При использовании других «специальных языков» (например, с квадратными скобками) всем ясно, что задача в пару строк не решается и тогда со спокойной душой создаются огромные библиотеки для интерпретации этих языков. Оправдание находят, вероятно, в том, что эти библиотеки якобы меньше по объему и якобы быстрее работают, чем соответствующие библиотеки для обработки html.

Я даже пошел бы дальше, предложил бы называть вещи своими именами и говорить, что мы требуем от пользователя ввода не HTML-кода, а XML-кода. Почему именно XML-кода? Потому что в нашем случае возможны расширения, когда пользователь может использовать дополнительные теги, которых нет в HTML. Я так же предложил бы ограничить пользователя и требовать от него ввода валидного XML-кода.

Справедливости ради, следует указать на недостаток предложенного мной способа. Мне видится только один недостаток, который состоит в том, что пользователь обязательно должен вводить валидный xml, для того, что бы его сообщение правильно отображалось. Но ведь и при использовании других языков мы тоже можем допустить ошибку, и тогда сообщение будет отображено неправильно. Здесь смысл на самом деле не в принципиальном наличии или отсутствии ошибок, а лишь в количестве деталей, приводящих к ошибкам.

Особенно тяжело может оказаться людям, которые «хорошо знают» html, но при этом не знакомы с особенностями xml. В целом, отличия-то не слишком большие. Просто во многих руководствах по языку html можно прочитать что-нибудь типа:


    При написании HTML Вы можете допускать такие, такие и такие ошибки.
    Допускайте эти ошибки! В Internet Explorer все равно все будет отображаться
    правильно!

Не знаю как Вам, но мне такая фраза видится чудовищной по своей развращенности. Для того, что бы объяснить, почему мне так кажется, я фактически должен объяснить, почему умышленное допущение ошибок - это разврат. В операционной системе Windows-98 обнаруживаются ошибки, которые возникли, вероятнее всего, по невнимательности программистов. Не так-то просто быть настолько внимательным, что бы не допустить ошибок в такой огромной системе, как Windows-98, поэтому мы не можем их ругать за эти ошибки. Но какой была бы эта система, если бы ошибки туда вставлялись умышленно и оправдание находилось бы в том, что «на тестовом примере это работает»?

Ошибки при написании HTML-документов включают в себя незакрытые теги (например, <td> - считается, что его можно не закрывать; в XHTML/XML не допустим даже не закрытый <br>), значения атрибутов без кавычек (например, <table border=1>), смесь верхнего/нижнего регистра при написании имен тегов и атрибутов, атрибуты без значений (например, <input type=“checkebox” checked />) расположение тегов в местах, где они не могут быть расположены, специальные &символы; без “;” в конце, теги, специфические для каких-то браузеров и т.п.

Почему никого не пугает, что в bb-кодах нельзя писать круглую скобку вместо квадратной, но при этом возникает ужас на лице, когда обнаруживается, что нельзя не ставить кавычки в значениях атрибутов в XML и по этому поводу говорят, что XML слишком требователен к синтаксису? Я вижу только одно объяснение - bb-коды никогда не работали с круглыми скобками и нигде не написано, что можно ставить круглые скобки вместо квадратных, а в HTML действительно допускается опускать кавычки в значениях атрибутов. К тому же существует масса руководств, в которых пользователям прямо предлагается использование этой возможности. Эта возможность оставлена для совместимости со старыми версиями HTML; как известно, в XHTML опускать кавычки уже нельзя. Если бы в HTML никогда не было возможности опускать кавычки, то требование к их наличию воспринималось бы как нечто само собой разумеющееся и уже не вызывало бы ужаса на лице.

Это же касается и других несовместимостей HTML с XML.

Если разрешить пользователю вводить html-код, который будет отображаться правильно только в некоторых браузерах, то мы фактически сводим на нет все усилия кодера шаблонов, который старался сделать так, что бы сайт работал правильно хотя бы в основных браузерах.