Внедрение SQL кода (SQL Injection) — до 20 мин

Распространенные ошибки при защите сервера БД — до 10 мин.

Текст лекции

Ключевые вопросы

Лекция № 13. Организация системы безопасности

Продолжительность: 2 часа (90 мин.)

· Распространенные ошибки при защите сервера БД

· Внедрение SQL кода.

· Защита SQL Server в Интернет.

· Пример организации системы безопасности приложений.

Ошибки можно разделить на три категории:

· Ошибки администрирования

· Ошибки программирования

· Ошибки реализации SQL Server

Примером ошибок первой категории являются: открытый в Интернет порт 1434, пустой пароль учетной записи sa. Для борьбы с подобного рода ошибками следует установить четкую политику безопасности в организации, согласно которой будет происходить администрирование ИС, включая администрирование СУБД. Необходимо отметить, что одним лишь корректным администрированием сервера баз данных невозможно обеспечить целостность и безопасность информации. Проблему следует рассматривать комплексно.

Примером ошибок второй категории может служить конструирование SQL запросов в приложении "на лету" на основе непроверенного пользовательского ввода и отправка таких запросов серверу СУБД. Для борьбы с такими ошибками можно использовать четкие стандарты кодирования и периодические обзоры программных решений.

Ошибки третьей категории: множественные переполнения буфера в системных расширенных процедурах и командах DBCC, излишне "большие" разрешения на выполнение ряда системных процедур для рядовых пользователей СУБД и т.п. Единственным способом преодоления подобных проблем является регулярный мониторинг соответствующих ресурсов на предмет выхода очередных заплат, сервис паков и их немедленная установка их на сервера.

Проблема многих приложений состоит в динамической генерации SQL запросов и отправке их в СУБД без предварительной обработки. Например, следующий фрагмент кода не является редкостью:

... Set rs = cn.Execute("SELECT password FROM dbo.Users WHERE email = '" &_ Request.Form("email") & "'")... objMail.To = Request.Form("email") objMail.Send(rs("password"))...

Нетрудно видеть, что через поле формы email можно изменить логику запроса. Например, с большой долей вероятности можно получить пароль произвольного пользователя, если в качестве значения поля email будет получено:

[email protected]' OR email=';[email protected]

Запрос будет выглядеть так:

SELECT password FROM dbo.Users WHERE email = '[email protected]' OR email=';[email protected]'

что приведет к тому, что будет выбран пароль Пользователя с адресом [email protected], но отправлен он будет, скорее всего, по адресу [email protected], т.к. многие почтовые компоненты считают символ; разделителем адресов. Этот сценарий будет работать в случае, если запросы строятся динамически и без проверки пользовательского ввода. Если же приложение работает под учетной записью, обладающей большими привилегиями в SQL Server, то последствия могут быть еще печальнее, вплоть до получения контроля над машиной, где работает SQL Server:

'; EXEC master.dbo.xp_cmdshell 'net user john pass /add && net localgroup Administrators john /add

Пользуясь подобными ошибками, злоумышленник может раскрыть схему таблиц, механизм подробно описан в документе "Web Application Disassembly with ODBC Error Messages", автор David Litchfield. Кроме того, в ряде случаев такие ошибки сводят на нет все усилия по защите сети через брандмауэр, т.к. атака может идти поверх HTTP, а для обмена данными, проникновения во внутреннюю сеть может использоваться SQL Server злоумышленника, выступающий в качестве присоединенного сервера. Об этом можно прочесть в документе "Manipulating Microsoft SQL Server Using SQL Injection", автор Cesar Cerrudo. Например, может быть использован такой запрос для получения списка баз на другом SQL сервере:

SELECT * FROM OPENROWSET('SQLOLEDB', 'Server=INTERNAL_SQL_SERVER;UID=sa;PWD=password;', 'select * from sysdatabases')

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

Для того, чтобы избежать ошибок подобного рода можно применить следующие методы:

· Не запускать приложения под привилегированными "учетными записями" (sysadmin, db_owner и т.п.) SQL Server. Не запускать SQL Server под привилегированными учетными записями операционной системы (LocalSystem, Administrators group member и т.п.).

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

CREATE PROCEDURE dbo.GetUsers @Field varchar(100) AS

SET NOCOUNT ON

EXEC ('SELECT UserID, Username, FirstName, LastName FROM dbo.Users ORDER BY ' + @Field) RETURN

Вызов ("опасный"):

EXECUTE dbo.GetUsers '1;

EXEC master.dbo.xp_cmdshell [net user john /add && net localgroup Administrators john /add]'

· Использовать параметризованные запросы

· Использовать регулярные выражения для проверки пользовательского ввода до того, как он будет отправлен в СУБД. В случае несоответствия ввода и шаблона выдавать сообщение об ошибке клиенту, оставлять запись об ошибке (ни в коем случае не показывать клиенту ошибки SQL Server'а!) в журнале приложения и прекращать выполнение запроса.

· Использовать функции для экранирования служебных символов. Например:

strEmail = Replace(Request.Form("Email"), "'", "''")

· Проводить обзор кода (code review) и следовать стандартам кодирования В качестве автоматических тестирующих средств можно порекомендовать SPI Dynamic WebInspect 2.6. Данное средство тестирования приложений пытается отыскать и ошибки класса "SQL Injection".

Дата добавления: 2014-01-11