[Закрыть]
 
popoff.donetsk.ua
Быть самим собой – это опыт. /Лиз Бурбо/
Начало | Новости | Статьи | Форум | Опросы | Карта сайта | Обо мне
popoff.donetsk.ua - Статьи - Программирование - Модули - xmlfilter
Я это делаю
Персональное меню
Голосование
Деньги, либо любимое занятие? Постоянный адрес этого вопроса
Деньги, но неинтересная работа и невозможность уделить время семье
Интересная работа, возможность саморазвиваться, но нищенский заработок
Ваш возраст (не обязательно)
Почему? (не обязательно)

Голосование закрыто.

Поиск по сайту
Реклама
Personal Photo.сайт:
www.denisey.com.ua
Статистика

xmlfilter

Постоянный адрес статьи

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

Содержание

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

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

Постоянный адрес статьи

Версия: 2005-08-27

Тип файла: zip-архив

Размер файла: 22 883 байта

http://download.popoff.donetsk.ua/xmlfilter-parse.zip

Введение

Постоянный адрес статьи

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

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

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

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

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

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

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

  • <p> Запрещают ввод специальных символов, применяя к вводу пользователя функцию htmlspecialchars(). Это самый надежный и, вероятно, самый быстрый способ. Еще никто не придумал, как его взломать и, вероятно, не придумают. Однако при использовании этого способа пользователи не могут вводить ничего кроме текста. А часто хочется дать пользователям возможность выделять текст жирным, курсивом, цветом, выделять ссылки и т.п. Если нам это нужно, то простой htmlspecialchars() нам не пойдет. </p>
  • <p> Как вариант улучшения htmlspecialchars() была придумана функция strip_tags(), которая удаляет из html-документа теги, оставляя в них только разрешенные теги. </p><p> Однако эта функция не проверяет значений атрибутов. JavaScript можно встраивать не только внутри тега <script>, но и, например, внутри значения атрибута onMouseOver или даже так: <a href=javascript:alert('hacked!');>. Поэтому, даже если мы и вырежем все запрещенные теги, отсутствия скриптов нам это не гарантирует. </p>
  • <p> Третий способ - кардинальный. Если уж мы не можем фильтровать то, что вводит пользователь, то будем считать, что он вводит описание на некотором особенном языке, который интерпретируется, и в результате получается html-код, который содержит в себе только то, что разрешено нашим специальным языком. </p><p> За примерами далеко ходить не требуется - это всем известные bb-codes, используемые, например, в форумах phpBB. Или синтаксис описания статей, используемый в системе распределенного владения статьями WackoWiki. </p><p> Если реализация этого способа не содержит в себе ошибок, то этот способ действительно гарантирует, что в результирующем документе не будет скриптов, и будут только те теги, которые разрешены нашим языком. </p><p> Следует, однако, указать на недостатки. </p><p> HTML - это общепризнанный стандарт, который знают все. Или, по крайней мере очень многие. А наш «специальный язык» - это именно специальный язык, который мы, конечно, можем описать, но такого распространения, как html, он не получит. Если я прихожу на какой-то сайт, на котором используется такой специальный язык, то я должен сначала изучить этот язык и только после этого я смогу создавать свои документы. Впрочем, эти языки обычно довольно просты. Но тем не менее, я должен запоминать какую-то дополнительную информацию, иногда не совсем тривиальную. </p><p> Значительно ухудшается переносимость документов. Если я хочу какой-то документ перенести из одного места в другое, и в этом одном месте используется один язык описания, а в другом - другой язык описания, то я должен все редактировать, переводить с одного языка на другой. Простым копированием тут не обойтись. Впрочем, эта задача может вызвать сложности, пожалуй, только в системах распределенного владения статьями, когда есть большие объемы статей. Но вот именно при решении такой задачи мы и прочувствуем всю головную боль. </p><p> Часто все же возникает необходимость вставлять какие-нибудь теги, которые не допустимы в этом специальном языке. Для этого обычно делают возможность вставлять «чистый html», который выводится «как есть», без изменений и преобразований. Обычно такую возможность оставляют только привилегированным пользователям, которым можно доверять. Но, снова же, возникает вопрос, насколько мы можем доверять этому пользователю? Если ему нужно дать только возможность добавления своих форм, но при этом не разрешать ему JavaScript, как нам быть? Разрешить весь html мы ему не можем, поскольку таким образом мы автоматически разрешаем и JavaScript. Вставить самим? Или, может, посадить отдельного человека, т.н. «службу поддержки», к которому все будут обращаться «мне вот тут нужно вставить такой-то тег, не могли бы Вы мне помочь»? Или, как наиболее вероятный вариант - доработать наш язык и ввести в него новые возможности. Эти доработки, однако, требуют внесения изменений в скрипты и для этого потребуется приглашать программиста. Обычные администраторы сайта, отвечающие за содержимое сайта, не могут внести изменения в этот язык. </p><p> А если мы захотим, что бы в одном месте можно было вставлять формы, а других местах - нельзя, как тогда? Лобовое решение - добавить отдельное поле, в котором будет говориться, разрешено ли здесь вставлять формы или нет. Хорошо, если только формы. А если у нас 10 таких разных возможностей - делать отдельную панель, на которой будет настраиваться, что можно, а что нельзя? А если мы захотим добавить возможность - приглашать программиста? </p><p> В общем, такой подход, конечно, справляется со своей задачей - обезопасить сайт от нападений. Но с таким способом сплошная головная боль. </p>

