Защита от хакеров корпоративных сетей

Включенные в состав запроса символы указания директории самой на себя /./ позволяют изменить сигнатуру уязвимости. Или пусть, для примера, атакуемый Web-сервер – информационный сервер Интернет (IIS) Windows NT (хотя phf – это программа интерфейса CGI системы UNIX). Тогда запрос можно оформить следующим образом:

GET /cgi-bin\phf HTTP/1.0

Приведенная строка маскирует сигнатуру искомой строки.

Недавно получил распространение способ маскировки данных, поставивший всех в тупик. Он основан на кодировании URL при помощи меняющих друг друга кодировок UTF-8 и Unicode, которые понимают сервера Microsoft IIS и некоторые другие. (UTF-8 – ASCII-совместимый многобайтовый код, применяемый в языке Java. Unicode – 16-битный стандарт кодирования символов, позволяющий представлять алфавиты всех существующих в мире языков). Для представления символов ASCII можно использовать 16-битное кодирование Unicode. Обычно приложения воспринимают эти 16-битные величины как неверные, хотя некоторые могут их обрабатывать.

Хорошим примером, иллюстрирующим возможности перехода к представлению данных на Unicode-коде, является уязвимость, исправленная патчем Microsoft MS00-078. Ранее можно было обмануть информационный сервер Интернет IIS и получить доступ к файлам, размещенным за пределами Web-директории, при помощи обращения к родительской директории. Пример подобного трюка с URL выглядит так

/cgi-bin/../../../../winnt/system32/cmd.exe

В идеальном для злоумышленника случае это позволило бы ему получить доступ к корневой директории, а затем к системной директории WINNT и ее поддиректориям, вызвав программу операционной системы cmd.exe. Позволило бы, если бы информационный сервер Интернет не был достаточно умен, чтобы противостоять злоумышленнику и не позволить ему преодолеть систему безопасности. Меняя некоторые символы на их эквиваленты в Unicode-коде, злоумышленник может обмануть информационный сервер Интернет IIS, заставив его поверить в безопасность URL. После декодирования URL информационный сервер Интернет выполнит программу cmd.exe. Результат замены символов в URL может выглядеть так:

/cgi-bin/..%c0%af..%c0%af..%c0%af..%c0%afwinnt/system32/cmd.exe

В этом примере символ «/» заменен на 16-битный эквивалент в Unicode-коде с представлением в шестнадцатеричном формате «0xC0AF», который затем был перекодирован в URL как «%c0%af». Вместо символа «/» можно было закодировать в Unicode-коде любой другой символ. Символ «/» был использован только в качестве примера.

Методы поиска и устранения уязвимостей, обусловленных непредвиденными входными данными

Будем надеяться, что читатель понял, какую проблему для безопасности представляют не предусмотренные разработчиком приложения данные, введенные пользователем. Следующее, что нужно узнать, – это уязвимо ли ваше приложение. Но как это сделать? Этот раздел посвящен наиболее общим методам, которые используются для определения уязвимости приложения и устранения их.

Тестирование методом «черного ящика»

В Web-приложениях проще всего найти уязвимости, вызванные вводом непредвиденных данных. Объясняется это их многочисленностью и широким распространением. Прежде всего следует исследовать HTML-формы и URL с параметрами (параметры – это значения после знака «?» в URL).

Для тестирования рекомендуется найти Web-приложение, которое поддерживает динамические страницы с большим количеством параметров в URL. Для начала можно использовать придирчивую методику поиска, основанную на замене некоторых значений параметров. Это не так уж и сложно. Для повышения эффективности поиска потенциальных уязвимостей следует придерживаться следующих правил.

Интуитивное понимание принципов работы приложения. Предусмотрена ли в приложении работа с электронными заказами? Если да, то, скорее всего, приложение взаимодействует с какой-нибудь базой данных. Предусмотрена ли возможность обратной связи с приложением после предъявления пользователю HTML-формы? Если да, то, скорее всего, после заполнения HTML-формы будет вызвана внешняя программа или процедура для отсылки электронной почты.