SQL инъекции и как от них защититься

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

Сегодня я затрону давно обещанную тему про SQL инъекции (не прошло и полгода… или прошло… – прим.ред.). Я постараюсь описать их как можно проще и покажу основный приёмы от их защиты (если конечно то, что я опишу, можно охарактеризовать как приёмы).

Прежде, чем начать, я хотел бы сослаться на википедию. Там выложена довольно неплохая статья про SQl injection, с которой стоит ознакомиться. В своей статье я опишу всё немного иначе, затрону то, чего там нет, но скорее всего в чём-то и повторюсь, но думаю в этом ничего криминального нет. Итак…

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

Рассмотрим простой пример, чтобы показать как работают инъекции. Примитивный запрос формы авторизации – пользователь вводит логин и пароль, а далее идёт сравнение введённых данных с теми, что есть в базе данных.

В случае, когда переданные параметры не проверяются, можно творить, что угодно. К примеру, вместо логина можно ввести admin"/*, а в качестве пароля что угодно (иди не вводить ничего), тогда запрос будет выглядеть так:

И такой запрос пройдёт как валидный и пользователь зайдёт под ником admin. Почему? /* – является началом комментария, и, в отличие от PHP, его необязательно закрывать. Вот и всё.

Отсюда лезет вывод – необходимо проверять введённые данные, в первую очередь на уровне PHP. На уровне JavaScript тоже неплохо проверять, но только как дополнение к проверке на PHP. Возьмём тот же пример с проверками на JavaScript. Вроде бы ничего ввести не можем, НО. К примеру, у нас включён register_globals (подробнее в статье "Почему опасно включать параметр register_globals"), тогда в адресную строку нужно лишь тупо дописать ?login=admin"/* и всё, результат тот же самый.

Защита от SQL injection

Числовые строки

Начну с простого, с числовой строки. Если мы передаём число, то чтобы в него ничего не внедрили, необходимо, чтобы все символы, кроме числовых, были выкинуты. Два способа:

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

  $number = (int)$_POST['number'];

  Минус этого метода (или не минус, кому как) следующий – если передаётся не число, то в переменную $number  попадёт нолик. Страшного тут ничего нет, но только в случае, если есть какая-то секретная нулевая запись. Впрочем, сценарий всегда можно переписать, проверив, является ли значение нулём.

• Замена по регулярному выражению, где обрубается всё, кроме цифр.

  $number = preg_replace ("/[^0-9]/", "", $_POST['number']);

Текстовые строки

С текстовыми строками не всё так просто. Конечно, если нужны только буквы и цифры, то все остальные символы можно спокойно отрубить регэкспом:

Но иногда всякие скобочки, галочки бывают реально нужны. Что делать?

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

1. Одинарные и двойные кавычки. Они используются в запросах для выделения. Думаю ещё из примера выше ясно, почему стоит их запрещать. В любом случае с ними заморачиваться особо и не надо, всегда есть htmlspecialchars и addslashes.
2. Знак равенства. Казалось бы обычный безобидный значок, но и он может напакостить. К примеру, имеем запрос:

   $sql = 'SELECT * FROM users WHERE id='.$id;

   Передадим в качестве параметра  1 OR name="admin". В результате запрос будет выглядеть как

   SELECT * FROM users WHERE id=1 OR name="admin"

   Думаю понятно, что если запретить символ равенства, то вместо name="admin" будет name"admin", а это приведёт к ошибке и запрос не пройдёт.

3. Символы комментариев. К символам комментариев относятся двойное тире и слэш со звёздочкой (его показывали в самом первом примере). Тут всё почти как с комментированием в PHP, то есть вместо двойного слэша используется двойное тире и комментит только одну строку, а слэш со звёздочкой точно также обозначен, только в SQL комментирует до конца запроса и его можно не закрывать. К примеру, есть запрос:

   SELECT * FROM users
   WHERE name=$id
     AND password=$pass

   Если мы внедрим вместо $id значение 1-- то последняя строчка с паролем не закомментируется и инъекция не прокатит. Но всё будет иначе, если вместо двойного тире использовать /*, тогда последняя строчка закомментируется.

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

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

На сегодня всё. Берегите свои скрипты от всякой нечисти. Удачи!

защита

(голосов: 4, средний: 5.00 из 5)