[26] D. Crockford. (2001) JavaScript - The World's Most Misunderstood Programming Language. [Online]. http://javascript.crockford.com/javascript.html
[27] A. Barth, J. Caballero, and D. Song. (2009) Secure Content Sniffing for Web Browsers, or How to Stop Papers from Reviewing Themselves. [Online]. http://www.adambarth.com/papers/2009/barth-caballero- song.pdf
[28] The World Wide Web Consortium (W3C). (2010, Jul.) Cross-Origin Resource Sharing. [Online]. http://www.w3.org/TR/cors/
[29] The World Wide Web Consortium (W3C). (2010, Jan.) Same-Origin Policy. [Online]. http://www.w3.org/Security/wiki/Same_Origin_Policy
[30] The World Wide Web Consortium (W3C). (2009, Dec.) Web Storage. [Online]. http://www.w3.org/TR/webstorage/
[31] The World Wide Web Consortium (W3C). (2008, May) Offline Web Applications. [Online]. http://www.w3.org/TR/offline-webapps/
[32] The World Wide Web Consortium (W3C). (2010, Nov.) HTML5 Web Messaging. [Online]. http://www.w3.org/TR/webmessaging/
[33] The World Wide Web Consortium (W3C). (2009, Dec.) The Web Sockets API. [Online]. http://www.w3.org/TR/websockets/
[34] The World Wide Web Consortium (W3C). (2010, Sep.) Geolocation API Specification. [Online]. http://www.w3.org/TR/geolocation-API/
[35] Attack and Defense Labs. (2010, Dec.) HTML5 Security - Web SQL / Cross Origin Requests. [Online]. http://www.andlabs.org/html5.html
Безопасность HTML5 – часть вторая
Данный документ содержит выдержки из магистерской диссертации Майкла Шмидта. Здесь отражены рассмотренные в диссертации аспекты HTML5, касающиеся безопасности.
Автор: Michael Schmidt (Compas Security)
2.2 Cross-Origin Resource Sharing
До HTML5 сайты могли заставлять ПА делать XMLHttpRequest-запросы лишь в пределах их собственного домена (из-за политики ограничения домена). Поэтому получать доступ к ресурсам вроде обновлений для частей веб-страницы было возможно только в пределах исходного домена, что ограничивало веб-разработчиков. Это представляло особенную проблему для веб-приложений, которые состоят из нескольких частей, отображающих данные с различных доменов. Загрузка и обновление этих данных были возможны лишь через исходный домен, так что XMLHttpRequest-запросы приходилось присылать на исходный сервер. Этот сервер должен был обрабатывать запрос, загружать данные с других доменов и передавать их назад, браузеру. Такая маршрутизация (называемая также Server-Side Proxying, т. е. Проксирование на стороне сервера) приводила к высокой нагрузке на сервера, а также усложняла и замедляла обновление страниц или их частей.
Атаки с помощью HTML5
С приходом HTML5 ситуация изменилась. HTML5 позволяет посылать XMLHttpRequest-запросы между доменами, если определен HTTP-заголовок "Access-Control-Allow-Origin". При некотором значении этого заголовка, XMLHttpRequest-запрос, посланный Java-скриптом с одного домена, может получить доступ к сайту на другом домене. Веб-приложение, состоящее из множества частей, находящихся на различных доменах, может также посылать XMLHttpRequest-запросы другим доменам, чтобы обновлять данные в браузере. Это снижает трафик между веб-серверами и упрощает реализацию.
Решение о том, может ли JavaScript в ходе XMLHttpRequest-запроса получить данные не от исходного домена, принимается ПА. То есть, ПА сначала делает запрос к другому домену, а затем осуществляет контроль доступа на основе заголовка Access-Control-Allow-Origin. Этот заголовок определяет, может ли JavaScript получить доступ к ответу на запрос или нет. Таким образом, веб-сервер определяет этим заголовком, каким доменам разрешен доступ к его домену путем междоменных запросов. Если данный заголовок не содержит запрашивающий домен или вовсе не определен, браузер не даст JavaScript получить ответ на запрос. Следующий пример перехваченного сетевого трафика показывает HTTP-ответ сервера из внешнего домена external.csnc.ch с установленным заголовком контроля доступа.
HTTP/1.1 200 OK
Content-Type: text/html
Access-Control-Allow-Origin: http://internal.csnc.ch
Данный фрагмент показывает, что заголовок Access-Control-Allow-Origin имеет значение internal.csnc.ch. Это означает, что лишь сайты с домена internal.csnc.ch имеют право доступа к external.csnc.ch через XMLHttpRequest.
В предыдущих параграфах было дано верное, но сокращенное описание Междоменного Разделения Ресурсов (CORS). На самом деле, в CORS существует больше деталей и посылается больше сообщений при определенных обстоятельствах, например, предварительный (preflight) запрос/ответ. Раздел 5.3.1 описывает шаги обработки CORS более подробно. Кроме того, в разделе 5.2.1 можно найти демонстрационное приложение, которое иллюстрирует междоменный запрос (Cross-Origin Request, COR), а также соответствующий дамп сетевого трафика. Это демонстрационное приложение можно использовать для загрузки произвольного URI через XMLHttpRequest и отображения результата на веб-странице (если целевой сайт посылает в ответе должным образом определенный заголовок Access-Control-Allow-Origin).
2.2.1 Уязвимости
Вместе с появлением этой новой возможности HTML5 возникают и новые уязвимости. Фундаментальная проблема безопасности заключается в том, что междоменные XMLHttpRequest-запросы можно посылать, не спрашивая разрешения у пользователя. На самом деле запросы посылаются даже без уведомления пользователя. Это можно использовать для нарушения требования безопасности "Контроль доступа" через злоупотребление пользовательской сессией. Это означает, что данные запросы делаются от лица жертвы, которая может оказаться аутентифицированным пользователем. Происходит злоупотребление пользовательской сессией, что нарушает требование безопасности "Безопасное управление сессиями".
Вслед за "Контролем доступа" нарушается следующее требование безопасности, "Конфиденциальность". Это делается либо прямым доступом к ресурсам через обход "Контроля доступа", либо косвенно, если доступ к конфиденциальным данным получается путем злоупотребления пользовательскими сессиями для сбора информации о жертве.
Другая проблема, связанная с CORS, заключается в том, что источник данных больше не ограничен сервером сайта. Браузер может загружать данные из других источников, которые не могут быть проверены исходным доменом и должны считаться недоверенными. Таким образом, данные, полученные через CORS, должны проверяться на стороне клиента. Эта проблема (требование безопасности «Проверка данных») связана также с технологиями Web Socket API (см. раздел 2.7) и Web Messaging (раздел 2.5) и поэтому рассматривается лишь однажды, в разделе 2.5.1.
2.2.2 Угрозы и сценарии атак
В этом подразделе приводятся некоторые сценарии эксплуатации злоумышленником проблем безопасности, описанных в разделе 2.2.1. Сценарии атак для следующих четырех угроз будут даны в параграфах 2.2.2.1-2.2.2.4 для демонстрации эффекта этих угроз. Идеи сценариев атак