База данных под прицелом

Крис Касперски aka мыщъх

Спецвыпуск: Хакер, номер #047, стр. 047-064-4

Скорректированный URL-запрос может быть таким: http://www.victim.com/index.php?id=12' или таким: http://www.victim.com/index.php?id=12+union+select+null,null,null+from+table1 /*.

Последний запрос работает только на MySQL версии 4.х и выше, поддерживающей union (объединение нескольких запросов в одной строке). Здесь table1 – имя таблицы, содержимое которой необходимо вывести на экран.

Атаки подобного типа называются SQL-инъекциями (SQL-injection) и являются частным случаем атак, основанных на ошибках фильтрации и интерполяции строк. Мы словно впрыскиваем в форму запроса к базе данных собственную команду, прокалывая хакерской иглой тело уязвимого скрипта (отсюда и "инъекции"). Это не ошибка SQL-сервера (как часто принято считать). Это – ошибка разработчиков скрипта. Грамотно спроектированный скрипт должен проверять пользовательский ввод на предмет присутствия потенциально опасных символов (одиночная кавычка, точка с запятой, двойное тире, а для MySQL еще и символ звездочки) включая и их шестнадцатеричные эквиваленты, задаваемые через префикс "%", а именно: %27, %2A и %3B. Если хотя бы одно из условий фильтрации не проверяется или проверяется не везде (например, остаются не отфильтрованными строки URL или cookie), в скрипте образуется дыра, через которую его можно атаковать.

Впрочем, сделать это будет не так уж и просто. Необходимо иметь опыт программирования на Perl/PHP и знать, как может выглядеть та или иная форма запроса и как чаще всего именуются поля таблицы, в противном случае интерполяция ни к чему не приведет. Непосредственной возможности определения имен полей и таблиц у хакера нет, и ему приходится действовать методом слепого перебора (blinding).

Однако большинство администраторов и Web-мастеров слишком ленивы, чтобы разрабатывать все необходимые им скрипты самостоятельно, и чаще они используют готовые решения, исходные тексты которых свободно доступны в сети. Причем, большинство этих скриптов дырявы как ведро без дна. Взять, к примеру, тот же PHP Nuke, в котором обнаруживаются все новые и новые уязвимости.

Приблизительная стратегия поиска дыр выглядит так. Скачиваем исходные тексты PHP Nukе (или любой другой портальной системы), устанавливаем их на свой локальный компьютер, проходимся глобальным поиском по всем файлам, откладывая в сторонку все те, что обращаются к базе данных (вызов типа mysql_query/mysql_db_query или типа того). Далее прокручиваем курсор вверх и смотрим – где-то поблизости должна быть расположена строка запроса к базе (например: $query = "SELECT user_email, user_id FROM ${prefix}_users WHERE user_id = '$cookie[0]'"). Определяем имена переменных, подставляемых в базу, находим код, ответственный за передачу параметров пользовательского ввода и анализируем условия фильтрации.