Атаки SQL Injection представляют собой огромные риски для веб-приложений, которые зависят от бэкэнда базы данных для создания динамического контента. В этом типе атаки хакеры манипулируют веб-приложением, пытаясь вставлять свои собственные SQL-команды в те, которые выдаются базой данных. Например, см. Статью SQL Injection Attacks on Batabases. В этой статье мы рассмотрим несколько способов тестирования ваших веб-приложений, чтобы определить, уязвимы ли они для атак SQL Injection.
Автоматизированное сканирование приложений SQL
Одной из возможностей является использование сканера уязвимости автоматизированного веб-приложения, такого как WebInspect HP, приложение AppScan от IBM или Cendic's Hailstorm. Эти инструменты предлагают простые, автоматизированные способы анализа ваших веб-приложений для потенциальных уязвимостей SQL Injection. Тем не менее, они довольно дороги, они работают на 25 000 долларов США за место.
Ручные SQL-инъекции
Что плохой разработчик приложений? Фактически вы можете запустить некоторые базовые тесты для оценки ваших веб-приложений для уязвимостей SQL Injection, используя не что иное, как веб-браузер. Во-первых, предостережение: тесты, которые мы описываем, рассматривают только основные недостатки SQL Injection. Они не будут обнаруживать передовые методы и несколько утомительны в использовании. Если вы можете себе это позволить, пойдите с автоматическим сканером. Однако, если вы не можете справиться с этим ценовым тегом, ручное тестирование - отличный первый шаг.Самый простой способ оценить, является ли приложение уязвимым, - это экспериментировать с безобидными инъекционными атаками, которые на самом деле не повредят вашей базе данных, если они преуспеют, но предоставят вам доказательства того, что вам нужно исправить проблему. Например, предположим, что у вас есть простое веб-приложение, которое ищет человека в базе данных и дает контактную информацию в результате. Эта страница может использовать следующий формат URL: http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike
Мы можем предположить, что эта страница выполняет поиск базы данных, используя запрос, подобный следующему: SELECT телефон
FROM directory
WHERE lastname = 'chapple' и firstname = 'mike'
Давайте немного поэкспериментируем с этим. В нашем предположении выше мы можем внести простое изменение в URL-адрес, который тестирует атаки SQL-инъекций: http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike'+AND+(select+count(*)+from+fake)+%3e0+OR+'1'%3d'1
Если веб-приложение не было должным образом защищено от SQL-инъекции, оно просто подключает это поддельное имя в оператор SQL, который он выполняет против базы данных, в результате чего: SELECT телефон
FROM directory
WHERE lastname = 'chapple' и firstname = 'mike'
И (выберите count (*) из фальшивки)> 0
ИЛИ '1' = '1'
Вы заметите, что приведенный выше синтаксис немного отличается от приведенного выше в исходном URL. Мы взяли на себя смелость преобразовать переменную URL-кодировку для своих эквивалентов ASCII, чтобы упростить ее выполнение. Например,% 3d является URL-кодировкой для символа '='. Мы также добавили некоторые разрывы строк для аналогичных целей. Тест выполняется, когда вы пытаетесь загрузить веб-страницу с указанным выше URL-адресом. Если веб-приложение хорошо себя ведет, оно будет выделять одиночные кавычки из ввода перед передачей запроса в базу данных. Это просто приведет к странному поиску для кого-то с первым именем, которое включает в себя кучу SQL. Вы увидите сообщение об ошибке из приложения, аналогичного приведенному ниже: Ошибка: пользователь не найден с именем mike + AND + (выберите + счетчик (*) + из + подделка) +% 3e0 + OR + 1% 3d1
Chapple!
С другой стороны, если приложение уязвимо для SQL-инъекции, оно передаст оператор непосредственно в базу данных, что приведет к одной из двух возможностей. Во-первых, если ваш сервер имеет подробные сообщения об ошибках (что вам не нужно), вы увидите что-то вроде этого: Поставщик Microsoft OLE DB для ошибки драйверов ODBC «80040e37»
Microsoft ODBC SQL Server Driver SQL Server Недопустимое имя объекта «fake».
/directory.asp, строка 13
С другой стороны, если ваш веб-сервер не отображает подробные сообщения об ошибках, вы получите более общую ошибку, например: Внутренняя ошибка сервераСервер обнаружил внутреннюю ошибку или неправильную конфигурацию и не смог выполнить ваш запрос.
Обратитесь к администратору сервера, чтобы сообщить о времени возникновения ошибки и о чем-либо, что вы могли бы сделать, что могло привести к ошибке.
Дополнительная информация об этой ошибке может быть доступна в журнале ошибок сервера.
Если вы получаете одну из двух вышеперечисленных ошибок, ваше приложение уязвимо для атаки SQL-инъекций. Некоторые шаги, которые вы можете предпринять для защиты ваших приложений от атак SQL Injection, включают в себя: Оценка результатов
