Тестирование на уязвимости SQL-инъекций

Атаки 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.
Оцените статью
Solutics.ru
Добавить комментарий