Better PHP

SQL-инъекции

SQL-инъекция — техника, при которой злоумышленник пользуется недостатками в коде приложения, который отвечает за построение динамических SQL-запросов. Злоумышленник получает доступ к привилегированным разделам приложения, получает информацию из базы данных, подменяет данные или даже выполняет опасные команды системного уровня на узле базы данных. Уязвимость возникает, когда разработчики конкатенируют или интерполируют произвольные входные данные в SQL-запросах.

Пример #1 Постраничный вывод результата и… создание суперпользователя в СУБД PostgreSQL

В следующем примере пользовательский ввод интерполируется в SQL-запрос, что помогает злоумышленнику получить учётную запись суперпользователя в базе данных.

<?php

$offset = $_GET['offset']; // Осторожно, нет валидации ввода!
$query  = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;";
$result = pg_query($conn, $query);

?>

В стандартном сценарии пользователи нажимают на ссылки «Вперёд» и «Назад», в URL-адресах которых закодировано смещение, значение которого получает переменная $offset. Скрипт ожидает, что входящее значение для переменной $offset — число. Однако, что если взломщик выполнит попытку взломать систему и добавит к URL-адресу следующее значение:

0;
insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd)
  select 'crack', usesysid, 't','t','crack'
  from pg_shadow where usename='postgres';
--

Если бы это случилось, скрипт предоставил бы злоумышленнику доступ суперпользователя. Обратите внимание, что значение 0; записали, чтобы передать правильное смещение для исходного запроса и завершить запрос.

Замечание:
Распространённый приём, который заставляет SQL-парсер игнорировать остальную часть запроса разработчика, — последовательность символов --, которая играет в SQL роль синтаксиса комментариев.

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

Пример #2 Вывод списка статей… и ряда паролей (любой сервер базы данных)

<?php

$query  = "SELECT id, name, inserted, size FROM products
         WHERE size = '$size'";
$result = odbc_exec($conn, $query);

?>

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

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

Инструкции UPDATE и INSERT также подвержены таким атакам.

Пример #3 От сброса пароля до… получения дополнительных привилегий (любой сервер баз данных)

<?php

$query = "UPDATE usertable SET pwd='$pwd' WHERE uid='$uid';";

?>

Если злоумышленник отправляет значение ' or uid like'%admin%' для переменной $uid, чтобы изменить пароль администратора, или просто присваивает переменной $pwd значение hehehe', trusted=100, admin='yes, чтобы получить дополнительные привилегии, тогда запросы переплетаются:

<?php

// Значение переменной $uid: ' or uid like '%admin%
$query = "UPDATE usertable SET pwd='...' WHERE uid='' or uid like '%admin%';";

// Значение переменной $pwd: hehehe', trusted=100, admin='yes
$query = "UPDATE usertable SET pwd='hehehe', trusted=100, admin='yes' WHERE
...;";

?>

Хотя остаётся ясным, что для успешной атаки злоумышленнику нужны хотя бы частичные знания об архитектуре базы данных, эту информацию часто получают легко. Например, когда код — часть открытого программного обеспечения и лежит в открытом доступе. Информация также раскрывается и закрытым исходным кодом, даже если код закодировали, обфусцировали или скомпилировали, и даже собственным кодом через отображение сообщений об ошибках. Другие методы включают подстановку типичных имён таблиц и столбцов: форма входа в систему, которая использует таблицу users с именами столбцов id, username и password.

Пример #4 Атака на операционную систему сервера базы данных (MSSQL Server)

Страшный пример получения доступа к командам уровня операционной системы на отдельных хостах баз данных.

<?php

$query  = "SELECT * FROM products WHERE id LIKE '%$prod%'";
$result = mssql_query($query);

?>

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

<?php

$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 запустили бы с достаточными привилегиями, у злоумышленника появилась бы учётная запись с доступом к локальной машине.

