Главная » Отражение атак на уровне приложений
Фильтры пакетов оказываются бессильны, когда сталкиваются с такимиатаками на приложения 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.
Категория: Обеспечение безопасности | Просмотров: 185