Вот как эту задачу предлагаю решать я:

Третий способ, в котором мы считаем, что пользователь вводит документы в особом формате, который мы затем интерпретируем, мне видится самым перспективным. Только я его немного переформулировал бы и в качестве «специального языка» взял бы не свой собственный язык, а тот язык, который используется везде - разрешить пользователю сразу вводить 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-код, который будет отображаться правильно только в некоторых браузерах, то мы фактически сводим на нет все усилия кодера шаблонов, который старался сделать так, что бы сайт работал правильно хотя бы в основных браузерах.

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

Постоянный адрес статьи
  • по умолчанию все теги запрещены. Можно задать список разрешенных тегов. Для каждого тега мы можем указывать параметры, как должна вести себя система в случае, если пользователь вводит недопустимый тег, указывает недопустимый атрибут или недопустимое значение одного из атрибутов, или располагает тег в месте, где этот тег не может быть расположен.

  • Для каждого тега можно указать, какие теги могут быть расположены внутри этого тега и внутри каких тегов может быть расположен этот тег. Можно указать, какие из тегов допустимы на самом верхнем уровне.

  • по умолчанию во всех тегах все атрибуты запрещены. Можно задать список разрешенных атрибутов для каждого отдельного тега. Для каждого отдельного атрибута можно указать, какие значения считать допустимыми в качестве значения этого атрибута.

  • по умолчанию запрещены все специальные символы, кроме символов &lt;, &gt;, &amp; и &quot;. Можно задать список разрешенных специальных символов. Например, можно дополнительно разрешить специальный символ неразрывного пробела &nbsp;.

  • В случае возникновения ошибок система не просто запрещает все неправильные данные, но она так же пишет, почему она запретила эти данные. Можно задавать, кто будет видеть сообщения об ошибках, а кто - нет.

  • Систему можно настроить таким образом, что бы результатом обработки всегда был валидный html. Это необходимо для того, что бы нельзя было ввести такой html-код, который мог бы испортить содержимое всей страницы. Например, нельзя выводить тег <tr>, если он расположен не внутри тега <table>.

  • Система может преобразовывать документы в двух режимах: в режиме xml и в текстовом режиме.

  • Дополнительные возможности для пользователей - переход на новую строку может автоматически преобразовываться в тег <br />. Возможно автоматическое преобразование смайлов.

  • О дополнительных возможностях по расширению системы (для программистов). Можно добавлять свои процедуры проверки правильности значений атрибутов, обработки инструкций, специальной обработки тегов и особой проверки валидности и преобразования URL. Можно так же задавать свой собственный перечень смайлов.

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

Постоянный адрес статьи

Попробовать работу скрипта:
http://popoff.donetsk.ua/try/xmlfilter/

Перечень и описание параметров разрешений и управляющих параметров библиотеки xmlfilter.parse:
http://popoff.donetsk.ua/text/work/libs/xmlfilter/parse/param.html

Перечень и описание ошибок, выводимых модулем фильтрации XML-документов:
http://popoff.donetsk.ua/text/work/libs/xmlfilter/parse/error.html

Об управлении параметрами:
http://popoff.donetsk.ua/text/work/libs/a/param/

Последняя модификация: 26.06.07 22:02

Не проходите мимо! Оставьте Ваш комментарий в форуме! >>>