Кросс-доменные ограничения

Оригинал:The Same-Origin Policy
Авторы: Eunsuk Kang, Santiago Perez De Rosso, and Daniel Jackson,
Дата публикации: July 12, 2016
Перевод: Н.Ромоданов
Дата перевода: январь 2017 г.

Это пятая часть статьи "Кросс-доменные ограничения".
Перейти к началу статьи.

Кросс-доменные ограничения

Прежде, чем мы можем определить, что такое кросс-доменные ограничения, первое, что мы должны сделать, это ввести понятие происхождения (origin), которое состоит из протокола, хоста и необязательного порта:

sig Origin {
  protocol: Protocol,
  host: Domain,
  port: lone Port
}

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

fun origin[u: Url] : Origin {
    {o: Origin | o.protocol = u.protocol and o.host = u.host and o.port = u.port }
}

Сами кросс-доменные ограничения состоят из двух частей, ограничивая возможность скрипта 1) делать вызовы API DOM и 2) отправлять запросы HTTP. В первой части такой политики устанавливается, что скрипт может читать документ и делать в него записи только в случае, если документ был получен из того же самого источника, что и скрипт:

fact domSop {
  all o: ReadDom + WriteDom |  let target = o.doc, caller = o.from.context |
    origin[target] = origin[caller] 
}

Контрпример, который показан как первый сценарий скрипта (из предыдущего раздела), невозможен для domSop, поскольку скрипт Script не может обращаться к ReadDom при работе с документом из другого источника происхождения.

Вторая часть политики говорит о том, что скрипт не может отправить запрос HTTP на сервер, если его контекст не имеет то же самое происхождение, что и целевой URL; это ограничение эффективно предотвращает такую ситуацию, как второй сценарий использования скрипта.

fact xmlHttpReqSop { 
  all x: XmlHttpRequest | origin[x.url] = origin[x.from.context.src] 
}

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

Однако оказывается, что кросс-доменные ограничения могут быть слишком ограничивающими. Например, иногда вы хотите обеспечить связь между двумя документами различного происхождения. По приведенному выше определению происхождения скрипт из хоста foo.example.com не сможет прочитать содержимое документа, поступившего из хоста bar.example.com, или отправить запрос HTTP на хост www.example.com, поскольку все они считаются различными хостами.

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

Перейти к следующей части статьи.

Перейти к началу статьи.

---

---

---