Новости

Не подведут ли вас веб-приложения?

В 2001 году вирусы Code Red и Nimda привлекли серьезное внимание к уязвимостям веб-серверов, эксплуатируя их автоматически и массово. Многие специалисты в области безопасности отмечают, что с тех пор администраторы улучшили защиту веб-серверов, а производители устранили различные уязвимости в серверном программном обеспечении, таком как IIS и Apache. Поскольку сами серверы стали более недосягаемы, хакеры переключились на атаки веб-приложений, часто направляя особые усилия на получение доступа к серверам баз данных пользователей. Почти каждую неделю мы узнаем об очередной компании, которая случайно раскрыла хакерам тысячи записей своих заказчиков, а, по крайней мере, в одном случае — миллионы записей. Центром наиболее распространенных атак является хакер, посещающий ваш общедоступный сайт и использующий против вас ваши собственные веб-приложения с незащищенным кодом.

К. К. Мукей (K. K. Mookhey) проделал большую работу, пытаясь найти способ защиты веб-приложений. Пользующийся особым успехом среди докладчиков на конференции BlackHat в этом году, Мукей является основателем и главным техническим директором компании, оказывающей консалтинговые услуги в области информационной безопасности, — Network Intelligence. Он консультировал компании из списка Fortune 500 и лидеров отраслевого сегмента в Индии, на Ближнем Востоке и в Северной Америке. Рабочая группа Мукея обнаружила уязвимости в системе безопасности продуктов Oracle, Symantec, Macromedia и других фирм. Мукей регулярно участвует в написании статей в разделе Infocus веб-сайта http://www.securityfocus.com. Здесь он дает полезные советы, которые помогут оценить уровень безопасности ваших веб-приложений.

LiveSecurity: Многие администраторы компаний малого и среднего бизнеса слышали об атаках типа «инъекция SQL», но до конца не понимают, что это такое. Не могли бы вы объяснить?

К. К. Мукей: Атака типа «инъекция SQL» — это по сути внедрение метасимволов SQL в веб-приложение с целью выполнения выбранного злоумышленником SQL-запроса в серверной базе данных жертвы. Идея, таким образом, заключается в использовании вашего веб-интерфейса для взлома серверной базы данных SQL.

LSS: Еще одну группу атак часто называют запуском сценариев между узлами (Cross-Site Scripting, XSS). Что это такое?

К. К. Мукей: Запуск сценариев между узлами относится к той же категории атак, что и инъекции SQL, а именно к атакам со вставкой метасимволов, когда злоумышленник пытается внедрить специальные символы, которые веб-приложение не может обработать. В случае запуска сценариев между узлами злоумышленник вставляет символы HTML-кода, которые в конечном итоге инициируют выполнение сценария JavaScript в браузере другого пользователя. Основное различие заключается в том, что целью атак типа «инъекция SQL» является сервер, а запуск сценариев между узлами направлен против другого пользователя того же веб-сайта. Этот тип атаки использует доверие пользователя к посещаемому веб-сайту.

LSS: Может показаться, что эти виды целевых атак угрожают только крупным компаниям. Представляют ли эти атаки реальный риск для сетей малых предприятий?

К. К. Мукей: Мишенью атак на веб-приложения скоро будут веб-сайты любого размера. Основной критерий, по которому злоумышленники выбирают свою цель, заключается в возможности получить доступ к финансовым данным.

LSS: Очевидно, любая компания стремится избежать изъянов в системе безопасности своих клиентских веб-приложений. Однако акцентировать внимание на защищенном программировании стали лишь недавно. Есть ли способы предотвратить атаки на веб-приложения, не привлекая специалиста в области защищенного программирования на языке HTML?

К. К. Мукей: К счастью, большинство языков веб-приложений, таких как Perl, PHP и ASP .NET, теперь имеют встроенные утилиты проверки входных и выходных данных. Разработчик веб-приложений просто должен удостовериться, что все пользовательские входные данные проверены этими утилитами. Обычно утилиты выполняют проверку на наличие метасимволов, например характерных для атак типа «инъекция SQL» или запуска сценариев между узлами, и удаляют их.

