Войти
Классификация атакующего вектора SQL-инъекции по состоянию на 2010 год. SQL-инъекция - это метод внедрения кода, используемый для атаки приложений, управляемых данными, в которых вредоносные операторы SQL вставляются в поле ввода для выполнения (например, для дампа содержимого базы данных нападающему). SQL-инъекция должна использовать уязвимость безопасности в программном обеспечении приложения, например, когда пользовательский ввод неправильно отфильтрован для строкового литерала escape-символов, встроенных в операторы SQL, либо пользовательский ввод не строго типизирован и выполняется неожиданно. SQL-инъекция в основном известна как атака вектор для веб-сайтов, но может использоваться для атаки на любой тип базы данных SQL.
Атаки с использованием SQL-инъекций позволяют злоумышленникам подделать идентификационные данные, подделать существующие данные, вызвать проблемы отказа, такие как аннулирование транзакций или изменение балансов, позволяют полностью раскрыть все данные в системе, уничтожить данные или сделать их недоступными по иным причинам и станьте администраторами сервера базы данных.
В исследовании 2012 года было отмечено, что в среднем веб-приложение подвергалось 4 атакам в месяц, а розничные продавцы получали вдвое больше атак, чем другие отрасли.
Первые публичные обсуждения внедрения SQL-кода начались примерно в 1998 году; например, статья 1998 года в Phrack Magazine.
SQL-инъекция (SQLI) была признана одной из 10 основных уязвимостей веб-приложений в 2007 и 2010 годах по версии Open Web Application Security Проект. В 2013 году SQLI был признан атакой номер один в первой десятке OWASP. Существует четыре основных подкласса внедрения SQL:
Storm Worm - одно из представлений составного SQLI.
Эта классификация представляет состояние SQLI с учетом его эволюции до 2010 г. - ведется дальнейшее уточнение.
Эта форма внедрения происходит, когда пользовательский ввод не фильтруется для escape-символов и затем передается в оператор SQL. Это приводит к потенциальной манипуляции операторами, выполняемыми в базе данных конечным пользователем приложения.
Следующая строка кода иллюстрирует эту уязвимость:
statement = "SELECT * FROM users WHERE name = '" + userName + "';"
Этот код SQL предназначен для извлечения записей указанного имени пользователя из своей таблицы пользователей. Однако, если переменная userName определенным образом создается злоумышленником, оператор SQL может сделать больше, чем предполагал автор кода. Например, установка переменной "userName" как:
'OR' 1 '=' 1
или использование комментариев даже для блокировки остальной части запроса (существует три типа комментариев SQL). три строки имеют пробел в конце:
'OR' 1 '=' 1 '-' OR '1' = '1' {'OR' 1 '=' 1 '/ *отображает один из следующих операторов SQL на родительском языке:
SELECT * FROM users WHERE name = '' OR '1' = '1';
SELECT * FROM users WHERE name = '' OR ' 1 '=' 1 '-';
Если бы этот код использовался в процедуре аутентификации, то этот пример можно было бы использовать для принудительного выбора каждого поля данных (*) от всех пользователей, а не от одного конкретного имени пользователя, как предполагал кодировщик, потому что оценка «1» = «1» всегда верна.
Следующее значение «userName» в приведенной ниже инструкции приведет к удалению таблицы «users», а также к выбору всех данных из таблицы «userinfo» (по сути, раскрывая информацию о каждом пользователе), используя API, который позволяет использовать несколько операторов:
a '; DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 'tЭтот ввод отображает окончательный оператор SQL следующим образом и указан:
SELECT * FROM users WHERE name =' a '; DROP TABLE users; ВЫБРАТЬ * ОТ userinfo WHERE 't' = 't';
В то время как большинство реализаций SQL-сервера позволяют выполнять несколько операторов с одним вызовом таким образом, некоторые API-интерфейсы SQL, такие как PHP mysql_query (), не позволяют этого для причины безопасности. Это не позволяет злоумышленникам вводить полностью отдельные запросы, но не мешает им изменять запросы.
Слепая SQL-инъекция используется, когда веб-приложение уязвимо для SQL-инъекции, но результаты инъекции не видны злоумышленнику. Страница с уязвимостью может не отображать данные, но будет отображаться по-разному в зависимости от результатов логического оператора, введенного в законный оператор SQL, вызванный для этой страницы. Этот тип атаки традиционно считался трудоемким, потому что для каждого восстановленного бита нужно было создавать новый оператор, и в зависимости от его структуры атака может состоять из множества неудачных запросов. Недавние достижения позволили каждому запросу восстанавливать несколько битов без неудачных запросов, что обеспечивает более последовательное и эффективное извлечение. Существует несколько инструментов, которые могут автоматизировать эти атаки после того, как будут установлены местоположение уязвимости и целевая информация.
Один тип слепой инъекции SQL заставляет базу данных оценивать логическое заявление на обычном экране приложения. Например, веб-сайт рецензии на книгу использует строку запроса , чтобы определить, какую рецензию на книгу отображать. Таким образом, URL https://books.example.com/review?id=5заставит сервер выполнить запрос
SELECT * FROM bookreviews WHERE ID = '5 ';
, из которого он будет заполнять страницу обзора данными из обзора с ID 5, хранящимися в таблице обзоры книг. Запрос полностью выполняется на сервере; пользователь не знает имен базы данных, таблицы или полей, а также не знает строку запроса. Пользователь видит только то, что указанный выше URL возвращает обзор книги. хакер может загрузить URL-адреса https://books.example.com/review?id=5 OR 1 = 1https://books.example.com/review?id=5 AND 1 = 2
SELECT * FROM bookreviews WHERE ID = '5' OR '1' = ' 1 '; ВЫБРАТЬ * ИЗ обзоров книг ГДЕ ID = '5' И '1' = '2';
соответственно. Если исходный обзор загружается с URL-адресом "1 = 1", а по URL-адресу "1 = 2" возвращается пустая страница или страница с ошибкой, а возвращенная страница не была создана для предупреждения пользователя о недопустимом вводе или другом Словом, был обнаружен входным тестовым сценарием, сайт, вероятно, уязвим для атаки с использованием SQL-инъекции, поскольку запрос, скорее всего, будет успешно пройден в обоих случаях. Хакер может продолжить эту строку запроса, предназначенную для выявления номера версии MySQL, запущенной на сервере: https://books.example.com/review?id=5 AND подстрока (@@ version, 1, INSTR (@@ version, '.') - 1) = 4
Вторая Заказ SQL-инъекции происходит, когда отправленные значения содержат вредоносные команды, которые сохраняются, а не выполняются немедленно. В некоторых случаях приложение может правильно закодировать инструкцию SQL и сохранить ее как действительный SQL. Затем другая часть этого приложения без элементов управления для защиты от внедрения SQL может выполнить этот сохраненный оператор SQL. Эта атака требует дополнительных знаний о том, как в дальнейшем используются представленные значения. Автоматические сканеры безопасности веб-приложений не смогут легко обнаружить этот тип SQL-инъекции, и, возможно, потребуется вручную указать, где проверять наличие доказательств того, что это делается.
SQL-инъекция - это хорошо известная атака, которую легко предотвратить с помощью простых мер. После очевидной атаки SQL-инъекции на TalkTalk в 2015 году BBC сообщила, что эксперты по безопасности были ошеломлены тем, что такая большая компания может быть уязвима для этого.
SQL Инъекционная фильтрация работает аналогично спам-фильтрам. Брандмауэры баз данных обнаруживают SQL-инъекции на основе количества недопустимых запросов от хоста, при наличии блоков OR и UNION внутри запроса или других.
На большинстве платформ разработки параметризованные операторы которые работают с параметрами, могут использоваться (иногда называемые заполнителями или связывающими переменными ) вместо встраивания пользовательского ввода в оператор. Заполнитель может хранить только значение данного типа, но не произвольный фрагмент SQL. Следовательно, SQL-инъекция будет просто рассматриваться как странное (и, вероятно, недопустимое) значение параметра. Во многих случаях оператор SQL является фиксированным, и каждый параметр представляет собой скаляр, а не таблицу. Затем пользовательский ввод назначается (привязан) к параметру.
Легко сказать, использование параметризованных запросов может определенно предотвратить внедрение SQL. В основном это означает, что ваши переменные не являются строками запроса, которые могут принимать произвольные входные данные SQL, однако некоторые параметры данных типов определенно необходимы. Параметризованные запросы требуют от разработчика определения всего кода. Следовательно, без параметризованных запросов любой может ввести в поле любой код SQL и стереть базу данных. Но если бы параметры были установлены на '@username', то человек мог бы только ввести имя пользователя без какого-либо кода.
Использование объектно-реляционное сопоставление библиотек избавляет от необходимости писать код SQL. Фактическая библиотека ORM будет генерировать параметризованные операторы SQL из объектно-ориентированного кода.
Простым, хотя и подверженным ошибкам способом предотвращения инъекций является экранирование символов, которые имеют особое значение в SQL. В руководстве по СУБД SQL объясняется, какие символы имеют особое значение, что позволяет создать исчерпывающий черный список символов, требующих перевода. Например, каждое вхождение одинарной кавычки (') в параметре необходимо заменить двумя одинарными кавычками (' '), чтобы сформировать допустимый строковый литерал SQL. Например, в PHP параметры обычно экранируются с помощью функции mysqli_real_escape_string ();перед отправкой запроса SQL:
$ mysqli = new mysqli ('hostname', ' db_username ',' db_password ',' db_name '); $ query = sprintf ("ВЫБРАТЬ * ОТ ʻUsers` WHERE UserName = '% s' AND Password = '% s'", $ mysqli->real_escape_string ($ username), $ mysqli->real_escape_string ($ password)); $ mysqli->query ($ query);Эта функция добавляет обратную косую черту к следующим символам: \ x00, \n, \r, \, ', "и \ x1a. Эта функция обычно используется для обеспечения безопасности данных перед отправкой запроса в MySQL.. PHP имеет аналогичные функции для других систем баз данных, таких как pg_escape_string () для PostgreSQL. Функция добавляет косые черты (строка $ str)работает для экранирования символов и особенно используется для запросов к базам данных, которые не имеют функций экранирования в PHP. Он возвращает строку с обратной косой чертой перед символами, которые необходимо экранировать в запросах к базе данных и т. Д. Это символы одинарной кавычки ('), двойной кавычки ("), обратной косой черты (\) и NUL (нулевой байт).. Обычно передача экранированных строк в SQL подвержена ошибкам, потому что легко забыть экранировать заданную строку. Создание прозрачного слоя для защиты ввода может уменьшить эту подверженность ошибкам, если не полностью устранить ее.
Целочисленные, плавающие или логические строковые параметры могут быть проверены, если их значение является допустимым представлением для данного типа. Строки, которые должны следовать некоторому строгому шаблону (дата, UUID, только буквенно-цифровые и т. Д.), Могут быть проверены, если они соответствуют этому шаблону.
Ограничение разрешений на вход в базу данных, используемое веб-приложением, только необходимыми, может помочь снизить эффективность любых атак с использованием SQL-инъекций, использующих любые ошибки в веб-приложение.
Например, на Microsoft SQL Serve r, вход в базу данных может быть ограничен выбором некоторых системных таблиц, что ограничит эксплойты, пытающиеся вставить JavaScript во все текстовые столбцы в базе данных.
запретить выбор sys.sysobjects для входа в веб-базу данных; запретить выбор sys.objects для входа в веб-базу данных; запретить выбор в sys.tables для webdatabaselogon; запретить выбор в sys.views для входа в веб-базу данных; запретить выбор в sys.packages для входа в веб-базу данных;
