Статья только в электронной версии журнала
Мне удалось проникнуть на сайт eWeek OpenHack, однако с помощью нескольких несложных шагов это вполне можно было бы предотвратить. Главный вывод таков: безопасность приложения - реальная вещь, но при условии последовательно предпринимаемых мер и методичной проверки их эффективности.
Поутит: “Разработчикам надо быть внимательными
при повторном использовании программ”
Я не стал концентрировать внимание на какой-то одной мишени из пяти предложенных eWeek и попытался нащупать потенциальные проблемы безопасности этого сайта.
Моя попытка нападения началась с беглого знакомства с приложением OpenHack в вариантах Microsoft и Oracle, чтобы получить общее представление об их возможностях и архитектуре.
Первым делом я решил выяснить, какое из этих приложений более уязвимо.
Регистрируясь в качестве пользователя, я обратил внимание, что в версии Oracle имеются кое-какие несообразности, так как обращение к необязательным пунктам учетной информации, например персональному “титулу”, вызывало неожиданные сообщения об ошибке. Проблемой безопасности это само по себе не является, однако говорит об отсутствии согласованности ПО, что, по моему мнению, указывало на наиболее вероятный путь к уязвимости испытуемого приложения, которую мне предстояло найти.
Поиграв с приложением Oracle OpenHack еще несколько минут, я выяснил, что в нем используется общая процедура проверки корректности заполнения полей ввода. Я начал искать поля, хотя бы в чем-то отличающиеся в этом смысле от других, в надежде, что в них могут быть недосмотры либо для них не годятся стандартные ограничения.
Приложение OpenHack невелико, и список интересующих меня полей оказался довольно коротким. В него входило несколько скрытых полей форм, несколько идентификационных шифров, передаваемых в качестве параметров запроса, поле URL и набор селективных кнопок.
Первым я проверил скрытое поле формы для идентификации пользователя, появляющееся при редактировании учетной записи.
В приложении имелась пометка, утверждавшая, что после создания учетной записи пользовательский идентификатор (ID) изменить нельзя. Я изменил скрытое поле, введя в него новый ID, и нажал на кнопку “submit”.
Приложение обработало мой запрос и заменило мой прежний ID на новый. Я вышел из приложения и снова попробовал войти в него со своим старым ID. Оказалось, что приложению он уже не известен. Тогда я попытался подключиться с новым ID и моим первоначальным паролем и в результате был допущен в систему как новый пользователь. Я повторил тот же процесс и возвратил входной ID к исходному состоянию. Хотя это не решало поставленных задач, я сообщил в eWeek о дефекте в нормальной работе программы.
Затем я начал размышлять, почему же разработчик не обеспечил контроля над изменением ID. По-моему, это было связано с тем, что он использовал одинаковый экранный интерфейс и для добавления новых пользователей, и для редактирования уже существующих учетных записей.
Хотя в принципе это можно осуществить без ущерба для безопасности, использование общего интерфейса для выполнения двух разных задач налагает на разработчика повышенную ответственность за логический контроль обеих ситуаций. Но, похоже, он не очень-то ожидал, что в сценарии редактирования кто-то вздумает изменять поле ID.
Однако когда я решил заново ввести дубликат того же ID, он появился в поле вместе с сообщением об ошибке. Поразмыслив над данными, возвращавшимися на экран, я попробовал использовать в качестве ID тег сценария. Это прошло успешно.
Разработчики Oracle, безусловно, знали про возможность модификации скрытых полей форм, но при оценке своего приложения не обратили внимания на эту уязвимость из-за того, что один экран мог использоваться в разных контекстах.
Для гарантированной безопасности системы надо логически проиграть каждый сценарий, чтобы учесть последствия всех возможных вариантов.
Вторая ошибка, позволявшая реализовать кросс-сайтовый сценарий, обнаружилась в поле URL-адреса Web-страницы “Product or Services”. Можно было предположить, что в нем была та же процедура проверки корректности ввода, что и в остальных частях приложения. Однако контекст этого поля - конструирование URL - отличался от других полей приложения.
Я ввел нормальный URL и посмотрел на возвращаемый HTML-источник, чтобы понять, какой специфический синтаксис можно было бы добавить. Поскольку при проверке URL использовалась та же процедура, что и для проверки длинных полей комментариев, в нем считались допустимыми такие символы, как кавычки, знак равенства, скобки и пробел. Мне не составило труда присоединить к анкерному тегу событие JavaScript, и я добился нужного эффекта.
Хотя эта сценарная уязвимость сослужила мне несколько иначе, чем то, что было описано выше, существо проблемы было одинаковым.
Многократное использование кода является важной концепцией в разработке ПО и может быть очень полезным при хорошо проработанной модели безопасности, но разработчик должен быть внимательным, чтобы это не привело к появлению непредусмотренных дыр.
Приложение OpenHack во всех случаях задействовало одну и ту же процедуру контроля, хотя контекст использования полей был не одинаков. Эти различия неизбежно требуют соответствующих вариаций в процедурах проверки корректности вводимых данных.
Повторное использование кода в комбинации с разнообразными способами кросс-сайтовых сценарных атак дало мне возможность успешно взломать сайт.
Джереми Поутит (jpoteet@tech-partners.com) работает главным технологом ИТ-консалтинговой фирмы Technology Partners (www.tech-partners.com).
Методы предупреждения атак на уровне приложений
- Разработчики должны представлять себе все возможные ситуации. Не исследовав все, что взломщик может сделать с приложением, они не смогут задействовать подходящие механизмы обороны. К сожалению, многим из них невдомек, что кто-то станет модифицировать скрытые поля форм и что кросс-сайтовая сценарная атака - вполне реальная вещь.
- При всей пользе повторно применяемого кода принцип “одно сгодится на всех” не всегда работает. Хотя имеются определенные общие аспекты политики безопасности, приложения нуждаются в доводке под специфические контексты.
- Надо сделать правилом процесс аттестации ПО, предусматривающий внимательные проверки кода и оценки уязвимости, чтобы последовательно и эффективно реализовывать меры безопасности.
Источник: Джереми Поутит.
1. Используя несколько Ethernet-портов IDS (системы обнаружения вторжений) IntruShield 2600 фирмы IntruVert Networks, мы могли одновременно следить за тремя сегментами сети. Однако наш наиболее важный трафик пересылался посредством Secure HTTP и поэтому, к сожалению, не мог контролироваться IDS, что является общей проблемой всех подобных систем. 2. ОС OpenBSD оснащена функциями брандмауэра, перенаправления портов, трансляции сетевых адресов и защиты сети от обманных действий. Мы по достоинству оценили способность pf (встроенного фильтра пакетов) брандмауэра OpenBSD регистрировать заблокированные пакеты через интерфейс виртуальной сети вместо syslog, в также возможность их сохранения в формате tcpdump. Правда, мы заметили несколько проблем, связанных с тем, что pf-правила, написанные с использованием опции брандмауэра “keep state”, могли вызывать некорректную блокировку пакетов, возвращаемых в результате входящего подключения. 3. Используемые нами коммутаторы фирмы Extreme Networks показали себя во время теста как простые и надежные устройства. В качестве дополнительной меры безопасности мы задействовали правила контроля трафика на уровне портов для блокировки обмена между IP-адресами, которым не следовало сообщаться друг с другом. 4. В конфигурации Oracle нам пришлось уделить специальное внимание проблемам VPN-взаимодействия, так как мы не смогли обнаружить VPN-клиент, которому полагалось функционировать на Solaris-клиентах Oracle и подключаться к VPN на базе OpenBSD. Мы подключили бастионный хост SSH (Secure Shell) перед периметром, хотя и сконфигурировали брандмауэр на сервере так, чтобы он пропускал только IP-адреса разрешенных систем. Для VPN-взаимодействия в конфигурации Microsoft нам достаточно было подключить Windows-клиенты к Windows-серверам. 5. Microsoft решала задачи криптозащиты на среднеуровневой системе IIS (Internet Information Services), так как необходимые библиотеки .Net внутри Microsoft SQL Server не работали. Но в ряде случаев предпочтительнее шифрование в СУБД, и будущий выпуск SQL Server Yukon должен полностью поддерживать .Net Framework. Это обеспечит переносимость кода на базе Java в другие комбинации сервера приложений и СУБД. 6. Мы управляли коммутаторами при помощи старого доброго нуль-модемного кабеля, не создавая отдельной виртуальной ЛВС. Но в перспективе лучшим выбором будет VLAN. 7. Дефект приложения, обнаруженный Джереми Поутитом, позволял осуществить при определенных, довольно редких, обстоятельствах атаку с заимствованием прав. Однако базы данных имели табличные ограничения, создававшие лишний уровень безопасности, и поэтому даже злонамеренное использование этого дефекта не могло изменить информацию в базах данных. Наличие многих независимых уровней защиты - ключ к крепкой обороне. |