LSS: Распространенные языки программирования, такие как C, также предусматривают функции, проверяющие входные данные или являющиеся более безопасными (например, если сравнивать функции strlcpy и strcpy). Однако, похоже, трудно убедить программистов, не особо разбирающихся в вопросах безопасности, использовать эти функции. Существует ли аналогичная проблема и в разработке веб-приложений? Знают ли разработчики об этих утилитах защиты?

К. К. Мукей: Бывают разные ситуации. Например, один из наших клиентов проводил базовую проверку входных данных, которая была недостаточной для обнаружения запуска сценариев между узлами. В этом издании есть сведения, которые помогут организациям создать процедуры и процессы для защищенного программирования, но эти сведения содержатся не только здесь. Важный шаг, который может сделать компания, — предоставить своим разработчикам программного обеспечения подписку на списки рассылки «Защищенное программирование» и «Безопасность веб-приложений», размещенные на сайте http://www.securityfocus.com/.

LSS: Существуют ли средства, которые помогают обнаружить изъяны в системе безопасности веб-приложений в собственном веб-коде?

К. К. Мукей: Большинство средств проверки исходного кода ориентировано на поиск таких дефектов, как переполнение буфера, строки форматирования или состояние гонки. Обычно они не обнаруживают ошибки, которые встречаются в веб-приложениях.

LSS: Мы обсудили, что могут сделать разработчики для улучшения безопасности своего кода, но большинство наших читателей являются сетевыми администраторами. Может ли специалист, обслуживающий веб-сервер, принять какие-либо меры для защиты сети от атак на веб-приложения?

К. К. Мукей: Он может установить такие средства, как mod_security, модуль защиты для Apache. Для Windows Майкрософт предлагает бесплатное средство ISS Lockdown, которое включает также URLscan. IIS Lockdown помогает создать эффективную конфигурацию защиты сервера IIS, а URLscan размещается на переднем крае сервера IIS и сканирует входные и выходные данные на основе установленных пользователем правил. Хотя средство URLscan недостаточно гибкое. Неплохим вариантом может стать SecureIIS от компании eEye. Администратор должен провести анализ затрат и выгод, чтобы оценить целесообразность покупки.

LSS: Один из современных популярных терминов в области безопасности — IDS (системы обнаружения вторжений). Эти системы обычно распознают атаки на основе сигнатур в их коде. Можно ли использовать общую сигнатуру для обнаружения атак на веб-приложения, таких как запуск сценариев между узлами или инъекция SQL?

К. К. Мукей: Запуск сценариев между узлами намного проще обнаружить при помощи сигнатуры, чем инъекции SQL. Независимо от того, как злоумышленник использует уязвимость для запуска сценариев между узлами, рано или поздно он должен вставить угловую скобку HTML-кода (<). При обнаружении такого символа во входных данных высока вероятность, что это вредоносный код.

LSS: Возможны ли ложные срабатывания сигнатуры, которая обнаруживает угловые скобки HTML-кода?

К. К. Мукей: Да. Если вы разрешаете посетителям своей веб-страницы создавать электронные сообщения или публикации в группе новостей или в блоге в формате HTML, то сигнатура обнаружит угловые скобки HTML-кода.

LSS: На конференции BlackHat вы обсуждаете использование IDS-систем на базе сигнатур в комбинации с обнаружением аномалий для более эффективного обнаружения атак на веб-приложения. Не могли бы вы конкретизировать достоинства и недостатки IDS-систем на базе сигнатур и на основе обнаружения аномалий, а также пояснить, как они взаимно дополняют друг друга?

К. К. Мукей: Есть ряд атак, для которых невозможно создать сигнатуры. Например, злоумышленник может попытаться определить идентификатор сеанса или данные для аутентификации методом подбора. Мы не представляли, с помощью какой сигнатуры можно обнаружить атаки этого типа. Другой вид атаки, для обнаружения которой не удается использовать сигнатуры, — ввод в скрытое поле формы HTML. При этом определенные ключевые параметры хранятся в скрытом поле HTML-страницы в браузере пользователя.

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

