SQL-инъекция это наиболее опасный тип атаки, ведь именно она стоит за бесчисленным количеством случаев взлома переживших корпоративные сайты и порталы, и просто личные домашние страницы. Действительности защитить свой проект довольно легко — для этого нужно прежде всего понять в чем суть этой проблемы и внести в код некоторые изменения для защиты.
Что такое SQL-инъекция
SQL-инъекцией называют действия, которые нужно осуществить, чтобы выполнить свой собственный запрос к базе данных, без вашего ведома. Чаще всего это происходит когда вы предлагаете пользователю отправить какую-то информацию на сервер, но вместо желаемой информации злоумышленник отсылает свой запрос, который, по неосторожности, выполняется сервером. С помощью такого запроса злоумышленник может не только получить запрещенную информацию из базы данных, но и, при определенных условиях, внести в нее изменения, а также выполнить системные команды.
Примеры SQL-инъекций
Отправить свой запрос злоумышленник может не только вписав его в поле для ввода информации (используя $_POST), он может также подставить свои $_GET переменные в адресную строку, или вручную изменить свои $_COOKIE. Поэтому следует проявлять осмотрительность при работе с этими глобальными массивами данных.
$_POST:
Если у вас на странице есть форма для ввода определенной информации, злоумышленник может использовать ее поля для своих целей. Вместо ожидаемых строк (имя, пароль и т.д.) он введет в такое поле свой собственный запрос.

