Коллектив авторов - Защита от хакеров корпоративных сетей
Одна из самых больших угроз, вызванная включением данных пользователя в запрос SQL, заключается в передаче злоумышленником дополнительных команд, выполняемых сервером. Представьте, что простенькое приложение захочет просмотреть таблицу данных пользователя. Запрос может выглядеть примерно так:
SELECT * FROM table WHERE x=$data
В этом запросе вместо переменной $data будут подставлены данные пользователя. Затем запрос будет передан системе управления базами данных. А теперь представим, что злоумышленник подготовил следующую строку данных:
1; SELECT * FROM table WHERE y=5
После подстановки в запрос данных пользователя системе управления базами данных будет передано:
SELECT * FROM table WHERE x=1; SELECT * FROM table WHERE y=5
В большинстве случаев это приведет к обработке системой управления базами данных двух отдельных запросов: ожидаемого запроса и непредвиденного дополнительного:
SELECT * FROM table WHERE y=5.
Написано «в большинстве случаев» потому, что каждая система управления базами данных обрабатывает дополнительные запросы по-разному. Одни не допускают выполнения более одного запроса за одно обращение, другие требуют специальных символов для разделения запросов, а третьим символы разделения запросов не нужны. Например, приведенная ниже часть кода является правильной (на самом деле это два запроса, отправленных одновременно) для серверов баз данных Microsoft SQL Server и Sybase SQL:
SELECT * FROM table WHERE x=1 SELECT * FROM table WHERE y=5
Обратите внимание на отсутствие символов разделения запросов между выражениями SELECT.
Важно понимать, что возвращенный результат зависит от ядра базы данных. Некоторые возвращают два набора записей, каждый из которых содержит результаты запроса SELECT. На рисунке 7.1 показан этот случай. Другие могут объединять наборы, если возвращаемые наборы записей состоят из одних и тех же колонок. А большинство приложений написаны таким образом, что возвращают результаты только первого запроса. В этом случае результат второго запроса увидеть нельзя, но это не значит, что он не был выполнен. Сервер MySQL позволяет сохранить результат запроса в файле. В состав MS SQL Server включены процедуры рассылки результатов запроса по электронной почте. И конечно, в обоих случаях не отображается результат выполнения команды DROP.
Рис. 7.1. Некоторые сервера баз данных, как, например, Microsoft SQL Server, разрешают указывать несколько команд в одном SQL-запросеПытаясь передать в запросе дополнительные команды, злоумышленник может указать серверу базы данных на необходимость игнорирования части запроса. Рассмотрим, например, запрос:
SELECT * FROM table WHERE x=$data AND z=4
При подстановке в запрос ранее упомянутых данных получим следующий запрос:
… WHERE x=1; SELECT * FROM table WHERE y=5 AND z=4
В результате во вложенный дополнительный второй запрос оказалось включено выражение AND z=4, которое по замыслу злоумышленника лишнее. Для его исключения из запроса следует использовать символ комментария, который в каждой системе управления базами данных свой. В сервере MS SQL включение двойного дефиса (-) говорит об игнорировании части запроса за ним, который выполняет роль символа комментария, как это показано на рис. 7.2. В MySQL символом комментария служит знак «решетки» (#). Поэтому в случае сервера MySQL подстановка злоумышленником значения
1; SELECT * FROM table WHERE y=5 #
приводит к выполнению запроса
Рис. 7.2. Использование символа комментария в Microsoft SQL Server для игнорирования части запроса… WHERE x=1; SELECT * FROM table WHERE y=5 # AND z=4
и заставляет сервер игнорировать выражение AND z=4.
В этих примерах было известно название атакуемой таблицы, что случается нечасто. Для составления правильного SQL-запроса нужно знать имя таблицы и названия столбцов. Обычно главная проблема в том, что эта информация недоступна пользователям. Но для злоумышленника не все так плохо. Разные системы управления базами данных обеспечивают различные способы получения системной информации о таблицах базы данных. Например, обращаясь с запросом к таблице sysobjects Microsoft SQL Server (с помощью запроса Select * from sysobjects запрос), можно получить информацию о всех зарегистрированных в базе данных объектах, включая хранимые процедуры и названия таблиц.
Занимаясь хакингом SQL, хорошо бы знать возможности серверов баз данных. Из-за особенностей хакинга SQL злоумышленник может не увидеть результатов своей работы, поскольку большинство приложений не предназначены для обработки вложенных запросов. Поэтому злоумышленнику может потребоваться много времени, прежде чем он удостоверится, что получил доступ к базе данных. К счастью, здесь нет легких решений, потому что для нормальной работы большинство команд SQL требуют задания имен таблиц. Следует творчески поработать, чтобы узнать их.
Вслепую или нет, но хакинг SQL возможен. Для этого может потребоваться понимание принципов работы серверов баз данных. Следует познакомиться с хранимыми процедурами и расширениями SQL анализируемого сервера. Например, сервер Microsoft SQL поддерживает хранимую процедуру рассылки результатов запроса по электронной почте. Это может пригодиться для просмотра результатов работы вложенных запросов. Сервер MySQL может сохранять результаты запросов в файле, позволяя впоследствии восстанавливать результат. Всегда следует попытаться использовать дополнительные возможности сервера базы данных с выгодой для себя.
Аутентификация приложений
Обсуждение аутентификации всегда интересно. В каких случаях пользователю необходимо получить доступ к приложению, ведающему данными аутентификации? Каким образом осуществляется аутентификация пользователя? Для однопользовательских приложений это не такие уж и трудные вопросы, но для Web-приложений это серьезная проблема.
Для того чтобы успешно противостоять атакам «грубой силы», часто используются случайные ключи сессии и аутентификации, образующие большое ключевое пространство (общее число возможных ключей). Но в этом подходе два серьезных недостатка.
Во-первых, ключ должен быть действительно случайным. Любая предсказуемость ключа повысит шансы злоумышленника вычислить его. Ключ не следует вычислять при помощи линейной возрастающей функции. Системные функции UNIX /dev/random и /dev/urandom могут не обеспечить необходимой случайности ключей, особенно при генерации ключей большого размера. Например, слишком быстрый вызов функций /dev/random или /dev/ urandom может отразиться на «случайности» генерируемых ключей, потому что в этом случае функции обращаются к предсказуемому генератору псевдослучайных чисел.
Во-вторых, ключевое пространство должно быть достаточно большим по отношению к числу ключей, необходимых в любой момент времени. Пусть ключ имеет 1 млрд возможных значений. Страшно даже подумать об атаке «грубой силы» на ключевое пространство в 1 млрд ключей. Но популярный сайт электронной коммерции может обслуживать около 500 000 открытых сессий каждый рабочий день. В этом случае у злоумышленника хорошие шансы найти подходящий ключ в каждой серии из 1000 проверенных ключей (в среднем) и его не отпугнет последовательный перебор 2000 ключей со случайно выбранного значения.
Рассмотрим некоторые современные схемы аутентификации. Какое-то время назад организация PacketStorm (www.packetstormsecurity.org) решила перепрограммировать на языке Perl программное обеспечение своего Web-форума после нахождения уязвимости в пакете wwwthreads.
Выбранный способ аутентификации оказался очень любопытным. После регистрации пользователю передавался URL-адрес с двумя специфичными параметрами:authkey=rfp.23462382.temp&uname=rfp
Рассматривая систему аутентификации как «черный ящик» без малейшего представления о принципах его работы, была предпринята попытка найти закономерности работы системы при изменении входных данных параметров. Первый шаг состоял в изменении значения параметра authkey: сначала имени пользователя, а затем случайного числа и дополнительной величины «temp». Целью данных манипуляций было проверить возможность аутентификации пользователя с другими случайными недействительными значениями параметра. Не получилось. Затем значение параметра uname было изменено на другое правильное имя пользователя. В результате была получена строка вида
authkey=rfp.23462382.temp&uname=fringe.
После этого удалось зарегистрироваться под именем другого пользователя («fringe»). Исходя из этого, был восстановлен фрагмент программы аутентификации на языке Perl (заметим, что без знания истинного кода форума PacketStorm):
if (-e “authkey_directory/$authkey”) {
print “Welcome $uname!”;
# do stuff as $uname
} else {
print “Error: not authenticated”;
}Таким образом, authkey – это файл, создаваемый при входе в систему с использованием случайного числа. Приведенный фрагмент программы позволяет любому пользователю, изменившему параметр uname, получить доступ к учетной записи иного пользователя, используя известный и правильный authkey (например, свой собственный).
Основываясь на форматах параметров authkey и uname, естественно было предположить, что значение authkey относится к файловой системе. Прежде всего потому, что значение параметра authkey в формате username.999999. temp не похоже на информацию, которую хранят в базе данных. Вполне возможно, что приложение разделяло параметр authkey на три части, используя для запроса к базе данных имя пользователя и случайное число. При этом отпадала необходимость в передаче через значение параметра uname имени пользователя, а постоянное окончание «.temp» становилось бесполезным и бессмысленным. Следуя интуиции и зная, что формат представления параметра authkey похож на задание имени файла, было высказано предположение, что значение параметра authkey определяет имя файла, как в итоге и оказалось.
