Текст книги "Защити свой компьютер на 100% от вирусов и хакеров"
Автор книги: Олег Бойцев
сообщить о нарушении
Текущая страница: 3 (всего у книги 20 страниц) [доступный отрывок для чтения: 8 страниц]
1.4. Классификация угроз безопасности веб-серверов
Многие из читателей наверняка обратили свое внимание на то, какую важную роль в анализе рисков (см. разд. 1.2) играет такой фактор, как угроза. В этой связи будет более чем уместно ознакомиться с перечнем типичных угроз, которые приведены ниже. Настоящая классификация окажется полезна и подготовленным читателям, и тем, кто углубленно интересуется вопросами компьютерной безопасности.
Очередной раз выходя в Интернет и привычно набирая в браузере дорогой сердцу адрес, мы убеждаемся снова и снова, что не так уж все и плохо: апокалипсис постоянно кто-то переносит, а мы живем в мире высоких технологий, и это не может не радовать. Интернет стал для многих из нас настолько привычным, что иногда кто-нибудь да и допустит мысль о его существовании со времени сотворения мира. Между тем за кажущейся простотой и удобством стоит четкая и отлаженная работа узлов Сети. Было бы наивно полагать, что все совершенно, особенно если речь идет о вещах, сосуществующих в столь динамичной среде. Просматривая горячие двадцатки SANS, предупреждения EEYE, горячий эксклюзив от SecurityLab, убеждаешься снова и снова: безопасность есть процесс, а не состояние.
В рамках данного раздела мы поговорим с вами о безопасности веб-серверов, а точнее постараемся внести ясность и создать некое подобие современной классификации веб-угроз. Предпосылки к созданию подобной классификации очевидны. За последние несколько лет индустрия безопасности веб-приложений адаптировала немалое количество не совсем точных терминов, описывающих уязвимости. Такие названия уязвимостей, как "подделка параметров" (Parameter Tampering), "меж-сайтовое выполнение сценариев" (Cross-site Scripting) и "отравление печений" (Cookie Poisoning) (да-да, именно так), мягко говоря, не совсем точно определяют суть проблемы и возможные последствия атак. Отсутствие четкости в определениях часто вызывает проблемы и взаимонепонимание, даже если стороны согласны с основной идеей.
Когда начинающий специалист безопасности веб-приложений приступает к обучению, его быстро вводит в заблуждение отсутствие стандартного языка. Подобная ситуация не только не способствует профессиональному овладению предметом, но и замедляет понимание картины в целом. Появление классификации угроз безопасности веб-приложений является исключительно важным событием в мире IT.
По известным причинам только система знаний, а не ее разрозненный, дискретный вариант, может служить показателем высшей квалификации разработчиков приложений, специалистов в области безопасности, производителей программных продуктов. На основе классификации в дальнейшем могут быть созданы методики обследования приложений, рекомендации по разработке приложений с учетом безопасности, требования к продуктам и службам. Следующая классификация есть результат проработки различных книг, десятков статей и презентаций. У ее истоков стоит Web Application Security Consortium, представители которой создали базу для разработки и популяризации стандартной терминологии описания подобных проблем (www.webappsec.org).
Представленная классификация окажется полезной прежде всего специалистам, хотя в целом материал направлен на широкий круг читателей, интересующихся проблемами компьютерной безопасности.
Классы атакСовременная классификация имеет иерархическую структуру. Классы атак разбиты по пунктам (1; 2 и т. д.) с соответствующими подпунктами (1); 2) и т. д.). Название класса атаки представлено как в русском варианте, так и в английском.
1. Аутентификация (Authentication):
1) подбор (Brute Force);
2) недостаточная аутентификация (Insufficient Authentication);
3) небезопасное восстановление паролей (Weak Password Recovery Validation).
2. Авторизация (Authorization):
1) предсказуемое значение идентификатора сессии (Credential/Session Prediction);
2) недостаточная авторизация (Insufficient Authorization);
3) отсутствие тайм-аута сессии (Insufficient Session Expiration);
4) фиксация сессии (Session Fixation).
3. Атаки на клиентов (Client-side Attacks):
1) подмена содержимого (Content Spoofing);
2) межсайтовое выполнение сценариев (Cross-site Scripting, XSS);
3) расщепление HTTP-запроса (HTTP Response Splitting).
4. Выполнение кода (Command Execution):
1) переполнение буфера (Buffer Overflow);
2) атака на функции форматирования строк (Format String Attack);
3) внедрение операторов LDAP (LDAP Injection);
4) выполнение команд операционной системы (OS Commanding);
5) внедрение операторов SQL (SQL Injection);
6) внедрение серверных расширений (SSI Injection);
7) внедрение операторов XPath (XPath Injection).
5. Разглашение информации (Information Disclosure):
1) индексирование директорий (Directory Indexing);
2) идентификация приложений (Web Server/Application Fingerprinting);
3) утечка информации (Information Leakage);
4) обратный путь в директориях (Path Traversal);
5) предсказуемое расположение ресурсов (Predictable Resource Location).
6. Логические атаки (Logical Attacks):
1) злоупотребление функциональными возможностями (Abuse of Functionality);
2) отказ в обслуживании (Denial of Service);
3) недостаточное противодействие автоматизации (Insufficient Anti-automation);
4) недостаточная проверка процесса (Insufficient Process Validation).
Пункт и подчиненные ему подпункты разбиты на разделы. Класс атаки имеет краткое описание и дополняется соответствующим "живым" примером. Ну что ж, начнем по порядку.
Аутентификация
Классифицируем атаки, направленные на обход или эксплуатацию уязвимостей в механизмах реализации аутентификации веб-серверов.
Подбор (Brute Force). Подбор, или просто «брут», как его ласково любят называть хакеры, представляет собой автоматизированный процесс проб и ошибок, основной задачей которого является угадывание имени пользователя, пароля, номера кредитной карты, ключа шифрования и т. д. Многие системы позволяют использовать слабые пароли или ключи шифрования, и пользователи часто выбирают легко угадываемые или содержащиеся в словарях парольные фразы. Трагизм еще и в том, что пользователи намеренно выбирают простые пароли, так как сложные, помимо времени ввода, неудобны еще и тем, что легко забываются. Воспользовавшись данной ситуацией, злонамеренный пользователь может применить электронный словарь (что чаще всего и делается) и попытаться использовать всю мощь содержащихся в нем комбинаций символов в качестве пароля. Если сгенерированный пароль позволяет получить доступ к системе, атака считается успешной, и атакующий может использовать учетную запись.
Подобная техника проб и ошибок может быть с успехом использована для подбора ключей шифрования. В случае использования сервером ключей недостаточной длины злоумышленник может получить используемый ключ, протестировав все возможные комбинации. Существует два вида подбора: прямой и обратный. При прямом подборе используются различные варианты пароля для одного имени пользователя (например, имя пользователя – Lamer, пароли – fuck, world, qwerty, 123321…). При обратном – перебираются различные имена пользователей, а пароль остается неизменным (например, имена пользователей – User, Intel, Sara, Vaviorka…, пароль – 12345678). В системах с миллионами учетных записей вероятность использования различными пользователями одного пароля довольно высока. Несмотря на популярность и высокую эффективность, подбор может занимать несколько часов, дней или лет. Данный вид атак широко используется преимущественно там, где отсутствует блокировка в случае неверного сочетания, – это может быть простой взлом NTLM-хэшей и т. д.
Недостаточная аутентификация (Insufficient Authentication). Данная уязвимость возникает тогда, когда веб-сервер позволяет атакующему получать доступ к важной информации или функциям сервера без должной аутентификации. Атаки подобного рода очень часто реализуются посредством интерфейса администрирования через сеть. Чтобы не использовать аутентификацию, некоторые ресурсы по умолчанию «сидят в укромном месте» по определенному адресу, который не указан на основных страницах сервера или других общедоступных ресурсах.
Однако подобный подход не более чем "безопасность через сокрытие". Важно понимать, что несмотря на то что злоумышленник не знает адреса страницы, она все равно доступна через веб. Необходимый URL может быть найден путем перебора типичных файлов и директорий (таких как /admin/) с использованием сообщений об ошибках, журналов перекрестных ссылок или путем простого чтения документации. Подобные ресурсы должны быть защищены адекватно важности их содержимого и функциональных возможностей.
К примеру, многие веб-приложения по умолчанию используют для административного доступа ссылку в корневой директории сервера (/admin/). Обычно ссылка на эту страницу не фигурирует в содержимом сервера, однако страница доступна с помощью стандартного браузера. Поскольку пользователь или разработчик предполагает, что никто не воспользуется этой страницей, так как ссылки на нее отсутствуют, зачастую реализацией аутентификации пренебрегают. В результате для получения контроля над сервером злоумышленнику достаточно зайти на эту страницу.
Небезопасное восстановление паролей (Weak Password Recovery Validation).
Данная уязвимость реализуется, благодаря тому что веб-сервер позволяет атакующему несанкционированно получать, модифицировать или восстанавливать пароли других пользователей. Часто аутентификация на веб-сервере требует от пользователя запоминания пароля или парольной фразы. Строгая политика безопасности предусматривает, что только пользователь должен знать пароль, причем помнить его отчетливо. Но, как оно всегда бывает, со временем пароль забывается. Ситуация усложняется еще и тем, что у многих по несколько электронных ящиков.
Примером реализации подобной функции является использование "секретного вопроса", ответ на который указывается в процессе регистрации. Вопрос либо выбирается из списка, либо вводится самим пользователем. Еще один механизм позволяет пользователю указать "подсказку", которая поможет ему вспомнить пароль. Другие способы требуют от пользователя указать часть персональных данных – таких как номер паспорта, домашний адрес, почтовый индекс и т. д., – которые затем будут использоваться для установления личности. После того как пользователь докажет свою идентичность, система отобразит новый пароль или перешлет его по почте. Система восстановления пароля может быть скомпрометирована путем использования подбора, уязвимостей системы или из-за легко угадываемого ответа на секретный вопрос.
Многие серверы требуют от пользователя указать его электронный адрес в комбинации с домашним адресом и номером телефона. Эта информация может быть легко получена из сетевых справочников. В результате данные, используемые для проверки, не являются большим секретом. Кроме того, эта информация может быть получена злоумышленником с использованием других методов – таких как межсайтовое выполнение сценариев или фишинг. Одно из слабых звеньев, несомненно, – парольные подсказки. Сервер, использующий подсказки для облегчения запоминания паролей, может быть атакован, поскольку подсказки помогают в реализации подбора паролей. Пользователь может использовать стойкий пароль, например "27Пуаро10", с соответствующей подсказкой: "детектив". Атакующий может заключить, что пользовательский пароль состоит из даты рождения и имени любимого автора пользователя. Это помогает сформировать относительно короткий словарь для атаки путем перебора.
Авторизация
Многие сайты разрешают доступ к некоторому содержимому или функциям приложения только определенным пользователям. Доступ для других должен быть ограничен. Используя различные техники, злоумышленник может повысить свои привилегии и получить доступ к защищенным ресурсам.
Предсказуемое значение идентификатора сессии (Credential/Session Prediction).
Предсказуемое значение идентификатора сессии позволяет перехватывать сессии других пользователей. Подобные атаки выполняются путем предсказания или угадывания уникального идентификатора сессии пользователя. Эта атака, так же как и перехват сессии (Session Hijacking), в случае успеха позволяет злоумышленнику послать запрос веб-серверу с правами скомпрометированного пользователя. Дизайн многих серверов предполагает аутентификацию пользователя при первом обращении и дальнейшее отслеживание его сессии. Для этого пользователь указывает комбинацию имени и пароля. Вместо повторной передачи имени пользователя и пароля при каждой транзакции веб-сервер генерирует уникальный идентификатор, который присваивается сессии пользователя. Последующие запросы пользователя к серверу содержат идентификатор сессии как доказательство того, что аутентификация была успешно пройдена. Если атакующий может предсказать или угадать значение идентификатора другого пользователя, это может быть использовано для проведения атаки.
Так, многие серверы генерируют идентификаторы сессии, используя алгоритмы собственной разработки. Подобные алгоритмы могут просто увеличивать значение идентификатора для каждого запроса пользователя. Другой распространенный вариант – использование функции от текущего времени или других специфичных для компьютера данных. Идентификатор сессии сохраняется в cookie, скрытых полях форм или URL. Если атакующий имеет возможность определить алгоритм, используемый для генерации идентификатора сессии, он может выполнить следующие действия:
♦ подключиться к серверу, используя текущий идентификатор сессии;
♦ вычислить или подобрать следующий идентификатор сессии;
♦ присвоить полученное значение идентификатора cookie/скрытому полю формы/URL.
Недостаточная авторизация (Insufficient Authorization). Недостаточная авторизация возникает, когда веб-сервер позволяет атакующему получать доступ к важной информации или функциям, доступ к которым должен быть ограничен. Успешное прохождение аутентификации пользователем вовсе не означает, что он должен получить доступ ко всем функциям и содержимому сервера. Кроме аутентификации, должно быть реализовано разграничение доступа. Процедура авторизации определяет, какие действия может совершать пользователь, служба или приложение. Грамотно построенные правила доступа должны ограничивать действия пользователя согласно политике безопасности. Доступ к важным ресурсам сайта должен быть разрешен только администраторам.
В прошлом многие веб-серверы сохраняли важные ресурсы в скрытых директориях – таких как /admin или /Log. Если атакующий запрашивал эти ресурсы напрямую, он получал к ним доступ и мог перенастроить сервер, получить доступ к важной информации либо полностью скомпрометировать систему. Некоторые серверы после аутентификации сохраняют в cookie или скрытых полях идентификатор «роли» пользователя в рамках веб-приложения. Если разграничение доступа основывается на проверке данного параметра без верификации принадлежности к роли при каждом запросе, злоумышленник может повысить свои привилегии, просто модифицировав значение cookie. К примеру, значение cookie: Session Id = 12345678; Role = User заменяется на SessionId = 12345678; Role = Admin.
Отсутствие тайм-аута сессии (Insufficient Session Expiration). Если для идентификатора сессии или учетных данных не предусмотрен тайм-аут или его значение слишком велико, злоумышленник может воспользоваться старыми данными для авторизации. Это повышает уязвимость сервера для атак, связанных с кражей идентификационных данных. Поскольку протокол HTTP не предусматривает контроль сессии, веб-серверы обычно используют идентификаторы сессии для определения запросов пользователя. Таким образом, конфиденциальность каждого идентификатора должна быть обеспечена, чтобы предотвратить множественный доступ пользователей с одной учетной записью. Похищенный идентификатор может использоваться для доступа к данным пользователя или осуществления мошеннических транзакций. Отсутствие тайм-аута сессии увеличивает вероятность успеха различных атак. К примеру, злоумышленник может получить идентификатор сессии, используя сетевой анализатор или уязвимость типа «межсайтовое выполнение сценариев». Хотя тайм-аут не поможет, в случае если идентификатор будет использован немедленно, ограничение времени действия поможет при более поздних попытках использования идентификатора. В другой ситуации, если пользователь получает доступ к серверу с публичного компьютера (библиотека, интернет-кафе и т. д.), отсутствие тайм-аута сессии может позволить злоумышленнику воспользоваться историей браузера для просмотра страниц пользователя. Большое значение тайм-аута увеличивает шансы подбора действующего идентификатора. Кроме того, увеличение этого параметра ведет к увеличению одновременно открытых сессий, что еще больше повышает вероятность успешного подбора.
При использовании публичного компьютера, когда несколько пользователей имеют неограниченный физический доступ к машине, отсутствие тайм-аута сессии позволяет злоумышленнику просматривать страницы, посещенные другим пользователем. Если функция выхода из системы просто перенаправляет на основную страницу веб-сервера, а не завершает сессию, страницы, посещенные пользователем, могут быть просмотрены злоумышленником. Поскольку идентификатор сессии не был отмечен как недействительный, атакующий получит доступ к страницам сервера без повторной аутентификации.
Фиксация сессии (Session Fixation). Используя данный класс атак, злоумышленник присваивает идентификатору сессии пользователя заданное значение. В зависимости от функциональных возможностей сервера существует несколько способов зафиксировать значение идентификатора сессии. Для этого могут использоваться атаки типа «межсайтовое выполнение сценариев» или подготовка сайта с помощью предварительного HTTP-запроса. После фиксации значения идентификатора сессии атакующий ожидает момента, когда пользователь войдет в систему. После входа пользователя злоумышленник использует идентификатор сессии для получения доступа к системе от имени пользователя.
Существуют два механизма управления сессиями на основе идентификаторов. Первый из них – так называемый разрешающий – основан на том, что конкретный идентификатор сессии присваивается браузером. Механизмы второго типа – строгого – функционируют с идентификаторами, сгенерированными сервером. В случае разрешающих механизмов злонамеренный пользователь может выбрать любой идентификатор сессии. При условии отсутствия спецзащиты от фиксации сессии данная атака может быть использована против любого сервера, аутентифицирующего пользователей с помощью идентификатора сессии. Не секрет, что большинство веб-серверов сохраняют ID в cookie, но это значение также может присутствовать в URL или скрытом поле формы. К сожалению, системы, использующие cookie, являются наиболее уязвимыми.
Большинство известных в настоящий момент вариантов фиксации сессии направлено именно на значение cookie (кстати, не грех будет напомнить, что сохраненные пароли вашего электронного ящика, входа на персональный сайт и прочие сохраняются все в тех же пресловутых cookie, которые можно найти по адресу: and SettingsUsernameCookies). После описанного выше нетрудно догадаться, каким именно образом программы, предназначенные для шпионажа, похищают ваши конфиденциальные данные.
Рассмотрим подробно атаку, направленную на фиксацию сессии. Атака осуществляется в три этапа. На первом этапе злонамеренный пользователь устанавливает на атакуемом сервере так называемую сессию-заглушку и получает (или выбирает произвольный в зависимости от механизма) от него идентификатор. На втором этапе, собственно, и происходит фиксация сессии, когда злоумышленник передает значение идентификатора сессии-заглушки браузеру пользователя и фиксирует его идентификатор. Данный пункт реализуется посредством модификации значения cookie с помощью пресловутого XSS.
Следующим шагом атакующего является собственно подключение к сессии. Атакующий ожидает аутентификации пользователя на сервере. После захода пользователя на сайт злоумышленник подключается к серверу, используя зафиксированный идентификатор, и получает доступ к сессии пользователя. Как вы уже поняли, "гвоздем программы" является фиксация ID, которая реализуется посредством следующих действий.
♦ При наличии уязвимости типа "межсайтовое выполнение сценариев" злоумышленник получает возможность установить определенное значение cookie на стороне клиента посредством следующего кода: httр://example/
