- Безопасность веб-приложений
- Вандализм
- Финансовое мошенничество
- Привилегированный доступ
- Кража информации о транзакциях
- Кража интеллектуальной собственности
- Атаки «отказ в обслуживании»
- Организация процесса обеспечения качества
- Межсетевые экраны для веб-приложений
- Системы предотвращения вторжений
- Реализация SYN-прокси на межсетевом экране
- Специфические угрозы веб-среде
- Сбор информации
- Административные интерфейсы
- Аутентификация и управление доступом
- Управление конфигурациями
- Проверка входных данных
- Провека параметров
- Управление сеансами
Многие ситуации и угрозы, связанные с сетью Интернет и веб-приложениями, являются уникальными. К примеру, в сети Интернет нередко нужно учитывать угрозы, связанные с возможным вандализмом. Риски мошенничества при использовании веб-приложений значительно выше, что вызвано их всеобщей доступностью. С помощью Интернета, мы можем предоставить свой продукт или услугу максимально возможной аудитории. Наученные горьким опытом, мы размещаем веб-серверы в DMZ, поэтому злоумышленники, получившие несанкционированный доступ к этим веб-серверам, не получат прямого доступа к ресурсам нашей внутренней сети. Но мы вынуждены разрешать доступ к веб-серверам через Интернет по портам, на которых работают наши веб-приложения (обычно 80 и 443), чтобы пользователи могли их использовать. Для этого мы открываем указанные порты на межсетевом экране, а это позволяет проводить атаки на веб-сервера через эти порты.
Сами приложения часто являются сложными и непонятными для интернет-продавцов. Если вы хотите продавать через Интернет домашние пироги, вам нужно будет разместить на сайте их фотографии, цены, указать способы связи с вами (телефон, электронная почта). Вам понадобится создать на сайте некую корзину для покупок, если вы собираетесь брать деньги за свои пироги, для этого вам потребуется работать с соответствующими сервисами доставки и обработки платежей... И все это для того, чтобы просто продавать пироги! Но если вы просто пекарь, вы вряд ли являетесь веб-мастером, поэтому вам придется положиться на кого-то, чтобы он создал и настроил веб-сайт для вас и установил необходимые приложения. Нужно ли вам разрабатывать для этого собственное веб-приложение на PHP или JAVA? У созданного специально для вас приложения может быть много преимуществ, т.к. оно будет максимально автоматизировать именно ваш бизнес, но нужно учитывать и риски, связанные с разработкой собственного приложения (особенно, если вы сталкиваетесь с этим впервые), а также сложность процессов и методологии, которые нужно будет организовать для этого: собственно процесс разработки, управление изменениями, управление версиями. Кроме того, нужно будет заняться выявлением уязвимостей и оценкой рисков... Стоит ли все это того, чтобы просто продавать пироги? Теперь вы понимаете, почему многие просто продают их у обочины дороги – никакой головной боли от веб-приложений!
Альтернативой разработке собственных веб-приложений является использование различных уже готовых продуктов. Существует множество коммерческих и бесплатных продуктов почти для любого вида электронной торговли. Они написаны на различных языках программирования, разными компаниями и частными лицами, но кому мы можем верить? Есть ли у этих разрабочиков процессы, о которых мы говорили выше? Учитывались ли надлежащим образом вопросы безопасности при разработке и тестировании этих приложений? Какие уязвимости есть в этих приложениях? Понимает ли наш веб-мастер, рекомендующий использовать определенное приложение, все связанные с ним риски безопасности? Теми же проблемами озабочены не только те, кто хочет продавать через Интернет пироги, но и финансовые организации, различные аукционы – все, кто занимается электронной коммерцией.
Помня обо всех этих вопросах, давайте попробуем определить наиболее опасные угрозы, связанные с использованием веб-сервера, подключенного к Интернету.
Эта атака, как правило, представляет собой изменение злоумышленником размещенного на веб-сайте контента – текста, заголовков, графики. Вам может показаться удивительным, что одной из угроз вашему сайту является вандализм. На самом деле, многие скрипт-кидди взламывают сайты исключительно в целях самоутверждения. Взлом вашего магазина пирогов может быть не столь впечатляющим для хакерской элиты, как дефейс сайтов *.gov или *.mil, но защищать нужно любой сайт. Здесь следует также учитывать и возможный репутационный риск: хотя многие технически грамотные клиенты смогут понять, что хакерам удалось изменить только текст на главной странице вашего сайта, но все остальные будут считать, что хакеры получили доступ ко всей базе данных ваших клиентов. Помните об общественном мнении!
Деньги – сильный мотиватор для тех, кто хочет получить что-нибудь бесплатно. При проведении финансовых операций, существуют потенциальные возможности для мошенничества, особенно в анонимной среде, такой как Интернет. При этом люди, которые не осмелятся украсть газету в сломанном торговом автомате в общественном месте, легко пойдут на совершение кражи товаров и услуг через Интернет.
Сеть Интернет и ее участники распределены по всей планете. Организуя свою торговлю пирогами через Интернет, ваши сотрудники, которые будут печь пироги реально могут жить в Талсе, веб-мастер может жить в Сингапуре, а серверы, на которых будет размещен ваш сайт, физически будут находиться в Лондоне. При этом должен быть создан механизм, позволяющий выполнять удаленное администрирование вашего сайта, что несет в себе риск того, что кто-то другой получит административные полномочия в вашей системе. Если злоумышленник получит административный доступ, вы больше не сможете доверять системе, журналам регистрации событий и транзакциям.
Для получения денег, доставки товаров, а также чтобы просто отличать одного клиента от другого, вам потребуется собирать и хранить данные ваших клиентов. Разумеется информация о транзакциях будет мишенью для хакеров, которые будут пытаться похитить идентификационные данные клиентов, данные их платежных карт, чтобы продавать эту информацию организованным преступным группировкам, либо использовать ее самостоятельно для совершения мошеннических действий.
Если веб-сервер будет взломан, он может быть использован для атаки на внутреннюю сеть и любую подключеную к ней систему. Получив доступ к веб-серверу, атакующий находится всего в шаге от баз данных и файлового хранилища, где хранятся все секреты компании. Можете ли вы позволить себе потерять свое конкурентное преимущество?
Одной из старейших в репертуаре хакеров атак является атака «отказ в обслуживании» (DoS-атака – Denial-of-Service attack). Это простая, но эффективная методика подавления системы или службы, основанная на отправке ей огромного количества запросов на соединение, что перегружает ее ресурсы и каналы связи, не позволяя реальным запросам дойти до веб-сервера. Некоторые виды DoS-атак вызывают сбой системы или службы, их переход в неуправляемое состояние и не позволяющее обрабатывать поступающие запросы – не очень хорошее состояние для веб-сервера.
Как мы уже говорили выше, веб-серверы и работающие на них веб-приложения обычно широко доступны, ведь мы хотим, чтобы пользователи имели к ним доступ из любого места на планете. Раньше широкую огласку получали случаи выявления уязвимостей программного обеспечения самих веб-серверов (напимер, Microsoft IIS 4.0), большинство современных атак направлено на веб-приложения, работающие на самом верхнем – прикладном – уровне. При этом, в процессе проведения атаки, чтобы усложнить ее выявление, на веб-сервер часто направляется множество запросов, что существенно затрудняет или делает невозможным журналирование событий (и, конечно же, их последующий анализ). Межсетевые экраны разрешают трафик, поступающий на 80-й порт вашего веб-сервера, т.к. это необходимо для его работы. Некоторые веб-мастеры считают, что использование для всех соединений пртокола SSL (Secure Sockets Layer), работающего на 443-м порту, обеспечит их защиту. Однко использлвание SSL позволит только шифровать передаваемый трафик и защитит его от перехвата, но шифроваться при этом будет в том числе и трафик злоумышленника, скрывая его от систем выявления вторжений и не позволяя ничего сделать для защиты самого веб-приложения. Если система выявления вторжений размещается в DMZ, то анализ ее журналов регистрации событий займет все рабочее время нескольких сотрудников. К тому же, если это стандартный IDS уровня сети, он в любом случае не окажет существенной помощи. Это, конечно, не означает, что не нужно выполнять журналирование событий, использовать SSL, межсетевые экраны и системы IDS, это означает только, что эффективность каждого из этих защитных механизмов должна быть оценена с точки зрения стратегии обеспечения безопасности вашей компании.
Ниже рассмотрен ряд защитных мер и средств, позволяющих снизить риски безопасности для веб-приложений, которые могут использоваться в дополнение к рассмотренным выше мерам и средствам.
Процесс обеспечения качества (quality assurance process) довольно эффективен для обеспечения уверенности в том, что серверы, на которых размещены ваши веб-приложения, настроены должным образом. Даже самые безопасные веб-приложения могут быть взломаны через уязвимости операционной системы. Указанный процесс должен учитывать все особенности сервера, начиная от установки обновлений операционной системы и программного обеспечения веб-сервера, удаления нежелательных сервисов, ненужной документации и библиотек. Чтобы убедиться, что система отвечает установленным требованиям, проводят его внешнее (из сети Интернет) и внутреннее (из локальной сети) сканирование, что должно быть сделано до перевода системы в промышленную эксплуатацию.
В отличие от традиционных межсетевых экранов, которые смотрят только на адреса получателя / отправителя и номера портов, межсетевые экраны прикладного уровня выполняют глубокий анализ пакетов, что позволяет им выявлять и блокировать определенное поведение, связанное с проведением атак, а также аномалии и нежелательные команды протоколов (например, команду POST в протоколе HTTP).
Система предотвращения вторжений (IPS – Intrusion Prevention System), в отличие от систем выявления вторжений (IDS), может реально предотвращать выявленные ей атаки. Такие системы обычно устанавливаются «в разрыв» (inline), т.е. весь трафик проходит через них и проверяется, прежде чем он достигнет серверов, размещенных за системой IPS. Это может вызвать сложности с точки зрения производительности, что, как правило, приводит к увеличению стоимости и аппаратных требований. Некоторые считают, что такие системы являются расширенными вариантами систем IDS.
Наиболее распространенным вариантом DoS-атак является SYN-флуд. При проведении атаки SYN-флуд атакующий отправляет поддельные запросы на соединение (пакеты SYN) на сервер, пытаясь перегрузить его и не позволить обслуживать запросы реальных пользователей. После получения от злоумышленника пакетов SYN, сервер будет в течение определенного периода времени ждать завершения фиктивных соединений (которые, конечно, никогда не завершатся), а запросы реальных пользователей будут игнорироваться сервером.
Реализация SYN-прокси на межсетевом экране позволит ему управлять подключениями к серверу. SYN-прокси постоянно контролирует количество запросов SYN в единицу времени и сравнивает его с заранее определенным пороговым значением (например, 500 в секунду). Если пороговое значение было достигнуто, а запросы все продолжают поступать, межсетевой экран может удалить самые старые из запросов, по которым так и не было установлено соединения, тем самым позволяя серверу продолжать обслуживать запросы на подключения от реальных пользователей. Не все межсетевые экраны имеют такую функциональность, обычно для этого нужны межсетевые экраны, поддерживающие «таблицы состояний» для соединений.
Все эти решения являются прекрасными, но в основе всего этого остается веб-приложение. Истинная безопасность веб-приложений должна начинаться с разработки и внедрения безопасных прикладных сервисов и позволять использовать другие виды защитных механизмов для снижения рисков. Теперь мы более детально рассмотрим отдельные угрозы и уязвимости, связанные с этой темой.
В следующих разделах рассматриваются наиболее распространенные виды уязвимостей, угроз и возникающих сложностей в веб-среде. Будут рассмотрены следующие аспекты:
- Сбор информации
- Административные интерфейсы
- Аутентификация и управление доступом
- Управление конфигурациями
- Проверка входных данных
- Проверка параметров
- Управление сеансами
Сбор информации (information gathering) является, как правило, первым шагом в методологии злоумышленника. Собранная информация может позволить злоумышленнику сделать выводы (догадаться) о дополнительной информации, которая может быть использована им для нарушения безопасности систем. К сожалению, значительную часть информации можно получить из общедоступных источников. Крупные поисковые системы упрощают злоумышленнику задачу сбора информации, поскольку они накапливают информацию, хранят ее в своих кэшах и могут возвращать результаты поиска из кэша поисковой системы, что не требует не только выполнения атаки, но даже подключения к целевому веб-серверу компании.
В большинстве случаев виновными в раскрытии информации оказываются разработчики и веб-администраторы сервера, которые просто пытаются делать свою работу. Комментарии в исходном тексте программы, указанные разработчиком для пояснения работы процедур, или файлы резервных копий, которые администратор хранит на самом веб-сервере, сами по себе не являются вопиющими проблемами безопасности, но если злоумышленник получит доступ к ним, они помогут ему узнать гораздо больше, чем хотелось бы компании. Даже сообщения об ошибках, возвращаемые сервером в ответ на некорректные запросы, могут содержать физический путь к базе данных, номер версии сервиса и т.п., что может быть использовано злоумышленником в качестве отправной точки для получения несанкционированного доступа к системе.
Более профессиональные атакующие выходят за пределы поисковых систем, чтобы изучить содержимое всех доступных файлов на сервере в поисках возможных ключей к пониманию структуры внутренней сети или строк соединений, используемых веб-сервером для подключения к серверу базы данных.
Для того чтобы веб-сервер предоставлял активное содержимое и единый интерфейс, что необходимо современным веб-пользователям, серверы должны обращаться к источникам данных, обрабатывать код и возвращать результаты веб-клиентам. Для работы этих механизмов, должен быть написан соответствующий код и передан веб-браузеру в соответствующем формате. Одной из технологий, позволяющей веб-разработчикам повторно использовать одно и то же содержимое, вставляя его в несколько веб-документов, является SSI (Server Side Includes - Включения на стороне сервера). Обычно это предполагает использование включения в код необходимых команд и информации из файлов (.inc). Однако если к этим файлам получит доступ злоумышленник, то он сможет увидеть код и измененить его для «включения» других файлов, содержащих критичную информацию. Другие технологии, такие как ASP (Active Server Pages - Активные серверные страницы) (страницы с расширением файла *.asp) используются для создания «активной» пользовательской среды. Эти файлы могут раскрыть любой содержащийся в них критичный код, если есть возможность их просмотра. Разработчики должны избегать размещения критичного кода в файлах SSI или ASP (например, строки подключения к базе данных или текст программы, реализующий бизнес-логику, которая является объектом интеллектуальной собственности), при этом даже в случае, если злоумышленник сможет получить доступ к такому файлу, в нем не будет ничего важного. В прошлом уже было найдено множество уязвимостей, позволяющих получить доступ к таким файлам, поэтому есть все осования полагать, что риск их прочтения злоумышленником достаточно велик.
Другим советом, позволяющим разработчикам предотвратить раскрытие физического размещения компонентов или паролей, используемых для подключения к базе данных, является использование имени источника данных (DSN – Data Source Name). Это логическое имя хранилища данных, а не буква диска и каталог, в котором размещена база данных. Такое логическое имя может быть использовано при программировании для интерфейса ODBC. При использовании ODBC DSN для хранения таких значений, хранение реальных физических путей осуществляется в реестре системы, а не в коде программы. Кроме того, эта технология упрощает изменение кода, поскольку при этом строки соединений являются переменными, хранящимися в системном реестре. Поэтому это является хорошей практикой.
Основной контрмерой против методов сбора информации является попытка сделать так, чтобы атакующий мог получить только ту информацию, которую вы осознанно делаете общедоступной, либо минимально ограничиваете ее доступность. Разработчики должны понимать, что существует потенциальная возможность, что их код будет просмотрен кем-то за пределами компании, а администраторы должны регулярно проверять ссылки поисковых систем на веб-сайты компании, адреса электронной почты, ссылки на файлы и хранилища данных. Многие веб-сайты и целые книги посвящены вопросам сбора информации из общедоступных баз данных, поэтому такие проверки будут хорошим примером проявления должной осмотрительности.
Каждый хочет работать из кафе или из дома, сидя в пижаме за собственным компьютером. Веб-мастера и веб-разработчики особенно любят такую работу. В некоторых системах установлены жесткие ограничения, позволяющие выполнять администрирование только с локального терминала, однако в большинстве систем таких ограничений нет, и интерфейс для администрирования системы предоставляется удаленно, в том числе через Интернет. Хотя это может быть очень здорово и удобно для веб-мастеров, это также является точкой входа в систему для неуполномоченных пользователей.
В большинстве случаев, использование административного веб-интерфейса является плохой идеей. Он может использоваться только в том случае, если определены его уязвимости, для них реализованы защитные меры, делающие административный веб-интерфейс не менее (а лучше даже более) безопасным, чем само администрируемое через него веб-приложение, приняты остаточные риски, на которые компания готова осознано пойти.
Очень плохой привычкой, которая иногда оказывает свое влияние даже в условиях повышенной безопасности, является жесткое указание в коде аутентификационной информации для соединений с интерфейсами управления или предоставление опции «Запомнить пароль». Это упрощает жизнь администратора, но дает слишком много прав доступа тому, кто получает эту информацию вопреки желанию администратора.
Но давайте смотреть фактам в лицо, большинство коммерческого программного обеспечения и серверов веб-приложений по умолчанию устанавливают те или иные виды административной консоли. Знания этого факта и методов сбора информации, рассмотренных выше, должно быть вполне достаточно для компании, чтобы всерьез рассматривать связанные с этим угрозы. Если интерфейс не нужен, он должен быть отключен. Если он нужен, следует рассмотреть вопросы его использования в политике и процедурах компании.
Простой контрмерой против этой угрозы является простое удаление или блокирование внешних интерфейсов управления, но это может расстроить ваших администраторов. Если внешние интерфейсы управления все же необходимы, следует использовать механизмы строгой аутентификации, это значительно лучше, чем просто имя пользователя и пароль. Другим хорошим вариантом является настройка ограничений на подключение к административным интерфейсам. Многие системы позволяют настроить разрешения доступа только для конкретных IP-адресов или сетевых идентификаторов, при этом возможность использования административных интерфейсов будет предоставляться только с этих компьютеров.
И, наконец, наиболее безопасным вариантом является интерфейс управления, доступ к которому предоставляется только по отдельному соединению, вне основного диапазона адресов, для подключения к которому используется отдельный канал связи. Это позволяет избежать влияния любых уязвимостей, присутствующих в среде, в которой работает система. Примером такого канала является использование модема, подключенного к веб-серверу, через который можно подключиться напрямую и выполнить настройку сервера с помощью его локального интерфейса, вместо подключения через Интернет и выполнения настроек с помощью веб-интерфейса. При этом такое модемное соединение должно осуществляться по шифрованному каналу, например, с использованием SSH.
Если вы уже имеете опыт использования систем дистанционного банковского обслуживания, онлайн-покупок, использования сервисов дистанционного обучения, вам наверняка приходилось не раз регистрироваться в веб-приложениях. Как для клиента, так и для поставщика услуги, тема аутентификации и управления доступом является очевидной проблемой. Клиенты, конечно, хотят, чтобы механизмы управления доступом обеспечивали безопасность и конфиденциальность, они хотят работать в доверенной среде, но при этом они совершенно не хотят, чтобы этот процесс был обременителен для них самих. С другой стороны, провайдер услуги хочет обеспечить максимальный уровень безопасности для клиента, насколько позволяет производительность используемого оборудования и программного обеспечения, действующие требования и бюджет. В результате, для доступа к веб-приложениям, как правило, по-прежнему используются имена и пароли.
Причиной, по которой пароли остаются самым распространенным способом аутентификации, является доступность. Безусловно, доступность – это прекрасно, но только если все использующие ваш сайт являются законными пользователями. Однако доступность, при которой любой злоумышленник может анонимно получить несанкционированный доступ к вашему сайту, уже совсем не прекрасна. Пароли не могут обеспечить многого. Они продолжают использоваться, поскольку они остаются дешевым и достаточно эффективным способом аутентификации, но реально они не могут гарантировать, что пользователь «Jsmith» на самом деле является Джоном Смитом, они просто говорят о том, что лицо, использующее учетную запись Jsmith, ввело правильный пароль. Но это может быть кто угодно! Разве вы сами никогда не использовали чужую учетную запись для каких-либо целей?
Было бы вполне логично предположить, что система, на которой хранится критичная информация (медицинская, финансовая и т.д.), может стать мишенью для атак. Распространенной практикой является сбор имен пользователей через поисковые системы с последующей попыткой использования их для входа в веб-приложения, либо использование для этих целей часто встречающихся имен (таких как, Ivanov). Кроме того, пользователи слишком часто при регистрации на различных сайтах используют одни и те же имя и пароль. Вспомните, какие учетные данные вы использовали последний раз, когда регистрировались на каком-нибудь сайте, чтобы просто скачать какой-нибудь бесплатный документ? Атакующие могут создавать веб-сайты специально для того, чтобы собирать через них имена и пароли пользователей. Такие сайты могут выглядеть вполне дружественно и безобидно, предлагая вам узнать свой IQ, прочитать чужие SMS, поучаствовать в лотерее, но их реальная цель – сбор учетных данных, которые затем будут использоваться злоумышленниками для попытки регистрации на других ресурсах. Помните, что необученный и неосведомленный о таких угрозах пользователь является большой угрозой для компании!
Еще одним слабым местом аутентификации (особенно, если используются пароли) является то, что злоумышленники (также, как и законные пользователи) могут блокировать учетные записи, выполняя последовательно несколько попыток входа с неправильным паролем. Система, настроенная в соответствии с рекомендациями по противодействию подбору паролей, после нескольких неудачных попыток регистрации автоматически заблокирует учетную запись. Противодействие подбору паролей, безусловно, также необходимо для веб-приложений, как и для традиционных приложений. Блокировка учетных записей при выявлении попыток подбора пароля является эффективной контрмерой. Но представьте, что перебор осуществляется не для паролей, а для имен пользователей. Если злоумышленник последовательно пытается войти в систему под каждой учетной записью, используя при этом неправильные пароли, фактически он заблокирует учетные записи всех пользователей. Каковы будут последствия, если несколько тысяч клиентов банка, использующие систему интернет-банкинга, вдруг не смогут войти в систему? Справится ли служба технической поддержки с таким потоком звонков и заявок? Это может привести к пересмотру политики вашей компании в отношении создания учетных записей и сброса паролей. Как вы будете проводить аутентификацию пользователей, забывших свой пароль? Какой пароль вы установите при сбросе забытого пароля? Вы будете использовать пароль по умолчанию при создании новых учетных записей? Все это должно быть определено в политике и процедурах. Помните, что общий уровень вашей безопасности равен уровню безопасности самого слабого звена.
Решением для защиты от массированной атаки на учетные записи с целью их блокировки может быть только использование временной блокировки учетных записей, т.е. после нескольких неудачных попыток регистрации учетная запись блокируется на ограниченное время (от 30 минут для сайтов с низким риском, до трех часов или даже до суток для сайтов с высоким уровнем рисков), после чего она автоматически разблокируется. Ваша компания должна определить, какой уровень риска она готова принять. Использование механизмов многофакторной аутентификации не обязательно исключит атаки такого типа, однако это позволит значительно повысить защиту от несанкционированного доступа и сделает его менее вероятным.
Чтобы выявить атакующую систему (или системы), следует анализировать журналы регистрации событий, хотя это вряд ли будет реальный компьютер, принадлежащий злоумышленнику. Анализ журналов регистрации событий позволит вам увидеть сам факт атаки – вы увидите многочисленные попытки регистрации, исходящие от отдельного компьютера (или нескольких компьютеров). Это поможет вам внести соответствующие изменения в правила межсетевого экрана и других систем безопасности.
И наконец, хорошей практикой является обмен всей аутентификационной информацией с использованием защитных механизмов. При этом, как правило, выполняется шифрование паролей и учетных данных, либо шифрование всего канала связи. В наше время было бы неразумно использовать незащищенный доступ на критичный веб-сайт, т.к. преимущества от реализации доступа посредством SSL значительно превышают стоимость покупки сертификата для своего веб-сайта и расходы на дополнительную обработку, связанную с зашифрованием и расшифрованием информации на каждой стороне. Некоторые крупные сайты, предоставляющие критичные сервисы, продолжают работать без выполнения шифрования информации аутентификации и подвергают себя и своих пользователей угрозе, поскольку злоумышленники могут перехватить имена пользователей и их пароли.
Управление конфигурациями (configuration management) – это просто концепция управления конфигурациями ваших систем. Учетные записи по умолчанию и их пароли, файлы примеров в системе, а также интерфейсы управления – все это должно быть выявлено и учтено при определении базовых требований безопасности в веб-среде. Прежде чем система будет переведена в промышленную эксплуатацию, должна быть проведена проверка ее соответствия действующей политике. Хотя, конечно, на практике такой подход используется не часто.
На практике, при разработке веб-приложений, обычно все ограничивается тем, что разработчик устанавливает приложение в «тестовую» среду, которая эмулирует промышленную среду (с такой же операционной системой и веб-сервером), после чего разработчик пишет код, проверяющий функциональность приложения, и готовит отчет об успешном тестировании. По результатам этого тестирования, без каких-либо дополнительных проверок, приложение переносится в промышленную эксплуатацию. При этом очень распространенной ошибкой является дальнейшее использование тестовой среды, в которой была проверена работоспособность приложения, в качестве промышленной среды. Конечно, приложение в такой среде точно будет работать, однако нужно понимать, что разработчик почти наверняка создавал тестовую среду без учета даже минимальных требований безопасности, необходимых для промышленной среды. Слишком часто в процессе тестирования веб-приложений основное внимание уделяется доступности, а не целостности и конфиденциальности. Все думают (ошибочно): «Давайте сначала посмотрим, работает ли это приложение вообще, и тогда уже будем ограничивать его функциональность». Но про необходимость ограничений потом забывают, что часто становится причиной компрометации системы.
Если у компании нет своей собственной команды разработчиков и она просто покупает приложение, она должна реализовать процесс, позволяющий выявить уязвимости этого приложения и убедиться в том, что приложение внедрено безопасно. Приложения, которые просто были установлены с использованием настроек по умолчанию, редко бывают безопасными. Многие приложения при установке по умолчанию создают административные учетные записи со стандартными паролями, известными хакерскому сообществу. Они устанавливают страницы ошибок с подробной информацией и файлы примеров, предназначенные для помощи в процессе внедрения, что часто является слабостью, которой могут воспользоваться злоумышленники. Вас может удивить, разве атакующий сможет найти все эти вещи на вашем веб-сервере? Ответ на этот вопрос вы можете найти в вашей любимой поисковой системе.
Поисковые системы (например, Google) очень хорошо анализируют веб-страницы и ссылки в них, они проходят по всем ссылкам и заносят в свой каталог все, что могут найти. Это отличная возможность, поскольку она значительно упрощает поиск кулинарных рецептов или цитат из фильмов, но этой возможностью могут воспользоваться и хакеры, которые используют хитро сформулированные поисковые запросы, позволяющие им найти интерфейсы управления, страницы ошибок со сведениями о конфигурации, а иногда и разделы вашего сайта, которые вы не собирались выставлять на всеобщее обозрение.
Решением всех этих проблем является наличие четких политик и процедур. Процедуры должны предусматривать обязательное удаление создаваемых по умолчанию настроек, учетных записей и паролей, своевременное применение патчей безопасности, выпускаемых производителем. При переносе приложения из тестовой среды в промышленную, следует удалять или пересматривать все заполненные на этапе тестирования списки контроля доступа (ACL) в приложении, что позволит обеспечить правильное разграничение прав доступа (в особенности к критичным файлам и данным) и надлежащий уровень безопасности. Перед началом промышленной эксплуатации новой системы, из нее должно быть удалено все, к чему вы не хотели бы давать доступ всему миру через поисковые системы. В частности, следует удалить файлы документации, файлы примеров и стандартные страницы ошибкок.
Веб-серверы не такие умные, они просто делают то, что им говорят. Они предназначены для обработки запросов, переданных посредством определенного протокола. Термин «протокол» означает правила, которым нужно следовать в определенной ситуации, чтобы выполнять необходимые коммуникации. Пользователь использует веб-браузер. Когда он вводит в адресную строку http://www.website.com/index.htm и нажимает Enter, он используют протокол HTTP (Hypertext Transfer Protocol), чтобы запросить файл «index.htm» с сервера «www» в пространстве имен «website.com». Запрос в такой форме называется URL (Uniform Resource Locator - Единый указатель ресурсов), он похож на то, как мы говорим (ну, по крайней мере, мы можем легко прочитать его). Как и во многих других случаях, в компьютерном мире существует несколько различных способов оформления такого запроса, поскольку компьютеры могут «говорить» на нескольких различных «языках» (используя, например, двоичную, шестнадцатеричную и другую кодировку), каждый из которых интерпретируются и обрабатывается системой в качестве команд. Проверка таких запросов являются частью проверки входных данных (input validation), обычно она связана с некоторыми запрограммированными правилами проверки. Тот факт, что эти правила должны быть заранее запрограммированы в коде программы означает, что вероятно могут существовать некоторые «хитрые» запросы, которые могут обойти такие правила проверки.
Вот некоторые такие хитрые примеры:
- Обход пути или каталога (Path or directory traversal). Эту атаку иногда называют «dot dot slash», поскольку она выполняется путем многократной вставки символов «../» в адрес URL для прохода в каталоги, которые не должны быть доступны из сети Интернет. Команда «../» в командной строке говорит системе, что нужно вернуться в предыдущий каталог (попробуйте в командной строке набрать, «cd ../»). Если каталогом по умолчанию веб-сервера является «C:\Inetpub\WWW», передача ему URL-запроса «http://www.website.com/scripts/../../../../../windows/system32/cmd.exe?/C+dir+C:\» даст ему команду вернуться на несколько каталогов выше, проходя весь путь до корневого каталога диска, а затем перейти в каталог операционной системы (Windows\System32), запустить утилиту cmd.exe и вывести содержимое диска «С:».
- Кодировка Unicode (Unicode encoding). Unicode – это стандартный механизм, разработанный для того, чтобы позволить использовать весь диапазон возможных символов (языки разных стран используют суммарно более 100 000 текстовых символов). Unicode поддерживает различные наборы символов (например, китайский), и, в настоящее время, многие приложения поддерживают его по умолчанию. Если мы внесли в настройки наших систем запрет на обработку команд «../» в запросах для описанного выше обхода каталогов, злоумышленник может воспользоваться кодировкой Unicode, чтобы дать веб-серверу ту же команду «/», но с использованием одного из вариантов Unicode-представлений этого символа (существует три: %c1%1c, %c0%9v и %c0%af). Такой запрос может проскользнуть незамеченным и будет обработан веб-сервером.
- Кодирование URL (URL encoding). Может быть, вы когда-нибудь обращали внимание, что в адресной строке веб-браузера «пробел» преобразуется в «%20» (шестнадцатиричный код символа «пробел»), поскольку «пробел» не является допустимым символом в запросе URL. Аналогично атаке с использованием Unicode-символов, злоумышленник может использовать представление символов в виде их кодов, чтобы обойти фильтрацию и передать серверу нужный запрос.
Переполнение буфера – это, пожалуй, наиболее известная ошибка проверки входных данных. Буфер – это область, зарезервированная приложением для хранения в ней неких данных, таких как пользовательский ввод. После получения входных данных приложением, указатель команд говорит приложению, что нужно делать с полученными данными, сохраненными в буфере. Переполнение буфера происходит в тех случаях, когда приложение ошибочно принимает неправильные входные данные, объем которых превышает объем отведенного под них буфера, что приводит перезаписати указателя команд в коде. Это позволяет выполнить любой код, на который теперь ссылается указатель команд (например, код, переданный приложению в качестве пользовательского ввода и теперь находящийся в буфере), причем этот код будет выполнен в контексте безопасности приложения.
Проверка на стороне клиента (client-side validation) – это контроль входных данных, выполняющийся клиентской частью приложения перед их передачей на сервер для обработки. Например, если при заполнении веб-формы вы пропустили какое-то важное поле, при нажатии кнопки подтверждения ввода вы сразу же получите сообщение об ошибке, информирующее вас, что вы забыли заполнить одно из обязательных полей. Это пример проверки, выполняющейся на стороне клиента. Это гораздо лучше, чем передавать неполные данные на сервер, чтобы затем получить от него такую же ошибку. Проблема возникает в тех случаях, когда проверка на стороне клиента является единственной проверкой данных. В таком случае сервер надеется, что клиентская часть приложения хорошо сделала свою работу и уже убедилась, что введенные данные – правильные. В обычной ситуации этого действительно должно быть достаточно. Однако, если злоумышленник может перехватить трафик между клиентом и сервером и внести в него изменения, либо просто напрямую передавать некорректные запросы на сервер без использования клиентской части, нарушение безопасности весьма вероятно.
В системе, в которой достаточно слабо реализованы проверки входных данных, злоумышленник будет пытаться вводить нужные ему команды операционной системы в поля ввода вместо значений, которые эта система ожидает получить (например, вместо имени пользователя и пароля), пытаясь обмануть систему и заставить ее выполнить эти команды. Помните, что компьютеры делают то, что им говорят, поэтому, если злоумышленник сможет получить возможность запуска команд операционной системы, они выполнят их, поскольку будут считать, что их запуск инициирован самим приложением. Если веб-приложение обращается к базе данных, в большинстве случаев существует угроза выполения SQL-инъекций (SQL-Injection), когда вместо правильных входных данных злоумышленник помещает в поля ввода команды для работы с базой данных, которые при получении разбираются и выполняются приложением. SQL-выражения могут быть использованы злоумышленником, в частности, для обхода аутентификации и получения всех записей в базе данных.
Помните, что различные уровни системы (см. Рисунок 9-18) имеют собственные уязвимости, которые должны быть выявлены и исправлены.
Рисунок 9-18. Атаки могут происходить на различных уровнях
Похожим образом выполняются атаки межсайтового скриптинга (XSS – cross-site scripting), которые пришли на смену переполнению буфера в качестве самой большой угрозы для веб-приложений. XSS-атака – это атака, для выполнения которой злоумышленник отыскивает на веб-сайте уязвимость, которая позволит ему внедрить вредоносный код в веб-приложение. При этом этот вредоносный код может быть выполнен в веб-браузером ничего не подозревающих пользователей, как только они зайдут на этот сайт. Отключение в настройках браузера пользователя выполнения любых сценариев легко решило бы эту проблему, но тогда пользователь не смог бы работать со множеством веб-приложений.
Все эти атаки, рассмотренные в этом разделе, связаны ошибочным предположением разработчиков, что входные данные всегда корректны. Эффективными контрмерами для борьбы с этой проблемой являются фильтрация всех запросов для выявления в них заведомо «вредоносных», применение правила не доверять входящей информации от пользователя без ее предварительной тщательной проверки, внедрение строгой политики, обеспечивающей обязательное включение необходимых проверок входных данных во всех приложениях.
Вопрос проверки параметров сродни вопросу проверки входных данных, рассмотренному ранее. Проверка параметров (parameter validation) – это проверка полученных приложением значений на предмет их нахождения в определенном диапазоне, перед тем, как передать их серверу приложения для обработки. Основное отличие проверки параметров от проверки входных данных заключается в том, что проверяются значения, полученные из переменной среды, определенной приложением, а не данные, введенные пользователем. Проверка параметров нужна для противодействия атакам, связанным с манипулированием значениями, которые может настраивать пользователь, и которые система учитывает в процессе своей работы. В основном это относится к настройкам, изменение которых не предусмотрено интерфейсом приложения. Никому нельзя слепо доверять, тем более если речь идет о компьютерах, у которых нет здравого смысла, которым наделены люди.
Чтобы создать приложение для широкого круга пользователей, разработчики веб-приложения должны использовать механизмы для отслеживания тысяч пользователей, которые могут подключаться к приложению в любое время. Протокол HTTP сам по себе не позволяет управлять состоянием пользовательских соединений, фактически, они просто подключаются к серверу, получают нужные им объекты (файлы *.htm, графические файлы и т.д.), запрошенные в коде HTML (HTTP Markup Language), а потом отключаются (либо соединение завершается по таймауту). Но если браузер пользователя сразу отключается от сервера, как сервер сможет распознать того же пользователя, когда он вернется? Вероятно, пользователь будет сильно раздражен, если ему придется повторно вводить все свои данные только из-за того, что он слишком долго смотрел список рейсов, чтобы забронировать через Интернет билет на самолет, и соединение его браузера с веб-сервером завершилось по таймауту. Чтобы этого не случилось, веб-разработчики используют куки, которые передаются клиенту, чтобы потом по ним сервер мог «вспомнить» этого клиента и все сведения о состоянии соединения с ним. Куки (cookie) – это не программа, это просто набор данных, которые передаются веб-браузеру пользователя и хранятся в памяти браузера (так называемые сеансовые куки), либо локально на компьютере пользователя в виде файла (называемые постоянными куки), чтобы в любой момент передать информацию о состоянии подключения пользователя обратно на сервер. Примером использования куки является корзина покупок на сайте интернет-магазина. Когда вы кладете покупки в вашу виртуальную корзину, соответствующие сведения передаются вашму веб-браузеру путем обновления сеансового куки на вашей системе. Такие сайты не могут работать без использования куки.
Поскольку сеансовые куки хранятся в памяти, как правило, большинство пользователей не может получить к ним доступ, поэтому веб-разработчики при проектировании систем часто не считают, что эти куки могут представлять серьезную угрозу. К примеру, разработчки часто реализуют функцию блокировки учетной записи после определенного числа неудачных попыток регистрации (то, о чем мы говорили ранее). Если разработчик реализует эту функцию таким образом, что она хранит количество оставшихся у пользователя попыток входа в сеансовом куки, может возникнуть уязвимость. В таком случае, если приложение настроено на блокировку учетной записи после трех неудачных попыток входа, сервер может передать клиенту сеансовый куки, записав в него значение, типа «Допустимое количество входов = 3». После каждой неудачной попытки, сервер уменьшает это количество в куки пользователя на единицу. Когда оставшееся количество становится равным нулю, пользователь перенаправляется на страницу с указанием, что «Ваша учетная запись заблокирована».
Злоумышленник может перехватить и внести изменения в передаваемую между браузером пользователя и веб-сервером информацию, используя для этого программное обеспечение, называемое веб-прокси (web proxy). Существуют свободно распростроняемое, общедоступное программное обеспечение веб-прокси (например, Achilles или Burp Proxy), которым он может воспользоваться для этих целей. Когда сервер передает пользователю сеансовый куки, в котором записано «Допустимое количество входов = 3», злоумышленник перехватывает эту информацию с помощью такого веб-прокси и изменяет значение, например, на 50000. Это позволит ему эффективно выполнить брутфорс-атаку и подобрать пароль пользователя, если эта система не использует дополнительные механизмы проверки.
Использование веб-прокси может также позволить воспользоваться скрытыми полями в веб-страницах. Скрытые поля не отображается в пользовательском интерфейсе, но они содержат некоторые значения, передаваемые на сервер при отправке веб-формы. Например, разработчик может использовать скрытые поля для указания цен на товары, показанные на веб-странице, вместо того, чтобы делать ссылку на прайс-лист на сервере. В таком случае злоумышленник, используя веб-прокси, может перехватить передаваемую от пользователя информацию и внести изменения в стоимость товаров (например, установить стоимость всех товаров 1 рубль), прежде чем эта информация попадает на сервер. Это совсем не сложно сделать, если в приложении не реализованы другие проверки.
Контрмерой, позволяющей снизить риски, связанные с такими угрозами, является надлежащая проверка параметров. Эта проверка может состоять из проверок на входе и проверок на выходе. В клиент-серверной среде, проверка на входе может быть реализована на стороне клиента, до передачи запросов на сервер. Однако даже при реализации такой проверки на клиентской стороне, сервер также должен выполнять проверку входных данных до начала их обработки, т.к. компьютер пользователя обычно защищен хуже, чем сервер, и его безопасность может быть нарушена.
- Проверка на входе (Pre-validation). Проверяет, что входные данные имеют правильный формат и соответствуют требованиям приложения, и только после успешной проверки данные передаются приложению. Примером может быть проверка вводимых в поле формы символов, которая не позволяет пользователю ввести буквы в цифровое поле.
- Проверка на выходе (Post-validation). Проверяет, что данные, выходящие из приложения, соответствуют ожиданиям (то есть находятся в пределах заранее определенного разумного диапазона).
Как было отмечено ранее, управление несколькими тысячами различных клиентов, подключающихся к веб-приложению, является непростой задачей. Вопрос управления сеансами (session management) должен быть рассмотрен и решен до размещения приложения в сети Интернет. Чаще всего используется способ управления пользовательскими сеансами, при котором каждому соединению присваивается уникальный идентификатор сеанса. Идентификатор сеанса – это значение, которое отправляется клиентом на сервер вместе с каждым запросом, что позволяет серверу или приложению однозначно идентифицировать клиента. В случае если злоумышленник сможет получить или угадать идентификатор сеанса аутентифицированного клиента и направить его на сервер в качестве собственного идентификатора сеанса, он сможет «обмануть» сервер и получить доступ к сеансу клиента.
Старое правило «никогда ничего не отправлять в открытом виде», безусловно, применимо и здесь. Трафик HTTP по умолчанию не зашифрован, в нем не предусмотрено ничего для противодействия перехвату злоумышленником идентификаторов сеансов из передаваемых по сети данных. Поскольку идентификаторы сеансов передаются, как правило, по протоколу HTTP, следует обеспечить их защиту.
Возможность угадать или предсказать идентификаторы сеансов, также представляет угрозу в такой среде. Поэтому использование идентификаторов сеансов с последовательными номерами является большой ошибкой. Более целесообразно использовать случайные идентификаторы сеансов нужной длины, что не позволит предсказать значение идентификатора. Следует включать в передаваемые запросы некие штампы времени, что позволит предотвратить атаку повтора (replay attack), при которой злоумышленник перехватывает трафик легитимного сеанса, а затем повторяет его, чтобы аутентификацировать свой сеанс. Кроме того, любой куки, используемый для хранения информации о состоянии соединения, должен быть зашифрован.
1 комментарий:
- Понимание SQL-инъекций. http://www.cisco.com/web/about/security/intelligence/sql_injection.html
Отправить комментарий