Предотвращение Sql-Инъекций

Предотвращение SQL-инъекций

SQL-инъекция (также известная как повреждение структуры SQL-запроса) — одна из наиболее распространенных и наиболее опасных уязвимостей безопасности.

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

SQL-инъекция — это чисто программная ошибка, не имеющая ничего общего с хост-провайдером.

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

Почему происходят SQL-инъекции?

SQL-инъекции — очень распространенная проблема, но, как ни странно, их также легко предотвратить.

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

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

• Не используйте пользовательские данные в запросах.

Все кажется простым, но это теории; на практике отказаться от динамических запросов невозможно, как невозможно исключить ввод пользовательских данных.

Но это не значит, что избежать инъекций невозможно.

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

Что вы можете сделать, чтобы предотвратить SQL-инъекции?

Хотя решение во многом зависит от конкретного языка программирования, общие принципы предотвращения SQL-инъекций схожи.

Вот несколько примеров того, как это можно сделать: • Используйте динамические запросы только в случае крайней необходимости.

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

Например, вместо динамического SQL в Java вы можете использовать AcceptedStatement() со связанными параметрами, в .

NET вы можете использовать параметризованные запросы, такие как SqlCommand() или OleDbCommand() со связанными параметрами, а в PHP вы можете использовать PDO со строгой типизацией.

параметризованные запросы (с использованием функции BindParam()).

Помимо подготовленных операторов, вы можете использовать хранимые процедуры.

В отличие от подготовленных операторов, хранимые процедуры хранятся в базе данных, но в обоих случаях сначала определяется SQL-запрос и ему передаются параметры.

• Проверка введенных данных в запросах.

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

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

• Не полагайтесь на волшебные цитаты.

Включение параметра Magic_quotes_gpc может предотвратить некоторые (но не все) SQL-инъекции.

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

Вот почему необходимо использовать код, исключающий кавычки.

Вот фрагмент кода, предложенный Джоном Ли:

$username = $_POST['username']; $password = $_POST['password']; if (!get_magic_quotes_gpc()) { $username = addslashes($username); $password = addslashes($password); }

• Регулярное и своевременное обновление обновлений.

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

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

• Удалите все функции, которые вы не используете.

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

Что касается безопасности, то принцип «чем больше, тем лучше» здесь не работает. Например, расширенная системная процедура xp_cmdshell в MS SQL дает доступ к операционной системе, а это просто мечта хакера.

Именно поэтому эту функцию необходимо отключить, как и любые другие, позволяющие легко злоупотреблять функционалом.

• Использование автоматизированных инструментов для поиска SQL-инъекций.

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

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

Одним из простых инструментов (и одним из более-менее надежных) для обнаружения SQL-инъекций является расширение для Firefox под названием SQL-инъекция для меня .

После установки этого расширения инструмент доступен по щелчку правой кнопкой мыши в контекстном меню или из меню Инструменты → Параметры.

Рабочая область SQL Inject ME показана на следующем снимке экрана, и вы можете увидеть, сколько типов тестов вы можете выполнить:

Вы можете выбрать, какой тест запускать и с какими параметрами.

По окончании теста вы увидите отчет о результатах теста.

Для расширения SQL Inject ME можно установить множество параметров, которые показаны на следующих двух снимках экрана:

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