Представляю вашему вниманию очередную часть перевода OWASP Testing Guide. В данной статье речь пойдет о тестировании конфигурации платформы веб-приложения.

Предыдущие статьи

  1. Тестирование: введение и задачи
  2. Сбор информации с помощью поисковых систем
  3. Определение веб-сервера
  4. Поиск информации в метафайлах веб-сервера
  5. Определение веб-приложений на сервере
  6. Поиск утечек информации в комментариях и метаданных
  7. Определение точек входа веб-приложения
  8. Составление карты веб-приложения
  9. Определение фреймворка веб-приложения
  10. Определение веб-приложения
  11. Составление карты архитектуры веб-приложения
  12. Тестирование конфигурации инфраструктуры веб-приложения

Резюме

Правильная конфигурация отдельных компонентов, составляющих архитектуру приложения помогает избежать ошибок, позволяющих скомпрометировать веб-приложение.

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

Как тестировать

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

Примеры и известные файлы и директории

Многие веб-серверы и серверы приложений при установке с параметрами по умолчанию также устанавливают тестовые примеры приложений и файлы, помогающие разработчику проверить функционирование сервера после установки. Многие из таких примеров, устанавливаемых по умолчанию, уязвимы. Например, CVE-1999-0449 (DoS в IIS при установке тестового примера Exair), CAN-2002-1744 (Directory traversal в файле CodeBrws.asp в Microsoft IIS 5.0), CAN-2002-1630 (использование sendmail.jsp в Oracle 9iAS) или CAN-2003-1172 (Directory traversal в View-source примере в Apache’s Cocoon)

CGI сканнеры обычно включают в себя подробный список таких тестовых уязвимых файлов и директорий, поставляемых различным веб-серверами или серверами приложений, использование таких сканнеров, пожалуй, наиболее быстрый способ выявить наличие уязвимых тестовых файлов.

Проверка комментариев

Комментирование исходного кода — часто встречающаяся и даже рекомендуемая практика серди разработчиков. Однако, комментарии добавленные в HTML код, могут раскрывать некоторые аспекты внутренней логики работы приложения, нежелательно, чтобы такая информация была доступна атакующему.
Проверка комментариев необходима чтобы убедиться в отсутствии утечки важной информации о работе веб-приложения, потенциально полезной атакующему. Для осуществления такой проверки необходимо проанализировать статический и динамический контент веб-приложения, для этого необходимо пройтись по контенту веб-приложения, можно в автоматическом режиме (spidering), сохраняя весь полученные данные, а затем осуществить поиск по содержимому файлов на наличие комментариев.

Тестирование по методу серого ящика

Проверка конфигурации

Веб-сервер или сервер приложений — важнейшее звено в обеспечении безопасности веб-приложения, эти компоненты должны быть тщательно проверены на предмет наличия типичных ошибок конфигурации. Рекомендации по конфигурации могут варьироваться, в зависимости от назначения и функциональности веб-приложения, однако, в большинстве случаев стоит придерживаться рекомендаций по конфигурации от поставщиков.

