Подтвердить что ты не робот

Почему API-интерфейсы браузера ограничивают междоменные запросы?

XMLHttpRequest требуют, чтобы CORS работал в междоменном режиме. Аналогично для веб-шрифтов, текстур WebGL и некоторых других вещей. В общем, все новые API, похоже, имеют это ограничение.

Почему?

Это так легко обойти: все, что требуется, это простой серверный прокси. Другими словами, серверный код не запрещается выполнять междоменные запросы; почему клиентский код? Как это дает какую-либо безопасность любому?

И это так непоследовательно: я не могу XMLHttpRequest, но я могу <script src> или <link rel> или <img src> или <iframe>. Что делает ограничение XHR и т.д. Даже достигать?

4b9b3361

ОТВЕТЫ

Ответ 1

Если я посещаю вредоносный веб-сайт, я хочу быть уверенным, что:

  • Он не может читать мои личные данные с других сайтов, которые я использую. Подумайте, как атаковать злоумышленник gmail.com.
  • Он не может выполнять действия от моего имени на других сайтах, которые я использую. Подумайте, что атакующий сайт переводит средства из моей учетной записи на сайте bank.com.

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

Такая же политика происхождения в целом соответствует следующим правилам -

  • Правило 1: не позволяет читать что-либо из другого домена
  • Правило 2: Позволяет писать все, что угодно, в другом домене, но правило №1 не позволит вам прочитать ответ.
  • Правило 3: вы можете свободно делать запросы GET для кросс-домена и запросы POST, но вы не можете управлять заголовками HTTP

Давайте посмотрим, как различные перечисленные вами вещи соответствуют приведенным выше правилам:

  • Теги

  • <img> позволяют вам делать HTTP-запрос, но нет способа прочитать содержимое изображения, кроме простого его отображения. Например, если я сделаю это <img src="http://bank.com/get/latest/funds"/>, запрос будет проходить (правило 2). Но нападающий не может видеть мой баланс (правило 1).

    Теги

  • <script> работают в основном как <img>. Если вы сделаете что-то вроде <script src="http://bank.com/get/latest/funds">, запрос будет проходить. Браузер также попытается проанализировать ответ как JavaScript и не выполнит свою работу.

  • Известно злоупотребление тегами <script>, называемыми JSONP, где вы вступаете в сговор с междоменным сервером, чтобы вы могли "читать" кросс-домен. Но без явного участия междоменного сервера вы не можете прочитать ответ через тег <script>

  • <link> для таблиц стилей работают в основном как теги <script>, за исключением того, что ответ оценивается как CSS. В общем, вы не можете прочитать ответ - если ответ каким-то образом не будет хорошо сформированным CSS.

  • <iframe> - это, по сути, новое окно браузера. Вы не можете прочитать HTML-код междоменного iframe. Кстати, вы можете изменить URL-адрес междоменного iframe, но вы не можете прочитать URL-адрес. Обратите внимание, как это следует из двух правил, упомянутых выше.

  • XMLHttpRequest - самый универсальный метод для запросов HTTP. Это полностью находится в управлении разработчиками; браузер не делает ничего с ответом. Например, в случае <img>, <script> или <link> браузер принимает определенный формат и в целом будет соответствующим образом проверять его. Но в XHR нет предписанного формата ответа. Таким образом, браузеры применяют одну и ту же политику происхождения и не позволяют вам прочитать ответ, если веб-сайт перекрестного домена явно не позволяет вам.

  • Шрифты через font-face являются аномалией. AFAIK, только для Firefox требуется поведение при входе; другие браузеры позволяют использовать шрифты так же, как вы использовали бы изображения.

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

EDIT. Почему я не могу обойти все это с помощью прокси-сервера на стороне сервера?

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

Прокси-сервер на стороне сервера не может получить доступ к файлам cookie или базовым учетным данным. И поэтому, даже если он может сделать запрос, сервер не будет возвращать данные, специфичные для пользователя.

Ответ 2

Рассмотрим этот сценарий...

  • Вы попадаете на мой вредоносный веб-сайт.
  • Мой сайт делает XHR на ваш банковский сайт и запрашивает форму для банковского перевода.
  • XHR читает токен, который предотвращает CSRF и POST-форму вместе с маркером безопасности и передает денежную сумму моей учетной записи.
  • (I) Прибыль!!!

Без той же самой политики происхождения, вы все равно можете POST, но вы не сможете запросить токен CSRF, который предотвращает CSRF.

Серверный код сервера не запускается на клиентском компьютере.

Ответ 3

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

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