Раздел: Компьютерная документация -> Безопасность -> Защита информации

Отражение атак на уровне приложений

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

За последние восемь лет во взглядах специалистов ИТ произошла незаметная, но тем не менее революционная смена приоритетов. Эта перемена в равной мере отразилась и на отрасли информационной безопасности, и на сообществе хакеров. Пока предприятия были озадачены тем, как получить контроль над технологиями и процессами, чтобы защитить свои сети и операционные системы, Всемирная паутина превратилась в удобное средство доступа к клиентам и информации. Брандмауэров, систем обнаружения и предотвращения вторжений, мер по укреплению операционных систем как инструментов безопасности теперь недостаточно. Вместе с тем, в эпоху чрезвычайно быстрого и широкого распространения приложений Web их безопасности уделяется слишком мало внимания. До сих пор в этом отношении мало что изменилось. Чаще всего в качестве механизма защиты используется многоуровневая система фильтров пакетов, в соответствии с которой разные компоненты приложений Web, в частности внешний сервер Web, сервер приложений и сервер баз данных, размещаются в разных зонах.

Используемые в разных зонах компоненты или системы «надежно» конфигурируются, а затем на них устанавливается укрепленная операционная система. Если злоумышленнику удается благодаря уязвимости в защите получить контроль над системой, то даже в этом случае он может нанести лишь ограниченный ущерб, поскольку между зонами открыты лишь те порты, которые действительно необходимы для приложений (см.Рисунок 1). Недостаток заключается в том, что многоступенчатые фильтры пакетов абсолютно бессильны против атак на уровне приложений Web, потому что они не в состоянии различить корректность информации в поле ввода или форме с точки зрения приложения.

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

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

ЧТО ИМЕЕМ

Современные приложения Web в большинстве своем состоят из нескольких уровней, атака на которые может осуществляться независимо. Часто архитектурой приложения предусматриваются три уровня — представления, логики и данных. Первый принимает данные и подготавливает результаты к представлению. Следующий, уровень логики, получив данные с уровня представления, обрабатывает их (возможно, с привлечением уровня данных) и передает результат обратно на уровень представления. Уровень данных предоставляет, к примеру, хранилище информации и может либо актуализироваться, либо опрашиваться логическим уровнем (см.Рисунок 2).

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

Это можно показать на примере запроса для сценария PHP. URL выглядит следующим образом:

http://www.beispiel.de/artikel.php?id=22&format=html.

Файл artikel.php выполняется на удаленном сервере, включая параметры справа от знака вопроса. Если artikel.php представить в качестве исполняемого файла для Windows (artikel.exe), то результат оказался бы таким:

C:\artikel.exe/id:22/format: html

Решение: первое, что приходит в голову, — предотвращение подобных атак путем надежного программирования приложения Web. Для этого разработчик должен проверить объект (artikel.php), имя параметра (id, format) и значение параметра (22, html), которые в запросе HTTP посылаются приложению Web. Однако на практике часто довольствуются лишь рудиментарными проверками.

Вдобавок полностью игнорируются многочисленные элементы: идентификационные маркеры (Cookie), заголовок HTTP, информация о сеансе в URL, скрытые поля в исходном тексте и т. д. Поскольку протокол HTTP не содержит никакой информации о статусе пользователя, злоумышленник — в зависимости от приложения — может, к примеру путем изменения маркера (Cookiе Poisoning, Cookie Stealing) или информации о сеансе в URL, получить доступ к открытому сеансу другого пользователя и тем самым к его данным без имени и пароля. Изменение значений скрытых полей в исходном тексте также не представляет труда. Задачу упрощают так называемые «посредники перехвата», работающие на компьютере злоумышленника и заметно упрощающие манипуляции с перечисленными параметрами.

