базовый иммунитет

ЕКАТЕРИНА ДЕРБЕНЦЕВА

Спецвыпуск: Хакер, номер #066, стр. 066-014-4

использование уязвимостей приложений

Если сами БД, как правило, защищены довольно неплохо и их обслуживают грамотные администраторы, то дело с приложениями часто обстоит довольно грустно. Например, посмотрим, что происходит, если доступ к базе разграничен средствами приложения (встречается достаточно часто) и приложение обращается к базе со стандартным паролем. Хэш пароля перехватывается отладчиком, в результате удается попытка подключиться к базе с неограниченными правами. Впрочем, случается и такое, что пароль лежит в реестре, в конфигурационных файлах — обнаружить его будет еще проще.

как защититься

НА ЭТАПЕ РАЗРАБОТКИ ПРОГРАММНОГО РЕШЕНИЯ НЕОБХОДИМО ЗАДУМАТЬСЯ О БЕЗОПАСНОСТИ ДАННЫХ, ХРАНИМЫХ В СУБД. ЕСЛИ ИЗМЕНИТЬ КОД ПРИЛОЖЕНИЯ ВСЕ-ТАКИ НЕВОЗМОЖНО, СТАРАЙСЯ ПОЧАЩЕ ИЗМЕНЯТЬ ПАРОЛЬ ТОЙ УЧЕТНОЙ ЗАПИСИ, ОТ ИМЕНИ КОТОРОЙ ФУНКЦИОНИРУЕТ ПРИЛОЖЕНИЕ. ИНИЦИИРУЙ РЕГИСТРАЦИЮ СОБЫТИЙ ПОПЫТКИ ДОСТУПА В БД ОТ ИМЕНИ ЭТОЙ УЧЕТНОЙ ЗАПИСИ.

использование ошибок синтаксиса

Ошибки синтаксиса часто оставляют без особого внимания. Незавершенный запрос, хранение паролей в коде, иногда даже в открытом виде (!) — те уязвимости, которыми злоумышленник воспользуется в первую очередь, если возьмется за добывание доступа к данным.

Вот, к примеру, посмотрим, как выглядит обычный запрос к базе данных. Он начинается с begin и заканчивается commit. Если в базе разрешен пользовательский ввод и он не проверяется или проверяется недостаточно качественно, в результате посыла запроса, в начале которого стоит обычное begin, но в конце нет commit, база перестает отвечать на другие запросы, обращенные к ней.

SQL-инъекции

SQL-инъекции часто используются для того, чтобы выудить лакомые для кого-то данные из базы в обход межсетевого экрана либо для проникновения во внутреннюю сеть.

[защита от SQL-инъекций] сейчас встраивается в web-приложения в обязательном порядке. Однако благодаря тому, что вариантов этой атаки великое множество, а приложения могут быть достаточно сложными, одна пропущенная инъекция имеет шансы скомпрометировать всю сеть. Действительно, обеспечить надежную защиту от этого вида атак — нерешенная проблема. Некоторые администраторы БД считают, что никакая SQL-инъекция не угрожает им, потому что они используют хранимые процедуры и маскируют сообщение об ошибке, которое выдает браузер. Да, действительно помогает, но, к сожалению, далеко не всегда.

[SQL-инъекции на примере MS SQL] Пытаясь применить SQL-инъекцию против нужного сервера БД, в первую очередь атакующий должен проверить, подвержен ли сервер БД выбранному виду атаки. Для этих целей может использоваться одна из встроенных функций SQL-сервера: OPENROWSET или OPENDATASOURCE (используются для подключения к OLEDB-провайдеру; в примерах используется функция OPENROWSET, но с тем же успехом в дело пойдет и OPENDATASOURCE).