Безопасность в Веб-разработке
17.1.2.6. Логические атаки (Logical Attacks)
Атаки данного класса направлены на эксплуатацию функций приложения или логики его функционирования. В качестве примеров можно привести восстановление пролей, регистрацию учетных записей, аукционные торги, транзакции в системах электронной коммерции. Приложение может требовать от пользователя корректного выполнения нескольких последовательных действий для выполнения определенной задачи. Злоумышленник может обойти или использовать эти механизмы в своих целях.
17.1.2.6.1. Злоупотребление функциональными возможностями (Abuse of Functionality)
Описание
Данные атаки направлены на использование функций Веб-приложения с целью обхода механизмов разграничение доступа. Некоторые механизмы Веб-приложения, включая функции обеспечения безопасности, могут быть использованы для этих целей. Наличие уязвимости в одном из, возможно, второстепенных компонентов приложения может привести к компрометации всего приложения. Уровень риска и потенциальные возможности злоумышленника в случае проведения атаки очень сильно зависят от конкретного приложения.
Пример
Примеры злоупотребления функциональными возможностями включают в себя:
- использования функций поиска для получения доступа к файлам за пределами корневой директории Веб-сервера;
- использование функции загрузки файлов на сервер для перезаписи файлов конфигурации или внедрения серверных сценариев;
- реализация отказа в обслуживании путем использования функции блокировки учетной записи при многократном вводе неправильного пароля.
17.1.2.6.2. Отказ в обслуживании (Denial of Service)
Описание
Данный класс атак направлен на нарушение доступности Веб-сервера. Обычно атаки, направленные на отказ в обслуживании реализуются на сетевом уровне, однако они могут быть направлены и на прикладной уровень. Используя функции Веб-приложения, злоумышленник может исчерпать критичные ресурсы системы, или воспользоваться уязвимостью, приводящий к прекращению функционирования системы.
Обычно DoS атаки направлены на исчерпание критичных системных ресурсов, таких как вычислительные мощности, оперативная память, дисковое пространство или пропускная способность каналов связи. Если какой-то из ресурсов достигнет максимальной загрузки, приложение целиком будет недоступно.
Атаки могут быть направлены на любой из компонентов Веб-приложения, например, такие как сервер СУБД, сервер аутентификации и т.д.
Решение
Очень распространенный вид атак, средствами защиты является, оптимизация кода, и, что более действенно при наличии у злоумышленника неких мощностей, ввод ограничений на количество посылаемых данных в единицу времени.
17.1.2.6.3. Недостаточное противодействие автоматизации (Insufficient Anti-automation)
Описание
Недостаточное противодействие автоматизации возникает, когда сервер позволяет автоматически выполнять операции, которые должны проводиться вручную. Автоматизированные программы могут варьироваться от безобидных роботов поисковых систем до систем автоматизированного поиска уязвимостей и регистрации учетных записей. Подобные роботы генерируют тысячи запросов в минуту, что может привести к падению производительности всего приложения.
Решение
Противодействие автоматизации заключается в ограничении возможностей подобных утилит. Например, файл "robots" может предотвращать индексирование некоторых частей сервера, а дополнительные средства идентификации предотвращать автоматическую регистрацию сотен учетных записей системы электронной почты.
Стандартным средство борьбы с роботами сейчас является CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart).
17.1.2.6.4. Недостаточная проверка процесса (Insufficient Process Validation)
Описание
Уязвимости этого класса возникают, когда сервер не достаточно проверяет последовательность выполнения операций приложения. Если состояние сессии пользователя и приложения должным образом не контролируется, приложение может быть уязвимо для мошеннических действий.
Пример
Система электронной торговли может предлагать скидку на продукт B, в случае покупки продукта A. Пользователь, не желающий покупать продукт A, может попытаться приобрести продукт B со скидкой. Заполнив заказ на покупку обоих продуктов, пользователь получат скидку. Затем пользователь возвращается к форме подтверждения заказа и удаляет продукт A из покупаемых, путем модификации значений в форме. Если сервер повторно не проверит возможность покупки продукта B по указанной цене без продукта A, будет осуществлена закупка по низкой цене.
Решение
Для обеспечения корректной работы подобных функций Веб-приложение должно четко отслеживать состояние сессии пользователя и отслеживать ее соответствие текущим операциям. В большинстве случаев это осуществляется путем сохранения состояния сессии в cookie или скрытом поле формы HTML. Но поскольку эти значения могут быть модифицированы пользователем, обязательно должна проводиться проверка этих значений на сервере. Если этого не происходит, злоумышленник получает возможность обойти последовательность действий, и как следствие – логику приложения.
17.1.2.7. Вирусы и приложения типа "троянский конь"
Описание
Рабочие станции конечных пользователей очень уязвимы для вирусов и троянских коней. Вирусами называются вредоносные программы, которые внедряются в другие программы для выполнения определенной нежелательной функции на рабочей станции конечного пользователя. В качестве примера можно привести вирус, который прописывается в файле command.com (главном интерпретаторе систем Windows) и стирает другие файлы, а также заражает все другие найденные им версии command.com. "Троянский конь" – это не программная вставка, а настоящая программа, которая выглядит как полезное приложение, а на деле выполняет вредную роль. Примером типичного "троянского коня" является программа, которая выглядит, как простая игра для рабочей станции пользователя. Однако пока пользователь играет в игру, программа отправляет свою копию по электронной почте каждому абоненту, занесенному в адресную книгу этого пользователя. Все абоненты получают по почте игру, вызывая ее дальнейшее распространение.
Решение
Борьба с вирусами и "троянскими конями" ведется с помощью эффективного антивирусного программного обеспечения, работающего на пользовательском уровне и, возможно, на уровне сети. Антивирусные средства обнаруживают большинство вирусов и "троянских коней" и пресекают их распространение. Получение самой свежей информации о вирусах поможет эффективнее бороться с ними. По мере появления новых вирусов и "троянских коней" предприятие должно устанавливать новые версии антивирусных средств и приложений.
17.1.3. Ключевые термины
Безопасность информации, Информационная безопасность, Политика безопасности, Политика безопасности информационно-телекоммуникационных технологий, Средства защиты от несанкционированного доступа, Системы мониторинга сетей, Анализаторы протоколов, Антивирусные средства, Межсетевые экраны, Криптографические средства, Системы аутентификации, Сетевые атаки.
17.2. XSS Filter
17.2.1. Общее описание
XSS ( Сross Site Sсriрting – "межсайтовый скриптинг") – тип уязвимости интерактивных информационных систем в Интернете [14]. XSS возникает, когда в генерируемые сервером страницы по какой-то причине попадают пользовательские скрипты. Специфика подобных атак заключается в том, что вместо непосредственной атаки сервера они используют уязвимый сервер в качестве средства атаки на клиента.
По данным securitylab.ru за второй квартал 2008 XSS составляют около 15 % всех обнаруженных уязвимостей [15]. Долгое время программисты не уделяли им должного внимания, считая их неопасными. Однако это мнение ошибочно: на странице или в HTTP-Cookie могут быть весьма уязвимые данные (например, идентификатор сессии администратора). На популярном сайте скрипт может устроить DoS-атакy.
По данным исследования Web Application Security Consortium за 2007 год [16] самой распространенной уязвимостью является Cross-Site Scripting, эта уязвимость присутствует почти в 60% проанализированных сайтов (рис. 17.2).
Источник: Security Statistics Projects [16]
Поскольку XSS относятся к классу атак, направленных на клиента (т.е. на браузер пользователя), логичным является решение сконцентрировать защитные механизмы, противодействующие атаке, также на стороне клиента.
Так в новой версии Internet Explorer 8 появился XSS -фильтр, который делает реализацию XSS -атаки в нем намного более сложной задачей для злоумышленника [16].
Архитектура XSS Filter в Internet Explorer 8 показана на рис. 17.3.
Источник: IE 8 XSS Filter Architecture / Implementation [17]
Логика работы XSS Filter в Internet Explorer 8 показана на рис. 17.4.
Источник: IE 8 XSS Filter Architecture / Implementation [17]
XSS -фильтр работает как компонент IE8, который просматривает все запросы и ответы, проходящие через браузер [18]. Когда фильтр обнаруживает XSS в межсайтовом запросе, он нейтрализует атаку, если она зависит от ответа сервера.
С XSS -фильтром пользователи IE8, которые столкнутся с Type-1 XSS -атакой, увидят приблизительно такое предупреждение, как на рис. 17.5.
Источник: IE8 Security Part IV: The XSS Filter [19]
В данном случае XSS -фильтр обнаружил атаку межсайтового скриптинга в URL, страница была модифицирована и XSS -атака была заблокирована. Фильтр нейтрализировал атаку, так как идентифицированный скрипт отсылал данные на страницу ответа. В данном случае фильтр эффективен без модификации первоначального запроса к серверу или блокировки всего запроса.
Как можно понять, есть множество сценариев, которые фильтр должен обрабатывать правильно. Вот некоторые из них [18]:
- фильтр должен быть эффективен, даже если атака направлена на артефакт часто используемых рабочих сред веб-приложений;
- при фильтрации наш код не должен предоставить новый сценарий для атаки, которая бы отличалась от существующей;
- фильтр должен эффективно бороться со всеми векторами XSS -атак, которые еще не были закрыты другими способами сокращения поверхности для XSS -атаки.