50. Уязвимость «sql Injection». Примеры. Методы устранения.
https://ru.wikipedia.org/wiki/Внедрение_SQL-кода
Внедрение SQL-кода (SQL-инъекция, SQL injection) – уязвимость, возникающая в следствие некорректной обработки принимаемых от клиента данных и позволяющая атакующей стороне выполнить произвольный SQL-скрипт на стороне сервера.
Внедрение SQL, в зависимости от типа используемой СУБД и условий внедрения, может дать возможность атакующему выполнить произвольный запрос к базе данных (например, прочитать содержимое любых таблиц, удалить, изменить или добавить данные), получить возможность чтения и/или записи локальных файлов и выполнения произвольных команд на атакуемом сервере.Типы:
Классическая SQLI
Слепая (blind) SQL инъекция
Специфическая для конкретной системы управления базами данных SQLI
Составные SQLI (например, в паре с XSS атакой)
Поиск скриптов, уязвимых для атаки
На данном этапе злоумышленник изучает поведение скриптов сервера при манипуляции входными параметрами с целью обнаружения их аномального поведения. Манипуляция происходит всеми возможными параметрами:
Данными, передаваемыми через методы POST и GET
Значениями [HTTP-Cookie]
HTTP_REFERER (для скриптов)
AUTH_USER и AUTH_PASSWORD (при использовании аутентификации)
Как правило, манипуляция сводится к подстановке в параметры символа одинарной (реже двойной или обратной) кавычки.
Аномальным поведением считается любое поведение, при котором страницы, получаемые до и после подстановки кавычек, различаются (и при этом не выведена страница о неверном формате параметров).
Наиболее частые примеры аномального поведения: • выводится сообщение о различных ошибках;
при запросе данных (например, новости или списка продукции) запрашиваемые данные не выводятся вообще, хотя страница отображается
Простая инъекция
Имеем следующий запрос:
s |
tatement
= "SELECT
*
FROM
users WHERE
name =
'"
+ userName + "';"
П
ри
подстановке
в
параметр
userName такой
строки:
a';DROP
TABLE
users; SELECT
*
FROM
userinfo WHERE
't'
=
't
Получаем запрос, удаляющий таблицу users:
SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';
Blind SQL injection
Используется для поиска и эксплуатации уязвимостей на сервере, отключен вывод сообщений об ошибках и результаты инъекции не видны злоумышленнику. Content-based blind SQLI
Для этого типа атаки злоумышленник пытается определить уязвимые параметр, сравнивая результаты двух запросов, которые возвращают TRUE или FALSE. URL для отображения позиции:
http://www.shop.local/item.php?id=34
Соответствующий SQL-запрос:
SELECT name, description, price FROM Store_table WHERE id = 34
Атакующий изменяет параметры следующим образом:
http://www.shop.local/item.php?id=34 and 1=2
Запрос принимает вид:
SELECT name, description, price FROM Store_table WHERE ID = 34 and 1=2
Такое условие вернет FALSE, следовательно, позиция не будет отображена. Атакующий снова меняет параметры:
http://www.shop.local/item.php?id=34 and 1=1
Запрос принимает вид:
SELECT name, description, price FROM Store_table WHERE ID = 34 and 1=1
Такое условие вычисляется в TRUE, позиция отображается на странице. Это ясно дает понять, что данный запрос имеет уязвимость. Time-based Blind SQL Injection
При использовании этого вида атаки, злоумышленник вставляет в запрос долгую по времени операцию, например, sleep. Если ответ от сервера не произошел мгновенно, то приложение уязвимо.
http://www.shop.local/item.php?id=34 and if(1=1, sleep(10), false)
Слепые инъекции часто используют для сбора информации о схеме базы данных и версии СУБД, хотя это требует большого числа запросов.
http://www.shop.local/item.php?id=34 and if(1=1, sleep(10), false) AND
|
Задержка ответа на такой запрос говорит об использовании 5 версии MySQL.
Методы устранения: 1) Использование параметризованных запросов.
Многие сервера баз данных поддерживают возможность отправки параметризованных запросов (подготовленные выражения). При этом параметры запроса отправляются на сервер отдельно от самого запроса либо автоматически экранируются клиентской библиотекой. Например, в Java — класс PreparedStatement. 2) Использование белых списков для идентификаторов и ключевых слов. Все допустимые имена таблиц, полей и ключевые слова, используемые для формирования запроса, должны быть жестко прописаны в коде и вычисляться на основании пользовательского ввода.
Хранимые процедуры.
Можно рассматривать как альтернативу параметризованных запросов, но только при условии, что хранимая процедура написана безопасно (не формирует запрос динамически).
Экранирование спецсимволов и фильтрация входных данных.
Минимальные меры предосторожности при отсутствии возможности соблюдать предыдущие правила.
Разграничение прав доступа.
При подключении к базе должна использоваться отдельная учетная запись с максимально ограниченными привилегиями.