Большинство таких SQL-инъекций выглядят следующим образом:
Скажем, мы имеем форму для авторизации пользователей. Если мы введем такой код в поле логина, мы сможем использовать нашу SQL-инъекцию для получения доступа даже без надлежащих проверок. Как это работает? Рассмотрим какой все же запрос мы получим в результате наших действий:
Итак как видно из примера, наш код будет успешно выполнен. А так как выражение 1=1 будет всегда возвращать true, мы гарантированно получим доступ.
Вас скорее всего заинтересует, для чего нам двойной дефис (--). Этот двойной прочерк в конце строки сообщает SQL серверу, что ему следует проигнорировать остальные запросы. Если же вы хотите написать инъекцию не для SQL сервера, то в таком случае, вам пригодится замена двойного дефиса на одинарный апостроф.
Обратите внимание, приведенный выше пример — это просто наиболее стандартный вариант, но далеко не единственный. Их количество просто поражает, и все зависит от того как работает голова злоумышленника.
Примеры еще некоторых наиболее распространенных инъекций:
$_GET
Также довольно часто злоумышленники используют адресную строку (URL) для своих атак. Этот метод также как и предыдущий, не менее опасен. Когда на сервере используется PHP и MySQL (на данный момент, самая популярная комбинация), адрес к скрипту как правило выглядит примерно следующим образом:
Добавляя к такой строке немножко SQL-а можно делать страшные вещи:
В данном случае использован знак # вместо двойного дефиса, так как он говорит SQL серверу проигнорировать все последующие запросы, которые будут идти после нашего. И что самое опасное (если вы еще не заметили), мы только что сказали серверу изъять табличку с пользователями. Данный пример хорошо демонстрирует насколько опасными могут быть SQL-инъекции.
Что нужно сделать для защиты своих скриптов от SQL-инъекций
Мы уже знаем, что уязвимость на SQL-инъекциях возникает тогда, когда информация от пользователей попадает в запрос к базе данных, без соответствующей обработки. Итак следующим шагом идет написание безопасных скриптов.
К счастью, данная опасность известна уже достаточно давно. В PHP даже появилась специальная функция (начиная с версии 4.3.0), которая борется с этим типом атак — mysql_real_escape_string.
mysql_real_escape_string превращает строку на безопасную для употребления в запросах к базе данных, путем экранирования всех потенциально опасных символов. Как правило таким последовательным знаком является одинарный апостроф ('), который после использования этой функции будет экранирован (\').
Для того чтобы защититься от SQL-инъекции, все внешние параметры ($_GET, $_POST, $_COOKIE), следует прежде чем включить в SQL запрос, проработать с помощью mysql_real_escape_string(), а в самом запросе поместить их в одинарном апострофе. Если придерживаться этого простого правила, тогда действия злоумышленника приведут к формированию безопасных запросов, так как весь текст его SQL-инъекций теперь внутри апострофов.
Давайте рассмотрим что же в действительности выполняет сервер при такой обработке:
SQL-инъекция (строка которую злоумышленник вписал в поле «Логин» вместо своего логина):
PHP:
MySQL:
То есть, при таком запросе, вместо опасных действий, мы стараемся выбрать данные пользователя у которого довольно странный username (sql\'or 1=1-).
Можно пойти дальше и написать функционал который будет автоматически обрабатывать массивы $_GET, $_POST и $_COOKIE соответствующим образом, но это все зависит только от ваших пожеланий. Запомнить следует только то, нужно защитить все места где в базу данных передаются данные от пользователя.
Что такое SQL-инъекция
SQL-инъекцией называют действия, которые нужно осуществить, чтобы выполнить свой собственный запрос к базе данных, без вашего ведома. Чаще всего это происходит когда вы предлагаете пользователю отправить какую-то информацию на сервер, но вместо желаемой информации злоумышленник отсылает свой запрос, который, по неосторожности, выполняется сервером. С помощью такого запроса злоумышленник может не только получить запрещенную информацию из базы данных, но и, при определенных условиях, внести в нее изменения, а также выполнить системные команды.
Примеры SQL-инъекций
Отправить свой запрос злоумышленник может не только вписав его в поле для ввода информации (используя $_POST), он может также подставить свои $_GET переменные в адресную строку, или вручную изменить свои $_COOKIE. Поэтому следует проявлять осмотрительность при работе с этими глобальными массивами данных.
$_POST:
Если у вас на странице есть форма для ввода определенной информации, злоумышленник может использовать ее поля для своих целей. Вместо ожидаемых строк (имя, пароль и т.д.) он введет в такое поле свой собственный запрос.

Большинство таких SQL-инъекций выглядят следующим образом:
asd' or 1=1--
Скажем, мы имеем форму для авторизации пользователей. Если мы введем такой код в поле логина, мы сможем использовать нашу SQL-инъекцию для получения доступа даже без надлежащих проверок. Как это работает? Рассмотрим какой все же запрос мы получим в результате наших действий:
SELECT * FROM users WHERE username = 'asd' or 1=1--' and password = 'asd'
Итак как видно из примера, наш код будет успешно выполнен. А так как выражение 1=1 будет всегда возвращать true, мы гарантированно получим доступ.
Вас скорее всего заинтересует, для чего нам двойной дефис (--). Этот двойной прочерк в конце строки сообщает SQL серверу, что ему следует проигнорировать остальные запросы. Если же вы хотите написать инъекцию не для SQL сервера, то в таком случае, вам пригодится замена двойного дефиса на одинарный апостроф.
Обратите внимание, приведенный выше пример — это просто наиболее стандартный вариант, но далеко не единственный. Их количество просто поражает, и все зависит от того как работает голова злоумышленника.
Примеры еще некоторых наиболее распространенных инъекций:
') or ('1'='1
"or "1"="1
' or '1'='1
Or 1=1--
" or 1=1--
' or 1=1--
$_GET
Также довольно часто злоумышленники используют адресную строку (URL) для своих атак. Этот метод также как и предыдущий, не менее опасен. Когда на сервере используется PHP и MySQL (на данный момент, самая популярная комбинация), адрес к скрипту как правило выглядит примерно следующим образом:
http://somesite.com/login_script.php?id=1
Добавляя к такой строке немножко SQL-а можно делать страшные вещи:
http://somesite.com/login_script.php?id=1‘; DROP TABLE login; #
В данном случае использован знак # вместо двойного дефиса, так как он говорит SQL серверу проигнорировать все последующие запросы, которые будут идти после нашего. И что самое опасное (если вы еще не заметили), мы только что сказали серверу изъять табличку с пользователями. Данный пример хорошо демонстрирует насколько опасными могут быть SQL-инъекции.
Что нужно сделать для защиты своих скриптов от SQL-инъекций
Мы уже знаем, что уязвимость на SQL-инъекциях возникает тогда, когда информация от пользователей попадает в запрос к базе данных, без соответствующей обработки. Итак следующим шагом идет написание безопасных скриптов.
К счастью, данная опасность известна уже достаточно давно. В PHP даже появилась специальная функция (начиная с версии 4.3.0), которая борется с этим типом атак — mysql_real_escape_string.
mysql_real_escape_string превращает строку на безопасную для употребления в запросах к базе данных, путем экранирования всех потенциально опасных символов. Как правило таким последовательным знаком является одинарный апостроф ('), который после использования этой функции будет экранирован (\').
Для того чтобы защититься от SQL-инъекции, все внешние параметры ($_GET, $_POST, $_COOKIE), следует прежде чем включить в SQL запрос, проработать с помощью mysql_real_escape_string(), а в самом запросе поместить их в одинарном апострофе. Если придерживаться этого простого правила, тогда действия злоумышленника приведут к формированию безопасных запросов, так как весь текст его SQL-инъекций теперь внутри апострофов.
Давайте рассмотрим что же в действительности выполняет сервер при такой обработке:
SQL-инъекция (строка которую злоумышленник вписал в поле «Логин» вместо своего логина):
sql' or 1=1--
PHP:
$name = mysql_real_escape_string($_POST['username']);
$res = mysql_query("SELECT * FROM users WHERE username = '".$name."' and password = 'asd'");
MySQL:
SELECT * FROM users WHERE username = 'sql\' or 1=1--' and password = 'asd'
То есть, при таком запросе, вместо опасных действий, мы стараемся выбрать данные пользователя у которого довольно странный username (sql\'or 1=1-).
Можно пойти дальше и написать функционал который будет автоматически обрабатывать массивы $_GET, $_POST и $_COOKIE соответствующим образом, но это все зависит только от ваших пожеланий. Запомнить следует только то, нужно защитить все места где в базу данных передаются данные от пользователя.