Технологии взлома языковых средств SQL
Внедрение SQL-кода в при определенных обстоятельствах можно осуществить в другие СУБД. Что касается Microsoft SQL Server, то единственное его отличие от других продуктов — большое количество встроенных дополнительных функций, что делает эту технологию более уязвимой. Но существует и достаточное количество механизмов взлома, которые используют уязвимости любых баз данных, основанных на SQL. Эти механизмы основаны на манипуляциях с операторами SQL и сводятся к добавлению в конец и вставке выражений SQL, а также к изменению ключевых слов языка SQL в выражениях.
Операторы SQL
Сразу скажу, что никаких сверхсенсационных вещей не будет, лишь то, как хакер может использовать стандартные операторы в своих целях. И так.
Язык SQL состоит из списка предопределенных ключевых слов и специальных символов. Для того чтобы извлечь какие-либо данные из таблицы, необходимо воспользоваться оператором SELECT. При работе с Web-приложениями, как правило, используется именно оператор SELECT с ключевыми словами FROM и WHERE. Внедряя инструкции SQL в такие запросы, хакер может заставить запрос выдать другую информацию или, например, сделать так, чтобы при проверке на какое-либо условие приложению возвращался положительный ответ.
Формат SQL-выражений строго не определен, и одно и то же выражение может быть записано несколькими способами, что очень усложняет восприятие инструкций языка. Эти особенности языка могут помочь хакеру получить доступ к базе данных. Естественно, что для получения более серьезных результатов необходимо использовать более сложные структуры запросов, но, тем не менее, все эти взломы основаны на этих же основополагающих принципах.
OR 1=1
Очевидно, что это выражение создает логическое выражение, результатом вычисления которого всегда будет “Истина”. Данное выражение используется в запросах аутентификации, которые проверяют имя пользователя и пароль:
sqlAuth = “SELECT userid FROM logins WHERE name = ‘ “ & Username & ” ’ AND password = ‘ “ & Password & ” ’ ” |
Если пользователь входит в систему под именем Wayne с паролем Pirate, то запрос будет выглядеть следующим образом:
SELECT userid FROM logins WHERE name= ‘Wayne’ AND password= ‘Pirate’ |
Таким образом, пользователь Wayne не сможет войти в систему до тех пор, пока значение Pirate не попадет в базу данных. Однако, применяя выражение OR 1=1, можно избавиться от проверки пароля:
SELECT userid FROM logins WHERE name= ‘Wayne’ AND password= ‘Pirate’ OR 1=1 |
UNION
Оператор UNION используется совместно с оператором SELECT и служит для извлечения всех столбцов из таблицы. Синтаксис использования команды следующий:
UNION ALL SELECT field FROM table WHERE condition |
Кроме того, этот оператор может использоваться для извлечения имен полей и таблиц из названий переменных в приложении, файлах .inc или сообщений об ошибках SQL. Условие 1=1 или “ ”=“ ” (ничего равняется ничему) всегда истинно.
INSERT
Как несложно догадаться, инструкция INSERT предназначена для добавления каких-либо значений в таблицу базы данных. На первый взгляд данная команда выглядит не слишком полезной с точки зрения взлома; в конце концов, мы же хотим узнать содержимое базы данных, а не наполнять ее информацией. Однако не стоит поддаваться первым впечатлениям — эта команда может быть прекрасно использована для прохождения аутентификации незарегистрированного пользователя. Вот как, например, с помощью внедрения SQL, можно добавить в таблицу пользователей Users нового пользователя с именем Neo и паролем Trinity:
INSERT INTO Users VALUES (‘Neo’, ‘Trinity’) |
Аутентификационные данные для получения доступа к базе данных.
Чтобы присоединиться к базе данных, Web-сервер должен знать пользовательское имя и пароль. Данное соединение производится сервером в автоматическом режиме. Следовательно, приложения хранят регистрационные данные для аутентификации в теле какой-либо страницы. Но, к сожалению, большинство приложений помещают эти данные в какой-нибудь файл, расположенный в корневом каталоге Web-сервера, — место, к которому обычно имеют доступ Web-браузеры пользователей.
Некоторые разработчики приложений надеются, что сервер защитит их важные файлы, как это делает сервер IIS, запрещающий запросы к файлу global.asa. Однако, если приложение подвержено опасности раскрытия исходного кода (что в случае с Web-приложениями встречается довольно часто), то имя пользователя и пароль Web-сервера могут быть похищены. Кроме того, разработчики иногда помещают эти регистрационные данные в файлы, которые, как они считают, пользователь не будет просматривать или при просмотре просто не найдет этих данных. Файлы могут иметь такие имена, как xmlserver.js, database.inc или server.js.
Однако эти строки легко обнаружить, если в них используется ключевое слово password:
strConn = “Provider=SQLOLEDB; Data Source=dotcomdb; Initial Catalog=Demo; User Id=sa; Password=” |
Файл СУБД Oracle global.asa также может содержать регистрационные данные.
Твитнуть