Библиотека сайта rus-linux.net
Кросс-доменные ограничения
Оригинал:The Same-Origin Policy
Авторы: Eunsuk Kang, Santiago Perez De Rosso, and Daniel Jackson,
Дата публикации: July 12, 2016
Перевод: Н.Ромоданов
Дата перевода: январь 2017 г.
Перевод главы 17 из книги "500 Lines or Less", которая представляет собой четвертый том серии "Архитектура приложений с открытым исходным кодом".
Creative Commons
Перевод был сделан в соответствие с лицензией . С русским вариантом лицензии можно ознакомиться .
Инсак Кан (Eunsuk Kang) является аспирантом и членом группы Software Design Group в Массачусетском технологическом институте. Он получил степень магистра в области компьютерных наук в Массачусетском технологическом институте (2010 год), и степень бакалавра инженерии программного обеспечения в Университете Ватерлоо (2007 год). Его исследовательские проекты были сосредоточены на разработке инструментов и методов моделирования и верификации программного обеспечения и их применения в системах безопасности и критически важных системах.
Сантьяго Перес Де Россо (Santiago Perez De Rosso) является аспирантом группы Software Design Group в Массачусетском технологическом институте. Он получил степень магистра в области компьютерных наук в MIT (2015 год), и степень бакалавра в ITBA (2011 год). Раньше он работал в Google, разрабатывал фреймворки и инструментальные средства, повышающие производительность инженеров-программистов (2012 год). В настоящее время он тратит большую часть своего времени на размышления о системах проектирования и управления версиями.
Дэниел Джексон (Daniel Jackson) является профессором кафедры электротехники и вычислительной техники (Department of Electrical Engineering and Computer Science) в Массачусетском технологическом институте, и возглавляет группу Software Design Group в лаборатории компьютерных наук и искусственного интеллекта Computer Science and Artificial Intelligence Laboratory. Он получил степень магистра физики в Оксфордском университете (1984 год) и степень магистра (1988 год) и доктора философии (1992 год) в области компьютерных наук в Массачусетском технологическом институте. Он был инженером-программистом в компании Logica UK Ltd. (1984-1986 годы), доцентом кафедры компьютерных наук в Университете Карнеги-Меллона (1992-1997 годы) и работает в Массачусетском технологическом институте с 1997 года. Его интересует разработка программного обеспечения, в частности разработка архитектуры и и спецификаций, формальные методы, а также безопасность критически важных систем.
Введение
Принцип кросс-доменных ограничений (The same-origin policy - SOP) является важной частью механизма безопасности любого современного браузера. Он управляет тем, как скрипты, запущенные в браузере, могут взаимодействовать друг с другом (грубо говоря, тогда, когда они с одного и того же сайта). Впервые представленный в браузере Netscape Navigator, принцип кросс-доменных ограничений в настоящее время играет важную роль в обеспечении безопасности веб-приложений; без него злоумышленнику было бы гораздо проще просмотреть ваши личные фотографии на Facebook-е, прочитать вашу электронную почту, или очистить ваш банковский счет.
Но этот принцип далек от совершенства. Иногда он оказывается слишком ограничивающий; бывают случаи (например, при создании коллажей), когда скрипты должны получать данные из разных источников, но не могут этого сделать. В других случаях он ограничивает недостаточно, в результате чего остаются лазейки, которые можно использовать с помощью обычных атак, таких как подделка межсайтового запроса. Принцип кросс-доменных ограничений разрабатывался постепенно на протяжении многих лет и был результатом размышлений многих разработчиков.
Цель этой главы заключается в том, чтобы отразить сущность этого важного и часто неправильно понимаемого принципа. В частности, мы попытаемся ответить на следующие вопросы:
- Почему необходимы кросс-доменные ограничения? Каким видам нарушений безопасности они препятствуют?
- Каким образом кросс-доменные ограничения влияют на поведение веб-приложения?
- Каковы различные механизмы обхода кросс-доменных ограничений?
- Насколько надежны эти механизмы? Каковы потенциальные проблемы безопасности, которые могут возникать из-за кросс-доменных ограничений?
Если учитывать сложность всех задействованных компонентов - веб-серверов, браузеров, документов HTTP и языка HTML, скриптов клиентской стороны и так далее, охват всех вопросов кросс-доменных ограничений в целом является непростой задачей, Мы, скорее всего, увязнем в неприукрашенных деталях всех этих компонентов (и потратим наши 500 строк, прежде чем даже дойдем до рассмотрения кросс-доменных ограничений). Но как мы можем надеяться на то, чтобы быть точными, и не рассматривать важные детали?
Моделирование с помощью языка Alloy
Эта глава несколько отличается от других глав этой книги. Вместо того чтобы строить рабочую реализацию, мы построим исполняемую модель, которая служит в качестве простого, но точного описания кросс-доменных ограничений. Как и реализация, модель может быть выполнена для изучения динамического поведения системы, но, в отличие от реализации, в модели нет низкоуровневых частностей, которые могут возникнуть на пути понимания основных концепций.
Подход, который мы применяем, можно назвать "гибким моделированием" (или "моделированием в стиле agile" — прим.пер.) из-за его сходства с гибкой программирования (или "программированием в стиле agile" — прим.пер.). Мы работаем маленькими шажками, собирая модель по кусочкам. Наша постепенно разрабатываемая модель является чем-то, что может быть выполнено. По ходу дела мы создаем и запускаем тесты, так что к концу у нас будет не только сама модель, но и набор свойств, которой будет удовлетворять модель.
Для построения этой модели мы используем /i>Alloy, язык для моделирования и анализа программных проектов. Модель на языке Alloy нельзя выполнить в традиционном смысле исполнения программы. Вместо этого, модель можно использовать 1) для моделирования с тем, чтобы получить экземпляр модели, который представляет собой правильный сценарий или конфигурацию системы, и 2) для проверки того, удовлетворяет ли модель желаемым свойствам.
Несмотря на приведенное выше сходство, гибкое моделирование отличается от гибкого программирования в одном ключевом аспекте: Хотя мы будем выполнять тесты, мы, на самом деле, ничего писать не будем. Анализатор языка Alloy генерирует тесты автоматически, и все, что должно быть сделано, это указать свойство, которое должно быть проверено. Излишне говорить, что это экономит много труда (и сокращает код). Анализатор фактически просматривает всевозможные тестовые варианты до определенного размера (так называемой областью видимости scope); это обычно означает, что генерируются все начальные состояния не более, чем с некоторым количеством объектов, а затем выбрать операции и аргументы, которые применяются для не более, чем некоторого числа шагов. Поэтому выполняется так много тестов (как правило, миллиарды) и поэтому при тестировании охватывается всевозможные состояния (хотя и в пределах некоторого объема), так что такой анализ способен более эффективно находить ошибки, чем обычное тестирования (которое иногда называют "ограниченной проверкой").
Упрощения
Поскольку кросс-доменные ограничения работают в контексте браузеров, серверов, HTTP, и так далее, полное описание будет просто громадным. Поэтому наша модель (как и все модели) абстрагируется от не относящихся к делу аспектов, например, от того, как структурированы и разбиты на части сетевые пакеты. Но из-за этого также упрощаются некоторые важные факторы, что означает, что модель не сможет в полной мере учесть всевозможные уязвимости, касающиеся безопасности.
Например, мы трактуем запросы HTTP как дистанционные вызовы процедур, игнорируя тот факт, что ответы на запросы могут изменять свой порядок. Мы также предполагаем, что служба DNS (служба доменных имен) является статической, поэтому мы не можем рассматривать атаки, в которых настройки DNS изменяются в процессе взаимодействия. Однако, в принципе можно было бы расширить нашу модель с тем, чтобы охватить все эти аспекты, хотя согласно самой природе анализа безопасности ни одна модель (даже если в качестве модели взять весь имеющийся код) не может гарантировать, что она будет полной.
Наши планы
Мы будем работать с нашей моделью кросс-доменных ограничений в следующем порядке. Мы начнем с построения модели из трех ключевых компонентов, которые нам нужны для того, чтобы можно было говорить о кросс-доменных ограничениях: протоколе HTTP, браузере и скриптов клиентской стороны. Мы будем все строить поверх этих базовых моделей и определим, что означает для веб-приложения быть безопасным, а затем введем кросс-доменные ограничения в качестве механизма, с помощью которого пытается достичь требуемых свойств безопасности.
Затем мы увидим, что кросс-доменные ограничения иногда могут быть слишком ограничительными, когда с помощью них определяется способ правильного функционирования веб-приложения. Поэтому мы добавим четыре различных способа, которыми обычно пользуются для того, чтобы обойти ограничения, налагаемые политикой кросс-доменных ограничений.
Вы можете изучать разделы данной главы в любом порядке, который вам понравится. Если вы новичок в применении языка Alloy, то мы рекомендуем начать с первых трех разделов (протокол HTTP, браузер, и скрипт), поскольку в них представлены некоторые из основных понятий языка моделирования. По мере того, пока вы будете изучать эту главу, мы также рекомендуем вам поэкспериментировать с моделями в анализаторе Alloy Analyzer: запускать их, изучить основные скрипты, попытаться сделать в моделях изменения и увидеть их последствия. Модель .
Перейти к следующей части статьи.