Я думаю, что обнаружение на основе аномалий компенсирует многие недостатки обнаружения на базе сигнатур. Например, когда злоумышленник пытается определить идентификатор сеанса методом подбора, генерируется множество запросов с различными идентификаторами сеанса за короткий промежуток времени и все они поступают с одного и того же IP-адреса. Это очень необычно. IDS-системы на основе аномалий помечают трафик как существенно отличающийся от нормального, поскольку обычно пакеты данных поступают с одним и тем же идентификатором сеанса с одного IP-адреса.

LSS: На конференции вы рассказали об использовании Snort для обнаружения SQL-атак. Можете ли вы дать какие-нибудь советы и рекомендации тем нашим читателям, которые не пользуются Snort?

К. К. Мукей: Один из лучших приемов, о котором я упоминал ранее, — использование модуля mod_security в составе установки Apache. Модуль mod_security поставляется вместе с приложением, которое преобразует правила Snort в формат, распознаваемый модулем mod_security. Самое простое, что может сделать администратор, — загрузить последний набор правил Snort, преобразовать их при помощи приложения, а затем использовать эти правила вместе с конфигурацией Apache при помощи модуля mod_security.

LSS: Значит, если я клиент Майкрософт, то мне не повезло?

К. К. Мукей: [смеется] Нет, все совсем не так плохо. Но вам придется потратиться на покупку SecureIIS или другого коммерческого продукта, поскольку URLscan не поддерживает регулярные выражения. Полагаю, ваш вопрос подразумевает, что вы используете IIS в качестве веб-сервера. Однако, если вы используете Apache на платформе Windows, модуль mod_security с таким же успехом будет работать и в этой среде.

LSS: Многие наши клиенты часто заказывают сторонним специалистам разработку веб-сайтов. Какие советы вы можете дать тем, кто работает с веб-приложениями, созданными другими разработчиками, относительно оценки этих приложений и их авторов?

К. К. Мукей: Если вы уже внедрили веб-приложение, лучше всего протестировать его на проникновение. Проведите полный анализ исходного кода, если с финансовой точки зрения это целесообразно. Оцените финансовые последствия взлома веб-приложения, а затем определите, перевешивает ли польза от теста на проникновение или анализа исходного кода этот финансовый ущерб?

Если компания привлекает сторонних разработчиков для создания веб-сайта, вот ряд важных вопросов, которые нужно им задать: Какими приемами защищенного программирования вы пользуетесь? Каким стандартам вы следуете? Обратите внимание, упомянут ли они проект OWASP и знают ли 10 главных уязвимостей веб-приложений, опубликованных на сайте OWASP. Все это желательно услышать от разработчиков.

LSS: Что в первую очередь следует сделать руководителю малого предприятия, чтобы разработчики его веб-приложений начали применять защищенное программирование?

К. К. Мукей: Всем разработчикам рекомендуется начать с посещения веб-сайта http://www.owasp.org/. Там они найдут «Руководство по созданию защищенных веб-приложений», новая версия которого выйдет через пару месяцев. На этом сайте также опубликован список 10 главных уязвимостей веб-приложений, о которых должны знать все разработчики. Списки рассылки «Защищенное программирование» и «Безопасность веб-приложений» на сайте SecurityFocus, о которых я упоминал ранее, также будут весьма полезными ресурсами для разработчиков веб-приложений. Наконец, проведите тестирование по принципу «черного ящика». Некоторые уязвимости могут остаться необнаруженными, пока какой-либо злоумышленник не попытается взломать ваше веб-приложение.

По публикациям авторов издания LiveSecurity®

Возврат к списку

 

Защита банкоматов

Имя* Компания* Email* Телефон

* - Поля, обязательные для заполнения

Компрометация приложений для смартфонов

Имя* Компания* Email* Телефон

* - Поля, обязательные для заполнения

Семинар ATAR

Фамилия* Имя* Должность* Компания* Email* Телефон* Защита от автоматического заполнения Введите символы с картинки*

* - Поля, обязательные для заполнения

Заполните поля

Защита от автоматических сообщений
CAPTCHA
Введите слово на картинке*

Заполните поля

Защита от автоматических сообщений
CAPTCHA
Введите слово на картинке*