В общем случае невозможно дать точных инструкций по конфигурации веб-сервера или сервера приложений, однако существуют общие рекомендации, которые стоит принять во внимание:

  • необходимо включать только те модули (расширения ISAPI в случае с IIS), которые необходимы для работы приложения. Это скоратит возможную поверхность атаки, так как уменьшиться размер и сложность сервера.
  • обрабатывать ошибки сервера (40x или 50х) с помощью собственных страниц, вместо используемых по умолчанию. Убедитесь, что ошибки приложения при их возникновении не попадают к конечному пользователю и не раскрывают никаких данных о внутренней структуре приложения. Этот пункт особенно важно проверять, так как подобная информация необходима разработчикам на стадии подготовки платформы и часто остается после релиза приложения;
  • Убедитесь в том, что серверное программное обеспечение запущено в операционной системе с минимально необходимыми правами доступа, дабы исключить возможность компрометации операционной системы, в случае если атакующий получит возможность исполнять код с правами сервера;
  • Убедитесь в том, что сервер логгирует как легитимный доступ к ресурсам приложения, так и ошибки.
  • Убедитесь в том, что сервер корректно справляется с перегрузками для предотвращения DoS атак.
  • Никогда не разрешайте учетным записям, не входящим в группу Администраторов (за исключением NT SERVICES\WMSvc) доступ к следующим файлам: applicationHost.config, redirection.config adminitration.config (как на чтение, так и на запись). Это относится к учетным записям Network Services, IIS_IUSRS, IUSR или к другим кастомным учетным записям, используемым IIS.
  • Никогда не предоставляйте сетевой доступ к файлам applicationHost.config, redirection.config administration.config. При использовании Shared Configuration, предпочтительней экспортировать applicationHost.config в другое место (подробнее см. в [ номер ссылки на конфигурацию IIS])
  • Имейте ввиду, что все пользователи могут читать .NET Framework файлы machine.config и root web.config, не рекомендуется хранить важную информацию в этих файлах.
  • шифруйте важную информацию, необходимую для работы IIS сервера, которая не нужна другим пользователям и процессам.
  • Не предоставляйте права на запись для учетных записей, которые использует веб-сервер для доступа к applicationHost.config файлу, такие учетные записи должны иметь права только на чтение этого файла.
  • Используйте разные учетные записи для публикации и конфигурирования applicationHost.config
  • используйте стойкие пароли при экспортировании ключей шифрования для использования с shared configuration
  • используйте строгие политки безопасности для досутпа к общему хранилищу конфигурации и ключей шифрования.
  • рассмотрите возможность защиты общего хранилища файрволом и политиками доступа IPSec, разрешая доступ к хранилищу только для веб-серверов, которым это необходимо.

Логирование

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

Для тестирования системы логирования, необходимо проанализировать следующую информацию:

  1. Содержат ли логи важную информацию?
  2. Где хранятся логи? вынесены ли они на отдельный выделенный сервер?
  3. Может ли логгирование вызвать отказ в обсуживании?
  4. Как организована ротация логов? В течение какого времени хранятся логи?
  5. Как организован просмотр логов? Могут ли администраторы при просмотре логов заметить целенаправленную атаку?
  6. Как огранизовано резервное копирование логов?
  7. Проходят ли валидацию данные, перед логированием? (минимальная/максимальная длинна, допустимые символы и т.д.)

Конфиденциальная информация в логах

Некоторые веб-приложения могут использовать GET-запросы для передачи данных форм, и такие данные могут попадать в логи сервера, а значит в логах может содержаться конфиденциальная пользовательская информация (имена пользователей, пароли, информация о банковском счете). Эта информация может попасть к атакующему, например через интерфейс администрирования, использование известных уязвимостей серверного программного обеспечения или изза ошибок конфигурации.

Логи событий обычно содержат полезную для атакующего информацию:

  • отладочная информация
  • стек-трейсы
  • имена пользователей
  • имена компонентов системы
  • внутренние IP адреса
  • менее важные персональные данные(емайл адреса, почтовые адреса, телефонные номера)
  • бизнес-данные

Расширенный список конфиденциальной информации информации:

  • исходные коды приложения;
  • идентификаторы сессий;
  • различные токены;
  • персональные данные;
  • пароли;
  • идентификаторы для подключения к базам данных;
  • ключи шифрования;
  • банковские данные и платежная информация;
  • данные, с более высоким уровнем секретности, чем может хранить система логгирования;
  • коммерческая конфиденциальная информация;
  • данные, сбор и хранение которых запрещено законом;
  • данные, на сбор которых пользователь не давал своего согласия или явно указал, что эти данные не должны храниться и использоваться (Do not track).

Расположение логов

Обычно, различные действия, совершаемые серверным ПО, а также их ошибки хранятся локально, используя свободное место сервера на котором и запущено ПО.
Однако, если сервер будет скомпрометирован, логи могут быть удалены злоумышленником для сокрытия своих действий и администраторы системы не смогут получить никакой информации о подробностях атаки.
Поэтому, более мудрым решением будет хранить логи в отдельном, специально отведенном месте, не на сервере веб-приложения. Такое решение также может помочь с агрегацией логов из разных источников, связанных с веб-приложением (веб-серверы, сервер аутентификации, сервер баз данных), также, при таком построении системы, анализ логов не будет влиять на вычислительные мощности веб-серверов.

