Защита от хакеров корпоративных сетей

и заставляет сервер игнорировать выражение 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-адрес с двумя специфичными параметрами: