Атаки SQL-инъекций представляют огромный риск для веб-приложений, которые зависят от базы данных для создания динамического контента. В этом типе атаки хакеры манипулируют веб-приложением, пытаясь внедрить свои собственные команды SQL в команды, выданные базой данных. В этой статье мы рассмотрим несколько способов тестирования веб-приложений, чтобы определить, уязвимы ли они для атак SQL-инъекций.
Автоматическое сканирование SQL-инъекций
Одной из возможностей является использование автоматического сканера уязвимостей веб-приложений, такого как HP WebInspect, IBM AppScan или Cenzic Hailstorm. Все эти инструменты предлагают простые, автоматизированные способы анализа ваших веб-приложений на предмет потенциальных уязвимостей SQL-инъекций. Тем не менее, они довольно дорогие и стоят до 25 000 долларов за место.
Ручные тесты SQL-инъекций
Что делать плохому разработчику приложений? Вы можете запустить некоторые базовые тесты, чтобы оценить свои веб-приложения на наличие уязвимостей SQL-инъекций, используя не более чем веб-браузер. Во-первых, предостережение: тесты, которые мы описываем, ищут только основные недостатки SQL-инъекций. Они не будут обнаруживать передовые методы и несколько утомительны в использовании. Если вы можете себе это позволить, используйте автоматический сканер. Однако, если вы не можете справиться с этим ценником, ручное тестирование – отличный первый шаг.
Самый простой способ оценить, уязвимо ли приложение, – это поэкспериментировать с безобидными инъекционными атаками, которые фактически не повредят вашей базе данных, если они добьются успеха, но предоставят вам доказательства того, что вам нужно исправить проблему. Например, предположим, что у вас есть простое веб-приложение, которое ищет человека в базе данных и в результате предоставляет контактную информацию. Эта страница может использовать следующий формат URL:
Мы можем предположить, что эта страница выполняет поиск в базе данных, используя запрос, подобный следующему:
Давайте немного поэкспериментируем с этим. Исходя из нашего предположения выше, мы можем сделать простое изменение URL-адреса, который проверяет атаки с использованием SQL-инъекций:
Если веб-приложение не было должным образом защищено от внедрения SQL, оно просто вставляет это поддельное имя в оператор SQL, выполняемый для базы данных, что приводит к:
Вы заметите, что приведенный выше синтаксис немного отличается от синтаксиса исходного URL. Мы позволили себе преобразовать закодированную в переменную URL для их эквивалентов ASCII, чтобы было легче следовать примеру. Например,% 3d – это кодировка URL для символа ‘=’. Мы также добавили несколько разрывов строк для аналогичных целей.
Оценка результатов
Тест приходит, когда вы пытаетесь загрузить веб-страницу с помощью URL-адреса, указанного выше Если веб-приложение хорошо себя ведет, оно удалит одинарные кавычки из входных данных перед передачей запроса в базу данных. Это просто приведет к странному поиску кого-то, чье имя включает в себя несколько SQL. Вы увидите сообщение об ошибке из приложения, подобное приведенному ниже:
С другой стороны, если приложение уязвимо для внедрения SQL-кода, оно передаст оператор непосредственно в базу данных, что приведет к одной из двух возможностей. Во-первых, если на вашем сервере включены подробные сообщения об ошибках (чего не следует делать), вы увидите нечто вроде этого:
С другой стороны, если ваш веб-сервер не отображает подробные сообщения об ошибках, вы получите более общую ошибку, такую как:
Если вы получите одну из двух ошибок, указанных выше, ваше приложение уязвимо для атаки SQL-инъекцией. Вот некоторые шаги, которые вы можете предпринять, чтобы защитить свои приложения от атак SQL-инъекций:
- Реализовать проверку параметров во всех приложениях. Например, если вы просите кого-то ввести номер клиента, убедитесь, что ввод числовой, прежде чем выполнять запрос.
- Ограничьте разрешения учетной записи, которая выполняет запросы SQL. Применяется правило наименьших привилегий. Если учетная запись, используемая для выполнения запроса, не имеет разрешения на его выполнение, она не будет выполнена успешно.
- Используйте хранимые процедуры (или аналогичные методы), чтобы предотвратить непосредственное взаимодействие пользователей с кодом SQL.
