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

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



Резюме

Насыщенное веб-приложение (англ. rich internet application, RIA) — это веб-приложение, загружаемое пользователем через интернет, предназначенное для выполнения функций традиционных настольных приложений и работающее на устройстве пользователя (не на сервере). Технологии, используемые для реализации RIA: язык разметки HTML5 и язык программирования JavaScript; (Google) Native Client; Adobe Flash; (Oracle) JavaFX; Microsoft Silverlight.

Насыщенные веб-приложения используют файлы crossdomain.xml для контроля кросс-доменного доступа к данным и использования сервисов различными технологиями, например, Oracle Java, Silverlight, и Adobe Flash. Если файлы, регулирующие кросс-доменный доступ (далее — файлы кросс-доменных политик), неправильно сконфигурированы, то появляется возможность проведения атаки Cross-site Request Forgery и доступа к различной чувствительной информации.

Какие файлы регулируют кросс-доменную политику?

Файлы кросс-доменных политик предоставляют веб-клиентам (Java, Adobe Flash, Adobe Reader и т. д.) доступ к данным на различных доменах. Для Silverlight также используется crossdomain.xml, но кроме того компания Microsoft дополнительно создала файл: clientaccesspolicy.xml.

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

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

Crossdomain.xml или Clientaccesspolicy.xml

Большинство обогащенных веб-приложений поддерживают crossdomain.xml. Однако, в случае Silverlight, он будет работать только в том случае, если в crossdomain.xml разрешен доступ с любого домена. Для более тонкой настройки Silverlight необходимо использовать clientaccesspolicy.xml.

Файлы кросс-доменных политик предоставляют несколько типов разрешений:

  1. разрешенные файлы кросс-доменных политик (главный файл кросс-доменной политики может разрешить или запретить прочие)
  2. разрешения сокетов
  3. разрешения заголовков
  4. разрешения доступа HTTP/HTTPS
  5. разрешения доступа по зашифрованным учетным данным

Ниже приведен пример чрезмерно разрешающего файла кросс-доменных политик:



<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
<allow-access-from domain="*" secure="false"/>
<allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>

Какие могут быть недостатки у файлов кросс-доменных политик?

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

Последствия от злоупотребления кросс-доменным доступом

  • недееспособность защиты от CSRF
  • чтение данных, ограниченных правилами домена

Как тестировать
Поиск слабостей в файлах кросс-доменных политик

Для тестирования кросс-доменных политик тестировщик должен получить crossdomain.xml и clientaccesspolicy.xml из корня веб-приложения, и каждой обнаруженной директории.

Например, если тестируется веб-приложение http://www.owasp.org, то тестировщик должен попытпться загрузить http://www.owasp.org/crossdomain.xml и http://www.owasp.org/clientaccesspolicy.xml.

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

Пример:

<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>

Ожидаемые результаты

  • перечень обнаруженных файлов кросс-доменных политик
  • список неправильных настроек

Инструменты

  • Nikto
  • OWASP Zed Attack Proxy
  • W3af

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