Классификация угроз безопасности web-серверов
Очередной раз выходя в Интернет и привычно набирая в браузере дорогой сердцу адрес Сети, мы убеждаемся снова и снова, что не так уж все и плохо: апокалипсис постоянно кто-то переносит, а мы живем в мире высоких технологий, и это не может не радовать. Тот же Интернет стал для многих из нас настолько привычным, что иногда кто-нибудь да и допустит мысль о его существовании со времени сотворения мира. Между тем, за кажущимися простотой и удобством стоит четкая и взаимоотлаженная работа узлов Сети. Было бы наивно полагать, что все совершенно, особенно если речь идет о вещах, сосуществующих в столь динамичной среде. Просматривая горячие двадцатки SANS, предупреждения EEYE, горячий эксклюзив от SecurityLab, убеждаешься снова и снова: безопасность есть процесс, а не состояние.
Сегодня мы поговорим о безопасности web-серверов, а точнее, постараемся внести ясность и создать некое подобие современной классификации web-угроз. Предпосылки к созданию подобной классификации очевидны. За последние несколько лет индустрия безопасности web-приложений адаптировала немалое количество не совсем точных терминов, описывающих уязвимости. Такие названия уязвимостей, как "подделка параметров" (Parameter Tampering), "межсайтовое выполнение сценариев" (Cross-site Scripting) и "отравление печений" (Cookie Poisoning) (да-да, вы не ослышались;)), мягко говоря, не совсем точно определяют суть проблемы и возможные последствия атак. Отсутствие четкости в определениях часто вызывает проблемы и взаимонепонимание, даже если стороны согласны с основной идеей. Когда начинающий специалист безопасности web-приложений приступает к обучению, его быстро вводит в заблуждение отсутствие стандартного языка. Подобная ситуация не только не способствует профессиональному овладению предметом, но и замедляет понимание картины в целом. Появление классификации угроз безопасности web-приложений является исключительно важным событием в мире IT.
По известным причинам только система знаний, а не ее разрозненный, дискретный вариант может служить показателем высшей квалификации разработчиков приложений, специалистов в области безопасности, производителей программных продуктов. На основе классификации в дальнейшем могут быть созданы методики обследования приложений, рекомендации по разработке приложений с учетом безопасности, требования к продуктам и службам. Следующая классификация есть результат проработки различных книг, десятков статей и презентаций. У истоков данной классификации стоит Web Application Security Consortium, представители которой создали базу для разработки и популяризации стандартной терминологии описания подобных проблем (Web Application Security Consortium, сайт ). Представленный материал, прежде всего, окажется полезным специалистам, хотя в целом материал направлен на широкий круг читателей, интересующихся проблемами компьютерной безопасности.
Классы атак
Современная классификация имеет иерархичную структуру. Классы атак разбиты по пунктам (1; 2 и т.д.) с соответствующими подпунктами (1.1; 1.2…). Название класса атаки представлено как в русском, так и в англоязычном варианте:
1. Аутентификация (Authentication).
1.1. Подбор (Brute Force).
1.2. Недостаточная аутентификация (Insufficient Authentication).
1.3. Небезопасное восстановление паролей (Weak Password Recovery Validation).
2. Авторизация (Authorization).
2.1. Предсказуемое значение идентификатора сессии (Credential/Session Prediction).
2.2. Недостаточная авторизация (Insufficient Authorization).
2.3. Отсутствие тайм-аута сессии (Insufficient Session Expiration).
2.4. Фиксация сессии (Session Fixation).
3. Атаки на клиентов (Client-side Attacks).
3.1. Подмена содержимого (Content Spoofing).
3.2. Межсайтовое выполнение сценариев (Cross-site Scripting, XSS).
3.3. Расщепление HTTP-запроса (HTTP Response Splitting).
4. Выполнение кода (Command Execution).
4.1. Переполнение буфера (Buffer Overflow).
4.2. Атака на функции форматирования строк (Format String Attack).
4.3. Внедрение операторов LDAP (LDAP Injection).
4.4. Выполнение команд ОС (OS Commanding).
4.5. Внедрение операторов SQL (SQL Injection).
4.6. Внедрение серверных расширений (SSI Injection).
4.7. Внедрение операторов XPath (XPath Injection).
5. Разглашение информации (Information Disclosure).
5.1. Индексирование директорий (Directory Indexing).
5.2. Идентификация приложений (Web Server/Application Fingerprinting).
5.3. Утечка информации (Information Leakage).
5.4. Обратный путь в директориях (Path Traversal).
5.5. Предсказуемое расположение ресурсов (Predictable Resource Location).
6. Логические атаки (Logical Attacks).
6.1. Злоупотребление функциональными возможностями (Abuse of Functionality).
6.2. Отказ в обслуживании (Denial of Service).
6.3. Недостаточное противодействие автоматизации (Insufficient Anti-automation).
6.4. Недостаточная проверка процесса (Insufficient Process Validation).
Пункт и подчиненные ему подпункты разбиты на разделы. Класс атаки имеет краткое описание и дополняется соответствующим "живым" примером. Ну что ж, начнем по порядку.
1. Аутентификация (Authentication). Классифицируем атаки, направленные на обход или эксплуатацию уязвимостей в механизмах реализации аутентификации web-серверов.
1.1. Подбор (Brute Force). Подбор, или просто "брут", как его ласково любят называть хакеры, представляет собой автоматизированный процесс проб и ошибок, основной задачей которого является угадывание имени пользователя, пароля, номера кредитной карточки, ключа шифрования и т.д. Многие системы позволяют использовать слабые пароли или ключи шифрования, и пользователи часто выбирают легко угадываемые или содержащиеся в словарях парольные фразы. Трагизм еще и в том, что пользователи намеренно выбирают простые пароли, т.к. сложные, помимо времени ввода, неудобны еще и тем, что легко забываются. Воспользовавшись данной ситуацией, злонамеренный пользователь может применить электронный словарь (что чаще всего и делается) и попытаться использовать всю мощь содержащихся в нем комбинаций символов в качестве пароля. Если сгенеренный пароль позволяет получить доступ к системе, атака считается успешной, и атакующий может использовать учетную запись. Подобная техника проб и ошибок может быть с успехом использована для подбора ключей шифрования. В случае использования сервером ключей недостаточной длины злоумышленник может получить используемый ключ, протестировав все возможные комбинации. Существует два вида подбора: прямой и обратный. При прямом подборе используются различные варианты пароля для одного имени пользователя. При обратном перебираются различные имена пользователей, а пароль остается неизменным. В системах с миллионами учетных записей вероятность использования различными пользователями одного пароля довольно высока. Несмотря на популярность и высокую эффективность, подбор может занимать несколько часов, дней или лет. Данный вид атак широко используется преимущественно там, где отсутствует блокировка в случае неверного сочетания — это может быть простой взлом NTLM-хэшей и.т.д. Пример прямого и обратного брутфорса:
Имя пользователя = Lamer
Пароли = fuck, world,qwerty,123321, ...
Имена пользователей = Epson, Apson, Sara, Vaviorka, ...
Пароль = 12345678
1.2. Недостаточная аутентификация (Insufficient Authentication) Данная уязвимость возникает тогда, когда web-сервер позволяет атакующему получать доступ к важной информации или функциям сервера без должной аутентификации. Атаки подобного рода очень часто реализуются посредством интерфейса администрирования через Web. Чтобы не использовать аутентификацию, некоторые ресурсы по дефолту "сидят в укромном месте" по определенному адресу, который не указан на основных страницах сервера или других общедоступных ресурсах. Однако подобный подход не более чем "безопасность через сокрытие". Важно понимать, что, несмотря на то, что злоумышленник не знает адреса страницы, она все равно доступна через Web. Необходимый URL может быть найден путем перебора типичных файлов и директорий (таких, как /admin/) с использованием сообщений об ошибках, журналов перекрестных ссылок или путем простого чтения документации. Подобные ресурсы должны быть защищены адекватно важности их содержимого и функциональных возможностей. Пример: многие web-приложения по умолчанию используют для административного доступа ссылку в корневой директории сервера (/admin/). Обычно ссылка на эту страницу не фигурирует в содержимом сервера, однако страница доступна с помощью стандартного браузера. Поскольку пользователь или разработчик предполагает, что никто не воспользуется этой страницей, так как ссылки на нее отсутствуют, зачастую реализацией аутентификации пренебрегают. И для получения контроля над сервером злоумышленнику достаточно зайти на эту страницу.
1.3. Небезопасное восстановление паролей (Weak Password Recovery Validation). Данная уязвимость реализуется благодаря тому, что web-сервер позволяет атакующему несанкционированно получать, модифицировать или восстанавливать пароли других пользователей. Часто аутентификация на web- сервере требует от пользователя запоминания пароля или парольной фразы (ну кто из нас не помнит, как при регистрации на mail.ru нас вежливо просили ввести имя бабушки из Гваделупы;-)).Строгая политика безопасности предусматривает, что только пользователь должен знать пароль, причем помнить его отчетливо. Но, как оно всегда бывает, со временем пароль забывается. Ситуация усложняется еще и тем, что у многих по несколько электронных ящиков. Примером реализации подобной функции является использование "секретного вопроса", ответ на который указывается в процессе регистрации. Вопрос либо выбирается из списка, либо вводится самим пользователем. Еще один механизм позволяет пользователю указать "подсказку", которая поможет ему вспомнить пароль. Другие способы требуют от пользователя указать часть персональных данных — таких, как номер паспорта, домашний адрес, почтовый индекс и т.д., — которые затем будут использоваться для установления личности. После того, как пользователь докажет свою идентичность, система отобразит новый пароль или перешлет его по почте. Уязвимости, связанные с недостаточной проверкой при восстановлении пароля, возникают, когда атакующий получает возможность используемый механизм. Это случается, когда информацию, используемую для проверки пользователя, легко угадать или сам процесс подтверждения можно обойти. Система восстановления пароля может быть скомпрометирована путем использования подбора, уязвимостей системы или из-за легко угадываемого ответа на секретный вопрос. Примеры. Многие серверы требуют от пользователя указать его e-mail в комбинации с домашним адресом и номером телефона. Эта информация может быть легко получена из сетевых справочников. В результате данные, используемые для проверки, не являются большим секретом. Кроме того, эта информация может быть получена злоумышленником с использованием других методов — таких, как межсайтовое выполнение сценариев или фишинг. Одно из слабых звеньев — несомненно, парольные подсказки. Сервер, использующий подсказки для облегчения запоминания паролей, может быть атакован, поскольку подсказки помогают в реализации подбора паролей. Пользователь может использовать стойкий пароль — например, "27Пуаро10" с соответствующей подсказкой: "детектив". Атакующий может заключить, что пользовательский пароль состоит из даты рождения и имени любимого автора пользователя. Это помогает сформировать относительно короткий словарь для атаки путем перебора.
2. Авторизация (Authorization) — процесс, стоящий в основе атак, направленных на методы, которые используются web-сервером для определения того, имеет ли пользователь, служба или приложение необходимые для совершения действия разрешения. Многие web-сайты разрешают доступ к некоторому содержимому или функциям приложения только определенным пользователям. Доступ для других должен быть ограничен. Используя различные техники, злоумышленник может повысить свои привилегии и получить доступ к защищенным ресурсам.
2.1. Предсказуемое значение идентификатора сессии (Credential/Session Prediction). Предсказуемое значение идентификатора сессии позволяет перехватывать сессии других пользователей. Подобные атаки выполняются путем предсказания или угадывания уникального идентификатора сессии пользователя. Эта атака, также как и перехват сессии (Session Hijacking), в случае успеха позволяет злоумышленнику послать запрос web-серверу с правами скомпрометированного пользователя. Дизайн многих серверов предполагает аутентификацию пользователя при первом обращении и дальнейшее отслеживание его сессии. Для этого пользователь указывает комбинацию имени и пароля. Вместо повторной передачи имени пользователя и пароля при каждой транзакции web-сервер генерирует уникальный идентификатор, который присваивается сессии пользователя. Последующие запросы пользователя к серверу содержат идентификатор сессии как доказательство того, что аутентификация была успешно пройдена. Если атакующий может предсказать или угадать значение идентификатора другого пользователя, это может быть использовано для проведения атаки. Примеры. Многие серверы генерируют идентификаторы сессии, используя алгоритмы собственной разработки. Подобные алгоритмы могут просто увеличивать значение идентификатора для каждого запроса пользователя. Другой распространенный вариант — использование функции от текущего времени или других специфичных для компьютера данных. Идентификатор сессии сохраняется в cookie, скрытых полях форм или URL. Если атакующий имеет возможность определить алгоритм, используемый для генерации идентификатора сессии, он может выполнить следующие действия:
1) подключиться к серверу, используя текущий идентификатор сессии;
2) вычислить или подобрать следующий идентификатор сессии;
3) присвоить полученное значение идентификатора cookie/скрытому полю формы/URL.
2.2. Недостаточная авторизация (Insufficient Authorization). Недостаточная авторизация возникает, когда web-сервер позволяет атакующему получать доступ к важной информации или функциям, доступ к которым должен быть ограничен. То, что пользователь прошел аутентификацию, не означает, что он должен получить доступ ко всем функциям и содержимому сервера. Кроме аутентификации, должно быть реализовано разграничение доступа. Процедура авторизации определяет, какие действия может совершать пользователь, служба или приложение. Правильно построенные правила доступа должны ограничивать действия пользователя согласно политике безопасности. Доступ к важным ресурсам сайта должен быть разрешен только администраторам. Примеры: в прошлом многие web-серверы сохраняли важные ресурсы в скрытых директориях — таких, как "/admin" или "/log". Если атакующий запрашивал эти ресурсы напрямую, он получал к ним доступ и мог перенастроить сервер, получить доступ к важной информации либо полностью скомпрометировать систему. Некоторые серверы после аутентификации сохраняют в cookie или скрытых полях идентификатор "роли" пользователя в рамках web-приложения. Если разграничение доступа основывается на проверке данного параметра без верификации принадлежности к роли при каждом запросе, злоумышленник может повысить свои привилегии, просто модифицировав значение cookie.
К примеру, значение cookie
SessionId=12345678; Role=User
заменяется на
SessionId=12345678; Role=Admin
2.3. Отсутствие тайм-аута сессии (Insufficient Session Expiration). В случае, если для идентификатора сессии или учетных данных не предусмотрен тайм-аут или его значение слишком велико, злоумышленник может воспользоваться старыми данными для авторизации. Это повышает уязвимость сервера для атак, связанных с кражей идентификационных данных. Поскольку протокол HTTP не предусматривает контроль сессии, web- серверы обычно используют идентификаторы сессии для определения запросов пользователя. Таким образом, конфиденциальность каждого идентификатора должна быть обеспечена, чтобы предотвратить множественный доступ пользователей с одной учетной записью. Похищенный идентификатор может использоваться для доступа к данным пользователя или осуществления мошеннических транзакций. Отсутствие тайм-аута сессии увеличивает вероятность успеха различных атак. К примеру, злоумышленник может получить идентификатор сессии, используя сетевой анализатор или уязвимость типа межсайтовое выполнение сценариев. Хотя тайм-аут не поможет в случае, если идентификатор будет использован немедленно, ограничение времени действия поможет при более поздних попытках использования идентификатора. В другой ситуации, если пользователь получает доступ к серверу с публичного компьютера (библиотека, Internet-кафе и т.д.), отсутствие тайм-аута сессии может позволить злоумышленнику воспользоваться историей браузера для просмотра страниц пользователя. Большое значение тайм-аута увеличивает шансы подбора действующего идентификатора. Кроме того, увеличение этого параметра ведет к увеличению одновременно открытых сессий, что еще больше повышает вероятность успешного подбора. Пример: при использовании публичного компьютера, когда несколько пользователей имеют неограниченный физический доступ к машине, отсутствие тайм-аута сессии позволяет злоумышленнику просматривать страницы, посещенные другим пользователем. Если функция выхода из системы просто перенаправляет на основную страницу web-сервера, а не завершает сессию, страницы, посещенные пользователем, могут быть просмотрены злоумышленником. Поскольку идентификатор сессии не был отмечен как недействительный, атакующий получит доступ к страницам сервера без повторной аутентификации.
Продолжение следует.
Использованы материалы сайт
Бойцев О.М., boyscout@gmail.ru
Сегодня мы поговорим о безопасности web-серверов, а точнее, постараемся внести ясность и создать некое подобие современной классификации web-угроз. Предпосылки к созданию подобной классификации очевидны. За последние несколько лет индустрия безопасности web-приложений адаптировала немалое количество не совсем точных терминов, описывающих уязвимости. Такие названия уязвимостей, как "подделка параметров" (Parameter Tampering), "межсайтовое выполнение сценариев" (Cross-site Scripting) и "отравление печений" (Cookie Poisoning) (да-да, вы не ослышались;)), мягко говоря, не совсем точно определяют суть проблемы и возможные последствия атак. Отсутствие четкости в определениях часто вызывает проблемы и взаимонепонимание, даже если стороны согласны с основной идеей. Когда начинающий специалист безопасности web-приложений приступает к обучению, его быстро вводит в заблуждение отсутствие стандартного языка. Подобная ситуация не только не способствует профессиональному овладению предметом, но и замедляет понимание картины в целом. Появление классификации угроз безопасности web-приложений является исключительно важным событием в мире IT.
По известным причинам только система знаний, а не ее разрозненный, дискретный вариант может служить показателем высшей квалификации разработчиков приложений, специалистов в области безопасности, производителей программных продуктов. На основе классификации в дальнейшем могут быть созданы методики обследования приложений, рекомендации по разработке приложений с учетом безопасности, требования к продуктам и службам. Следующая классификация есть результат проработки различных книг, десятков статей и презентаций. У истоков данной классификации стоит Web Application Security Consortium, представители которой создали базу для разработки и популяризации стандартной терминологии описания подобных проблем (Web Application Security Consortium, сайт ). Представленный материал, прежде всего, окажется полезным специалистам, хотя в целом материал направлен на широкий круг читателей, интересующихся проблемами компьютерной безопасности.
Классы атак
Современная классификация имеет иерархичную структуру. Классы атак разбиты по пунктам (1; 2 и т.д.) с соответствующими подпунктами (1.1; 1.2…). Название класса атаки представлено как в русском, так и в англоязычном варианте:
1. Аутентификация (Authentication).
1.1. Подбор (Brute Force).
1.2. Недостаточная аутентификация (Insufficient Authentication).
1.3. Небезопасное восстановление паролей (Weak Password Recovery Validation).
2. Авторизация (Authorization).
2.1. Предсказуемое значение идентификатора сессии (Credential/Session Prediction).
2.2. Недостаточная авторизация (Insufficient Authorization).
2.3. Отсутствие тайм-аута сессии (Insufficient Session Expiration).
2.4. Фиксация сессии (Session Fixation).
3. Атаки на клиентов (Client-side Attacks).
3.1. Подмена содержимого (Content Spoofing).
3.2. Межсайтовое выполнение сценариев (Cross-site Scripting, XSS).
3.3. Расщепление HTTP-запроса (HTTP Response Splitting).
4. Выполнение кода (Command Execution).
4.1. Переполнение буфера (Buffer Overflow).
4.2. Атака на функции форматирования строк (Format String Attack).
4.3. Внедрение операторов LDAP (LDAP Injection).
4.4. Выполнение команд ОС (OS Commanding).
4.5. Внедрение операторов SQL (SQL Injection).
4.6. Внедрение серверных расширений (SSI Injection).
4.7. Внедрение операторов XPath (XPath Injection).
5. Разглашение информации (Information Disclosure).
5.1. Индексирование директорий (Directory Indexing).
5.2. Идентификация приложений (Web Server/Application Fingerprinting).
5.3. Утечка информации (Information Leakage).
5.4. Обратный путь в директориях (Path Traversal).
5.5. Предсказуемое расположение ресурсов (Predictable Resource Location).
6. Логические атаки (Logical Attacks).
6.1. Злоупотребление функциональными возможностями (Abuse of Functionality).
6.2. Отказ в обслуживании (Denial of Service).
6.3. Недостаточное противодействие автоматизации (Insufficient Anti-automation).
6.4. Недостаточная проверка процесса (Insufficient Process Validation).
Пункт и подчиненные ему подпункты разбиты на разделы. Класс атаки имеет краткое описание и дополняется соответствующим "живым" примером. Ну что ж, начнем по порядку.
1. Аутентификация (Authentication). Классифицируем атаки, направленные на обход или эксплуатацию уязвимостей в механизмах реализации аутентификации web-серверов.
1.1. Подбор (Brute Force). Подбор, или просто "брут", как его ласково любят называть хакеры, представляет собой автоматизированный процесс проб и ошибок, основной задачей которого является угадывание имени пользователя, пароля, номера кредитной карточки, ключа шифрования и т.д. Многие системы позволяют использовать слабые пароли или ключи шифрования, и пользователи часто выбирают легко угадываемые или содержащиеся в словарях парольные фразы. Трагизм еще и в том, что пользователи намеренно выбирают простые пароли, т.к. сложные, помимо времени ввода, неудобны еще и тем, что легко забываются. Воспользовавшись данной ситуацией, злонамеренный пользователь может применить электронный словарь (что чаще всего и делается) и попытаться использовать всю мощь содержащихся в нем комбинаций символов в качестве пароля. Если сгенеренный пароль позволяет получить доступ к системе, атака считается успешной, и атакующий может использовать учетную запись. Подобная техника проб и ошибок может быть с успехом использована для подбора ключей шифрования. В случае использования сервером ключей недостаточной длины злоумышленник может получить используемый ключ, протестировав все возможные комбинации. Существует два вида подбора: прямой и обратный. При прямом подборе используются различные варианты пароля для одного имени пользователя. При обратном перебираются различные имена пользователей, а пароль остается неизменным. В системах с миллионами учетных записей вероятность использования различными пользователями одного пароля довольно высока. Несмотря на популярность и высокую эффективность, подбор может занимать несколько часов, дней или лет. Данный вид атак широко используется преимущественно там, где отсутствует блокировка в случае неверного сочетания — это может быть простой взлом NTLM-хэшей и.т.д. Пример прямого и обратного брутфорса:
Имя пользователя = Lamer
Пароли = fuck, world,qwerty,123321, ...
Имена пользователей = Epson, Apson, Sara, Vaviorka, ...
Пароль = 12345678
1.2. Недостаточная аутентификация (Insufficient Authentication) Данная уязвимость возникает тогда, когда web-сервер позволяет атакующему получать доступ к важной информации или функциям сервера без должной аутентификации. Атаки подобного рода очень часто реализуются посредством интерфейса администрирования через Web. Чтобы не использовать аутентификацию, некоторые ресурсы по дефолту "сидят в укромном месте" по определенному адресу, который не указан на основных страницах сервера или других общедоступных ресурсах. Однако подобный подход не более чем "безопасность через сокрытие". Важно понимать, что, несмотря на то, что злоумышленник не знает адреса страницы, она все равно доступна через Web. Необходимый URL может быть найден путем перебора типичных файлов и директорий (таких, как /admin/) с использованием сообщений об ошибках, журналов перекрестных ссылок или путем простого чтения документации. Подобные ресурсы должны быть защищены адекватно важности их содержимого и функциональных возможностей. Пример: многие web-приложения по умолчанию используют для административного доступа ссылку в корневой директории сервера (/admin/). Обычно ссылка на эту страницу не фигурирует в содержимом сервера, однако страница доступна с помощью стандартного браузера. Поскольку пользователь или разработчик предполагает, что никто не воспользуется этой страницей, так как ссылки на нее отсутствуют, зачастую реализацией аутентификации пренебрегают. И для получения контроля над сервером злоумышленнику достаточно зайти на эту страницу.
1.3. Небезопасное восстановление паролей (Weak Password Recovery Validation). Данная уязвимость реализуется благодаря тому, что web-сервер позволяет атакующему несанкционированно получать, модифицировать или восстанавливать пароли других пользователей. Часто аутентификация на web- сервере требует от пользователя запоминания пароля или парольной фразы (ну кто из нас не помнит, как при регистрации на mail.ru нас вежливо просили ввести имя бабушки из Гваделупы;-)).Строгая политика безопасности предусматривает, что только пользователь должен знать пароль, причем помнить его отчетливо. Но, как оно всегда бывает, со временем пароль забывается. Ситуация усложняется еще и тем, что у многих по несколько электронных ящиков. Примером реализации подобной функции является использование "секретного вопроса", ответ на который указывается в процессе регистрации. Вопрос либо выбирается из списка, либо вводится самим пользователем. Еще один механизм позволяет пользователю указать "подсказку", которая поможет ему вспомнить пароль. Другие способы требуют от пользователя указать часть персональных данных — таких, как номер паспорта, домашний адрес, почтовый индекс и т.д., — которые затем будут использоваться для установления личности. После того, как пользователь докажет свою идентичность, система отобразит новый пароль или перешлет его по почте. Уязвимости, связанные с недостаточной проверкой при восстановлении пароля, возникают, когда атакующий получает возможность используемый механизм. Это случается, когда информацию, используемую для проверки пользователя, легко угадать или сам процесс подтверждения можно обойти. Система восстановления пароля может быть скомпрометирована путем использования подбора, уязвимостей системы или из-за легко угадываемого ответа на секретный вопрос. Примеры. Многие серверы требуют от пользователя указать его e-mail в комбинации с домашним адресом и номером телефона. Эта информация может быть легко получена из сетевых справочников. В результате данные, используемые для проверки, не являются большим секретом. Кроме того, эта информация может быть получена злоумышленником с использованием других методов — таких, как межсайтовое выполнение сценариев или фишинг. Одно из слабых звеньев — несомненно, парольные подсказки. Сервер, использующий подсказки для облегчения запоминания паролей, может быть атакован, поскольку подсказки помогают в реализации подбора паролей. Пользователь может использовать стойкий пароль — например, "27Пуаро10" с соответствующей подсказкой: "детектив". Атакующий может заключить, что пользовательский пароль состоит из даты рождения и имени любимого автора пользователя. Это помогает сформировать относительно короткий словарь для атаки путем перебора.
2. Авторизация (Authorization) — процесс, стоящий в основе атак, направленных на методы, которые используются web-сервером для определения того, имеет ли пользователь, служба или приложение необходимые для совершения действия разрешения. Многие web-сайты разрешают доступ к некоторому содержимому или функциям приложения только определенным пользователям. Доступ для других должен быть ограничен. Используя различные техники, злоумышленник может повысить свои привилегии и получить доступ к защищенным ресурсам.
2.1. Предсказуемое значение идентификатора сессии (Credential/Session Prediction). Предсказуемое значение идентификатора сессии позволяет перехватывать сессии других пользователей. Подобные атаки выполняются путем предсказания или угадывания уникального идентификатора сессии пользователя. Эта атака, также как и перехват сессии (Session Hijacking), в случае успеха позволяет злоумышленнику послать запрос web-серверу с правами скомпрометированного пользователя. Дизайн многих серверов предполагает аутентификацию пользователя при первом обращении и дальнейшее отслеживание его сессии. Для этого пользователь указывает комбинацию имени и пароля. Вместо повторной передачи имени пользователя и пароля при каждой транзакции web-сервер генерирует уникальный идентификатор, который присваивается сессии пользователя. Последующие запросы пользователя к серверу содержат идентификатор сессии как доказательство того, что аутентификация была успешно пройдена. Если атакующий может предсказать или угадать значение идентификатора другого пользователя, это может быть использовано для проведения атаки. Примеры. Многие серверы генерируют идентификаторы сессии, используя алгоритмы собственной разработки. Подобные алгоритмы могут просто увеличивать значение идентификатора для каждого запроса пользователя. Другой распространенный вариант — использование функции от текущего времени или других специфичных для компьютера данных. Идентификатор сессии сохраняется в cookie, скрытых полях форм или URL. Если атакующий имеет возможность определить алгоритм, используемый для генерации идентификатора сессии, он может выполнить следующие действия:
1) подключиться к серверу, используя текущий идентификатор сессии;
2) вычислить или подобрать следующий идентификатор сессии;
3) присвоить полученное значение идентификатора cookie/скрытому полю формы/URL.
2.2. Недостаточная авторизация (Insufficient Authorization). Недостаточная авторизация возникает, когда web-сервер позволяет атакующему получать доступ к важной информации или функциям, доступ к которым должен быть ограничен. То, что пользователь прошел аутентификацию, не означает, что он должен получить доступ ко всем функциям и содержимому сервера. Кроме аутентификации, должно быть реализовано разграничение доступа. Процедура авторизации определяет, какие действия может совершать пользователь, служба или приложение. Правильно построенные правила доступа должны ограничивать действия пользователя согласно политике безопасности. Доступ к важным ресурсам сайта должен быть разрешен только администраторам. Примеры: в прошлом многие web-серверы сохраняли важные ресурсы в скрытых директориях — таких, как "/admin" или "/log". Если атакующий запрашивал эти ресурсы напрямую, он получал к ним доступ и мог перенастроить сервер, получить доступ к важной информации либо полностью скомпрометировать систему. Некоторые серверы после аутентификации сохраняют в cookie или скрытых полях идентификатор "роли" пользователя в рамках web-приложения. Если разграничение доступа основывается на проверке данного параметра без верификации принадлежности к роли при каждом запросе, злоумышленник может повысить свои привилегии, просто модифицировав значение cookie.
К примеру, значение cookie
SessionId=12345678; Role=User
заменяется на
SessionId=12345678; Role=Admin
2.3. Отсутствие тайм-аута сессии (Insufficient Session Expiration). В случае, если для идентификатора сессии или учетных данных не предусмотрен тайм-аут или его значение слишком велико, злоумышленник может воспользоваться старыми данными для авторизации. Это повышает уязвимость сервера для атак, связанных с кражей идентификационных данных. Поскольку протокол HTTP не предусматривает контроль сессии, web- серверы обычно используют идентификаторы сессии для определения запросов пользователя. Таким образом, конфиденциальность каждого идентификатора должна быть обеспечена, чтобы предотвратить множественный доступ пользователей с одной учетной записью. Похищенный идентификатор может использоваться для доступа к данным пользователя или осуществления мошеннических транзакций. Отсутствие тайм-аута сессии увеличивает вероятность успеха различных атак. К примеру, злоумышленник может получить идентификатор сессии, используя сетевой анализатор или уязвимость типа межсайтовое выполнение сценариев. Хотя тайм-аут не поможет в случае, если идентификатор будет использован немедленно, ограничение времени действия поможет при более поздних попытках использования идентификатора. В другой ситуации, если пользователь получает доступ к серверу с публичного компьютера (библиотека, Internet-кафе и т.д.), отсутствие тайм-аута сессии может позволить злоумышленнику воспользоваться историей браузера для просмотра страниц пользователя. Большое значение тайм-аута увеличивает шансы подбора действующего идентификатора. Кроме того, увеличение этого параметра ведет к увеличению одновременно открытых сессий, что еще больше повышает вероятность успешного подбора. Пример: при использовании публичного компьютера, когда несколько пользователей имеют неограниченный физический доступ к машине, отсутствие тайм-аута сессии позволяет злоумышленнику просматривать страницы, посещенные другим пользователем. Если функция выхода из системы просто перенаправляет на основную страницу web-сервера, а не завершает сессию, страницы, посещенные пользователем, могут быть просмотрены злоумышленником. Поскольку идентификатор сессии не был отмечен как недействительный, атакующий получит доступ к страницам сервера без повторной аутентификации.
Продолжение следует.
Использованы материалы сайт
Бойцев О.М., boyscout@gmail.ru
Компьютерная газета. Статья была опубликована в номере 06 за 2006 год в рубрике безопасность