Замечание:
Часть приведённых примеров привязана к конкретному серверу базы данных, но это не говорит о невозможности похожей атаки на другие продукты. Сервер базы данных подвержен и другим уязвимостям.

Забавный пример проблем, связанных с SQL-инъекциями

Изображение любезно предоставил сайт веб-комиксов » xkcd

Техники защиты

Рекомендуемый способ избежать SQL-инъекций — связать данные подготовленными инструкциями. Параметризованных запросов недостаточно, чтобы на 100 процентов избежать внедрения SQL-инъекций, но это простейший и безопасный способ передать входные данные SQL-инструкциям. Литералы динамических данных в условиях WHERE, SET и VALUES требуется заменить заполнителями. Сервер базы данных свяжет фактические данные при выполнении и отправит отдельно от SQL-команды.

Сервер применяет связывание параметров только для данных. Другие динамические части SQL-запроса требуется отфильтровать по известному списку разрешённых значений.

Пример #5 Избегание SQL-инъекций средствами подготовленных инструкций модуля PDO

<?php

// Динамическая часть SQL-запроса проверяется на соответствие ожидаемым значениям
$sortingOrder = $_GET['sortingOrder'] === 'DESC' ? 'DESC' : 'ASC';
$productId = $_GET['productId'];

// SQL-запрос подготавливается с заполнителем
$stmt = $pdo->prepare("SELECT * FROM products WHERE id LIKE ? ORDER BY price {$sortingOrder}");

// Значение передаётся с подстановочными знаками LIKE
$stmt->execute(["%{$productId}%"]);

?>

Подготовленные инструкции предоставляют модули PDO, MySQLi и другие библиотеки баз данных.

Атаки с внедрением SQL-инъекций обычно основаны на коде, который написали без учёта требований безопасности. Разработчик не должен доверять никаким входным данным, особенно со стороны клиента, даже если входные значения поступают из HTML-блока SELECT, скрытого поля ввода или из cookie. Первый пример показывает, что такой простой запрос легко приводит к катастрофе.

Стратегия глубокой защиты включает набор практик хорошего кода:

Не подключайтесь к базе данных как суперпользователь или владелец базы данных. Используйте только пользователей с минимальными привилегиями.
Проверяйте входные данные на соответствие типу, который ожидался. В PHP содержится много функции для проверки входных данных, от простейших функций для работы с переменными наподобие функции is_numeric() и функций проверки типа символов наподобие функции ctype_digit() и далее к поддержке Perl-совместимых регулярных выражений.
Если приложение ожидает числовые входные данные, рассмотрите применимость проверки данных функцией ctype_digit(), незаметно измените тип входных данных функцией settype() или получите числовое представление входных данных функцией sprintf().
Если на уровне базы данных не поддерживается связывание переменных, возьмите в кавычки каждое пользовательское нечисловое значение, которое передаётся в БД через характерную для конкретной базы данных функцию экранирования строки: mysql_real_escape_string(), sqlite_escape_string() и т. д. Общие функции наподобие addslashes() полезны только в конкретных средах (например, СУБД MySQL в однобайтовой кодировке с отключённым режимом NO_BACKSLASH_ESCAPES), поэтому при работе с БД лучше избегать таких функций.
Ни в каком случае не выводите информации о БД, особенно о структуре. Дополнительную информацию дают разделы «Сообщения об ошибках» и «Функции обработки и логирования ошибок».

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

Нашли ошибку?

Инструкция • Исправление • Сообщение об ошибке

＋Добавить

Примечания пользователей 1 note

down

Richard dot Corfield at gmail dot com ¶

14 years ago

The best way has got to be parameterised queries. Then it doesn't matter what the user types in the data goes to the database as a value. 

A quick search online shows some possibilities in PHP which is great! Even on this site - http://php.net/manual/en/pdo.prepared-statements.php
which also gives the reasons this is good both for security and performance.

＋Добавить