Хорошим примером, иллюстрирующим возможности перехода к представлению данных на 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-формы будет вызвана внешняя программа или процедура для отсылки электронной почты.
Контроль хода выполнения интерактивной обработки в приложении от начала до конца хотя бы один раз.Следует сохранить и проанализировать каждую HTML-форму, переданную пользователю. Посмотрите, нет ли на форме скрытых полей. Скрытые поля ввода могут содержать ранее введенные данные. Дефект приложения может состоять в том, что сначала оно получает данные пользователя и обрабатывает их, а затем возвращает обратно пользователю в скрытом виде. После повторного получения данных приложение может полагать, что назад обработанные данные вернулись без изменений, хотя пользователь мог аннулировать обработку данных, изменив их.
Умышленная попытка создания аварийной ситуации.Попытайтесь оставить некоторые поля ввода пустыми или ввести в них столько «плохих» символов, сколько возможно (поместите буквы туда, где должны быть цифры и т. п.). Цель подобных манипуляций – выяснить реакцию приложения на ошибку. Если приложение обнаружит ошибку, то реакция приложения поможет установить алгоритм проверки входных данных. Если приложение выдает диагностические сообщения об ошибке в данных или выводит уже исправленные значения, то следует поэкспериментировать с символами ASCII, чтобы определить, какие данные приложением отбраковываются, а какие – нет. Данные, отбракованные приложением, могут подсказать алгоритм обработки данных. Например, если приложение отсеивает одинарные или двойные кавычки, то данные, вероятнее всего, используются в запросах SQL. Если приложение избавляется от всех метасимволов командного процессора UNIX, то возможно, что они передаются в другую программу.
Читать дальше
Конец ознакомительного отрывка
Купить книгу