Таким образом, для разработки надежного приложения программист должен исходить из того, что злоумышленник в состоянии манипулировать любыми значениями. Дополнительно необходимо проверить поля ввода на наличие специальных символов и сценариев, поскольку они — если достигнут сервера баз данных — могут вызвать запуск специальных функций или обеспечить доступ к оболочке через внешнюю программу. Так, простая кавычка (') в комбинации с командами SQL в поле ввода способна привести к нежелательным действиям с внутренней базой данных. Еще одним возможным сценарием является атака, когда некорректные данные представлены в зашифрованной форме. Если злоумышленник запускает сценарий на стороне клиента (Cross-Site Scripting), специальные символы будут интерпретированы еще позже, когда их выведет, интерпретирует и выполнит браузер ничего не подозревающего пользователя. Для защиты от переполнения буфера должна выполняться проверка длины.

Итак, программист должен, с одной стороны, проверять, не манипулировал ли злоумышленник параметрами, заданными приложениями Web, а с другой — не содержат ли поля ввода неразрешенных данных: к примеру, инжекций SQL или команд, сценариев для выполнения на стороне клиента или переполнения буфера.

НАДЕЖНОЕ ПРОГРАММИРОВАНИЕ

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

Так или иначе, приложение должно продолжать функционировать. Поэтому в каждом отдельном случае следует решить, какие символы необходимы при вводе, а какие изначально стоит запретить. К примеру, нет смысла блокировать запрос по причине подозрения на инжекцию SQL из-за наличия апострофа в имени пользователя O'Grady (см.Таблицу 1). Иначе говоря, каждое поле необходимо обрабатывать индивидуально.

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

Альтернатива данному методу — использование брандмауэра для приложений Web (Web Application Firewall, WAF). Эти системы устанавливаются в сеть перед приложением Web и обеспечивают более широкие возможности по сравнению с тем, что в настоящее время могут предложить производители классических брандмауэров. WAF должен поддерживать разнообразные приложения Web и занять таким образом центральное место в корпоративном ландшафте ИТ. Отличие от классической технологии заключается в том, что WAF интерпретирует защищаемые приложения Web с их отдельными страницами, полями ввода, значениями параметров и маркерами Cookie.

Таким образом, WAF в состоянии контролировать объекты в вызываемом URL и параметры в запросе GET или POST, а также блокировать вредоносные запросы. В базовую функциональность должно входить обеспечение возможности вызова лишь таких URL, которые принадлежат приложению: система блокирует доступ ко всем другим ресурсам, находящимся в пределах целевого каталога на сервере Web, к примеру к системным журналам, сценариям и административным приложениям.

Дополнительно следует контролировать отклики и в случае необходимости блокировать их, поскольку описание ошибок в откликах может содержать важную информацию. Заголовок сервера, где в стандартной конфигурации сервера Web указан тип сервера (к примеру, сервер: Apache 2.0.54 (UNIX), mod_ssl/2.0.54 OpenSSL/0.9.7a DAV/2 SVN/1.2.0-dev), переписывается в отклике большинства WAF, чтобы злоумышленник не мог получить этих сведений таким простым способом.

ПЛЮС ИЛИ МИНУС

Возможны два подхода к решениям обеспечения безопасности — в соответствии с положительной и отрицательной логикой безопасности.

В последнем случае определяется лишь то, что запрещено — все остальное разрешено, как, например, в антивирусном сканере.

WAF снабжаются заранее составленными черными списками, содержащими схемы распространенных типов атак. Тем самым обеспечивается защита от многих известных атак, базирующихся на этих схемах, поэтому нет необходимости в знании и конфигурировании всех параметров. Чрезвычайно важная функция — исключение отдельных полей ввода перед проверкой для предотвращения неверных положительных распознаваний. В некоторых приложениях Web, к примеру в техническом дискуссионном форуме, при определенных обстоятельствах может понадобиться разрешение возможности ввода кодов HTML или сценариев.

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

WAF должен поддерживать комбинацию обоих типов логики. И наиболее эффективен WAF тогда, когда он может соответствующим образом интерпретировать приложение Web, т. е. положительная логика преобладает. Основой этого является создание свода правил, так называемой «политики». Возможны два подхода: динамический и статический.

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

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

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

Важная функция — анализ «кротом» JavaScript. Дополнительно должна быть предусмотрена возможность определения пути навигации, по которому может быть вызвана указанная страница. Если, к примеру, задано, что страница z.html должна быть достижимой лишь после того, как пользователь запросил сначала страницу x.html, а потом y.html, то WAF блокирует запрос непосредственно к z.html. В этом случае говорят о «потоках», для которых определяются объекты отправителя и получателя. Ряд производителей предлагают собственный браузер для тонкой настройки, который также оказывается полезен при формировании политики. Поскольку правило не должно генерироваться динамически, статический подход значительно более производителен.

Проверка того, было ли статическое значение в запросе HTTP несанкционированно изменено, для большинства WAF не представляет проблемы. Однако при использовании статического подхода WAF должны защищать также от изменений динамических значений, генерируемых на сервере. Это динамическое значение, генерируемое приложением во время выполнения, встречается, к примеру, в URL или в скрытых полях. Злоумышленник может просто изменить его и отправить в следующем запросе HTTP приложению Web. В результате, к примеру, товар будет помещен в корзину покупателя по более низкой цене (см.Рисунок 3).

Другие приложения для однозначной идентификации пользователя применяют идентификаторы сеанса, которые генерируются на сервере в качестве динамических параметров. Если злоумышленнику удается добраться до идентификатора сеанса другого пользователя, он получает доступ к пользовательскому сеансу и тем самым к его данным без знания имени пользователя и пароля. Для защиты ландшафта ИТ можно настроить WAF таким образом, чтобы он, к примеру, удалял этот динамический параметр из отклика.

Еще одна важная задача WAF — проверка маркеров Cookie. WAF должен предотвращать попадание в приложение Web модифицированных пользователем маркеров (Cookie Poisoning). Если злоумышленнику удастся это сделать, не исключено, что он, как и в предыдущем примере с идентификатором сеанса, попытается получить доступ к сеансу другого пользователя. Одним из вариантов проверки в WAF является помещение зашифрованных и подписанных имен и содержимого всех маркеров пользователя в дополнительном сеансовом маркере, который имеется только в памяти у клиента. Если маркеры передаются браузером приложению — как это происходит в случае каждого запроса HTTP, — WAF посредством дополнительного сеансового маркера распознает, изменил ли злоумышленник один или несколько маркеров. К сожалению, некоторые приложения меняют содержимое маркеров и на стороне клиента. Поэтому важно, чтобы маркеры таких приложений могли исключаться перед проверкой. Другой вариант — шифровать все маркеры приложений. При этом, как описано выше, отдельные маркеры могут перед шифрованием исключаться. Когда приложение изменяет на клиенте содержимое отдельного маркера, оно должно быть представлено открытым текстом.

Большинство WAF работают в качестве обратного посредника. Они принимают от клиента запрос HTTP вместо сервера Web или балансировщика нагрузки, анализируют его соответствие политике и организуют новое соединение HTTP, наделенное собственным IP-адресом, с сервером Web или балансировщиком нагрузки (см. Рисунок 4). Поэтому для регистрации IP-адресов отправителя на сервере Web необходимо, чтобы WAF мог передавать дальше исходный IP-адрес клиента, к примеру в заголовке X-Forwarded-For-Header (XFF). Терминирование SSL и аппаратное ускорение шифрования и дешифрования, включая согласование ключа, должно поддерживаться в любом фильтре приложений, иначе анализу оказываются доступны только незашифрованные данные. Пассивный режим мониторинга, когда запросы злоумышленника не блокируют, а только отмечаются в отчетах, полезен не только при вводе в эксплуатацию, но и в случае высокочувствительных приложений. Тем самым остается, по крайней мере, возможность получения информации обо всех атаках на приложение Web и сервер Web без прерывания работы приложения.

Первые коммерческие продукты WAF появились на рынке в 2000 г. Интерес к ним растет, так что технология будет распространяться дальше. Некоторые аналитики уже сейчас уверены в том, что рынки «доставки приложений на базе Web» и «брандмауэров для приложений Web» сольются, поскольку лежащая в их основе технология и позиционирование в сети очень похожи. Преимущества объединения в один продукт очевидны: более высокая производительность, меньшая стоимость и пониженные издержки на управление.

Альфредо Вистола — легализованный хакер (Certified Ethical Hacker, CEH) и архитектор в области систем обеспечения безопасности компании F5. С ним можно связаться по адресу: wj@lanline.awi.de.

Рисунок 1.

Фильтры пакетов должны пропускать соединения, необходимые для приложений Web, такие, как HTTP и SQL. Как результат, по этим каналам вполне вероятно проведение атак.

Рисунок 2.

Многоуровневая архитектура приложения Web.

Рисунок 3.

Процесс атаки на приложение Web.

Рисунок 4.

WAF может устанавливаться как в виде отдельного устройства, так и на имеющемся брандмауэре. Он либо размещается в одном сегменте с сервером Web, как изображено, либо в отдельной демилитаризованной зоне.

Таблица 1.

Перечень некоторых специальных символов.

Автор: Альфредо Вистола
Источник: www.morepc.ru