Представляю вашему вниманию очередную часть перевода OWASP Testing Guide. В данной статье речь пойдет о тестирование политики кросс-доменных запросов в насыщенных веб-приложениях.
- Тестирование: введение и задачи
- Сбор информации с помощью поисковых систем
- Определение веб-сервера
- Поиск информации в метафайлах веб-сервера
- Определение веб-приложений на сервере
- Поиск утечек информации в комментариях и метаданных
- Определение точек входа веб-приложения
- Составление карты веб-приложения
- Определение фреймворка веб-приложения
- Определение веб-приложения
- Составление карты архитектуры веб-приложения
- Тестирование конфигурации инфраструктуры веб-приложения
- Изучение расширений файлов
- Поиск страрых версий веб-приложения, скрытых файлов и резервных копий
- Поиск административных интерфейсов
- Тестирование HTTP методов
- Тестирование 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.
Файлы кросс-доменных политик предоставляют несколько типов разрешений:
- разрешенные файлы кросс-доменных политик (главный файл кросс-доменной политики может разрешить или запретить прочие)
- разрешения сокетов
- разрешения заголовков
- разрешения доступа HTTP/HTTPS
- разрешения доступа по зашифрованным учетным данным
Ниже приведен пример чрезмерно разрешающего файла кросс-доменных политик:
<!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
Справочные материалы
-
UCSD: «Analyzing the Crossdomain Policies of Flash Applications» — http://cseweb.ucsd.edu/~hovav/dist/crossdomain.pdf
-
Adobe: «Cross-domain policy file specification» — http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
-
Adobe: «Cross-domain policy file usage recommendations for Flash Player» — http://www.adobe.com/devnet/flashplayer/articles/cross_domain_policy.html
-
Oracle: «Cross-Domain XML Support» — http://www.oracle.com/technetwork/java/javase/plugin2-142482.html#CROSSDOMAINXML
-
MSDN: «Making a Service Available Across Domain Boundaries» — http://msdn.microsoft.com/en-us/library/cc197955(v=vs.95).aspx
-
MSDN: «Network Security Access Restrictions in Silverlight» — http://msdn.microsoft.com/en-us/library/cc645032(v=vs.95).aspx
-
Stefan Esser: «Poking new holes with Flash Crossdomain Policy Files» — http://www.hardened-php.net/library/poking_new_holes_with_flash_crossdomain_policy_files.html
-
Jeremiah Grossman: «Crossdomain.xml Invites Cross-site Mayhem» — http://jeremiahgrossman.blogspot.com/2008/05/crossdomainxml-invites-cross-site.html
-
Google Doctype: «Introduction to Flash security » — http://code.google.com/p/doctype-mirror/wiki/ArticleFlashSecurity