Инъекция sql

Многие web-разработчики не в курсе того, как запросы SQL могут быть подделаны, и считают, что SQL-запрос это надёжная команда. SQL-запросы могут обойти управление доступом, стандартную аутентификацию и проверку авторизации, а некоторые SQL-запросы могут даже дать доступ к командам ОС хоста.

Direct SQL Command Injection это такая техника, когда взломщик создаёт или изменяет текущие команды SQL для получения доступа к скрытым данным, их переопределения или даже для выполнения опасных команд системного уровня на хосте БД. Это выполняется с помощью приложения, принимающего пользовательский ввод, и сочетания его со static-параметрами для построения SQL-запроса. Следующие примеры (к сожалению...) основаны на реальных фактах.

Благодаря отсутствию проверки ввода и соединения с БД или поведению superuser'а или того, кто может создавать пользователей, взломщик может создать superuser'а в вашей БД.

Пример 4-6. Разделение результата выполнения запроса на страницы... и создание superuser'ов (PostgreSQL и MySQL) $offset = argv[0]; // видите, никакой проверки ввода! $query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;"; // с PostgreSQL $result = pg_exec($conn, $query); // с MySQL $result = mysql_query($query);

Обычно пользователи щёлкают ссылки 'next', 'prev', где $offset кодируется в URL. Скрипт ожидает, что входящее $offset это 10-ричное число. Однако кто-нибудь может попытаться вломиться, присоединив urlencode()'ированную форму следующей информации к URL:

// в PostgreSQL 0; insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd) select 'crack', usesysid, 't','t','crack' from pg_shadow where usename='postgres'; -- // в MySQL 0; UPDATE user SET Password=PASSWORD('crack') WHERE user='root'; FLUSH PRIVILEGES;

Если это произойдёт, то скрипт даст доступ superuser'а к нему. Заметьте, что 0; предоставлен для того, чтобы задать правильное смещение/offset для запроса-оригинала и прервать его.

Примечание: обычной техникой является форсирование игнорирования SQL-разборщиком остальной части запроса, написанного разработчиком, с помощью --(знака комментария в SQL).

Возможно получение паролей путём обмана ваших страниц с результатами поиска. Взломщику нужно лишь проверить, имеется ли отправленная переменная, используемая в SQL-операторе, которая не обрабатывается надлежащим образом. Эти фильтры могут быть установлены обычно в предыдущей форме для специализирования вариантов WHERE, ORDER BY, LIMIT и OFFSET в операторах SELECT. Если ваша БД поддерживает конструкцию UNION, взломщик может попытаться присоединить к оригинальному запросу целый запрос на список паролей из произвольной таблицы. Использование шифрованных полей password настоятельно рекомендуется.

Пример 4-7. Листинг статей ... и некоторых паролей (любой сервер БД) $query = "SELECT id, name, inserted, size FROM products WHERE size = '$size' ORDER BY $order LIMIT $limit, $offset;"; $result = odbc_exec($conn, $query);

Статическая часть запроса может комбинироваться с другим оператором SELECT, который выявит все пароли:

' union select '1', concat(uname||'-'||passwd) as name, '1971-01-01', '0' from usertable; --

Если этот запрос (играя с ' и --) присоединить к одной из переменных, используемых в $query, запрос чудовищно изменится.

SQL UPDATEs также являются субъектами атаки на ваши БД. Есть угроза их расчленения и присоединения к ним совершенно нового запроса. Взломщик может поработать с SET. В этом случае нужно обладать некоторой схемой информации для успешного манипулирования запросом. Это можно сделать, проверив имена переменных формы, или просто выполнив грубое форсирование. Есть не так уж много соглашений по именованию полей для хранения паролей и имён пользователей.

Пример 4-8. От восстановления значения пароля ... до получения дополнительных привилегий (любой сервер БД) $query = "UPDATE usertable SET pwd='$pwd' WHERE uid='$uid';";

Но пользователь-злоумышленник отправляет значение ' or uid like'%admin%'; -- в $uid для изменения пароля admin'а или просто устанавливает в $pwd значение"hehehe', admin='yes', trusted=100 " (с ведомым пробелом) для получения дополнительных привилегий. Затем запрос скручивается:

// $uid == ' or uid like'%admin%'; -- $query = "UPDATE usertable SET pwd='...' WHERE uid='' or uid like '%admin%'; --"; // $pwd == "hehehe', admin='yes', trusted=100 " $query = "UPDATE usertable SET pwd='hehehe', admin='yes', trusted=100 WHERE ...;"

Устрашающий пример того, как может быть получен доступ к командам уровня ОС на некоторых хостах БД.

Пример 4-9. Атака на ОС-хост БД (MSSQL Server) $query = "SELECT * FROM products WHERE id LIKE '%$prod%'"; $result = mssql_query($query);

Если взломщик отправляет значение a%' exec master..xp_cmdshell 'net user test testpass /ADD' -- в $prod, то $query будет:

$query = "SELECT * FROM products WHERE id LIKE '%a%' exec master..xp_cmdshell 'net user test testpass /ADD'--"; $result = mssql_query($query);

MSSQL Server выполняет операторы SQL в пакетном режиме, включая и команды добавления нового пользователя в локальную БД бюджетов. Если такое приложение запущено как sa и служба MSSQLSERVER запущена с достаточными привилегиями, хакер сможет получить бюджет для доступа к данной машине.

Примечание: некоторые из вышеприведённых примеров касаются определённых серверов БД. Это не означает, что аналогичные действия невозможны в отношении других продуктов. Работа вашего сервера БД может быть нарушена каким-нибудь другим способом.