Хранение логов

Система логирования, при неверном подходе к организации хранения, может вызвать отказ в обслуживании. Атакующий, обладающий достаточными ресурсами, может сгенерировать большое количество запросов чтобы заполнить все свободное место, отведенное для хранения логов. При неправильной конфигурации системы хранения логов, например, когда логи хранятся на разделе операционной системы или веб-приложения, это может вызвать сбои в работе операционной системы сервера или самого веб-приложения.
Обычно, в Unix-системах логи хранятся в директории /var (или /opt, /usr/local), в этом случае необходимо убедиться, что эти директории хранятся на отдельных разделах операционной системы.
Также стоит следить за размером лог-файлов, резкий рост размера лог-файла может быть индикатором проводимой на веб-приложение атаки.
Тестирование вышеописанных возможных проблем, связанных с хранением логов с одной стороны довольно легко осуществимо, с другой стороны — весьма опасно для запущенных в эксплуатацию системах, так как может привести к отказу в обслуживании. В некоторых системах параметры QUERY_STRING логгируются независимо от метода запроса (GET или POST), таким образом для тестирования можно легко симулировать большой объем данных для логирования.

Ротация логов

Большинство серверных систем осуществляют ротацию логов, для предотвращения заполнения файловой системы, исходя из того, что информация, хранящаяся в логах, необходима и актуальная в течение определенного времени.

Ротацию логов также необходимо протестировать и проверить следующие моменты:

  • логи хранятся установленное в политиках безопасности время, не больше и не меньше;
  • логи архивируются и к ним применяют алгоритмы сжатия, для уменьшения занимаемого дискового пространства;
  • параметры доступа к архивным лог файлам и к текущим лог файлам такие же или более строгие. Например, веб-серверу необходимы права для записи в лог, но при этом ему не обязательно иметь права на изменение архивных лог файлов.

Контроль доступа к лог-файлам

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

Проверка логов

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

При таком анализе следует особое внимание уделить следующему:

  • ошибки 40х. Наличие большого количества таких сообщений об ошибки может служить индикатором использования CGI сканнеров, используемых для сканирования веб-сервера;
  • ошибки 50х. Подобные ошибки могут быть результатом того, что атакующий пытается использовать ошибки приложения. Например, первые фазы при попытке проведения SQL injection атак могут вызывать сбои в приложении, так как sql запрос сконструирован неверно.

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

Справочные материалы:

  1. Apache
  2. Lotus Domino
    • Lotus Security Handbook, William Tworek et al., April 2004, available in the IBM Redbooks collection
    • Lotus Domino Security, an X-force white-paper, Internet Security Systems, December 2002
    • Hackproofing Lotus Domino Web Server, David Litchfield, October 2001,
    • NGSSoftware Insight Security Research, available at http://www.nextgenss.com
  3. Microsoft IIS
    • IIS 6.0 Security, by Rohyt Belani, Michael Muckin, — http://www.securityfocus.com/print/infocus/1765
    • IIS 7.0 Securing Configuration — http://technet.microsoft.com/en-us/library/dd163536.aspx
    • Securing Your Web Server (Patterns and Practices), Microsoft Corporation, January 2004
    • IIS Security and Programming Countermeasures, by Jason Coombs
      From Blueprint to Fortress: A Guide to Securing IIS 5.0, by John Davis, Microsoft Corporation, June 2001
    • Secure Internet Information Services 5 Checklist, by Michael Howard, Microsoft Corporation, June 2000
    • “INFO: Using URLScan on IIS” — http://support.microsoft.com/default.aspx?scid=307608
  4. Red Hat’s (formerly Netscape’s) iPlanet
    • Guide to the Secure Configuration and Administration of iPlanet Web Server, Enterprise Edition 4.1, by James M Hayes, The Network Applications Team of the Systems and Network Attack Center (SNAC), NSA, January 2001
  5. WebSphere
    • IBM WebSphere V5.0 Security, WebSphere Handbook Series, by Peter Kovari et al., IBM, December 2002.
    • IBM WebSphere V4.0 Advanced Edition Security, by Peter Kovari et al., IBM, March 2002.
  6. General
  7. Generic: