Политика XMLHttpRequest одинакового происхождения

Я провел последние 3 дня, изучая, как сделать запрос перекрестного домена, используя XMLHttpRequest. Лучшая альтернатива действительно с JSONP, которую я уже использую.

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

Сказано, что я читал на многих сайтах, что из-за соображений безопасности я не могу сделать запрос Ajax от домена aaa.com к bbb.com и получить нужные данные. Это очень ясно, и я не сомневаюсь в этом. НО проблема в том, что когда я запускаю код ниже в своем локальном хосте (мой домен является "localhost", и я не должен иметь возможность запрашивать какие-либо данные из другого домена).

xhReq = new XMLHttpRequest();
xhReq.open("GET","http://domain.com?parameter",true);
xhReq.send(null);

Когда я проверяю вкладку Firebug Net, я понимаю, что запрос не был заблокирован! Это было явно запрошено. Я не мог поверить. Поэтому я создал файл в domain.com/log.php, где я мог зарегистрировать любой запрос, который попал в мой домен. Удивительно, что все запросы, которые я запускал localhost, попали на мой домен .com. Когда я попытался получить ответ, я действительно не смог получить его из-за той же политики происхождения моего браузера Chrome и FIrebug. Но я был очень удивлен, что запрос действительно попал в веб-сервер, несмотря на то, что я не мог манипулировать ответами.

Более удивительно, что если domain.com/log.php генерирует огромное количество ответов с 1 МБ, мой firebug показал мне, что браузер загружает ВСЕ 1 МБ с веб-сервера, а в конце он показывает сообщение "Доступ запрещен", как и ожидалось. Поэтому зачем загружать весь файл, если одна и та же политика происхождения запрещает чтение этих данных.

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

Что меня расстраивает, так это то, что он может открыть БОЛЬШОЕ отверстие безопасности, в котором каждый день с помощью веб-сайта с тысячами просмотров каждый может запускать этот 3-строчный код и вызывать HUGE Ddos-атаку на недружественном веб-сайте, просто заставляя пользователей запрашивать страницу на другом веб-сайте через небольшие промежутки времени, так как браузер не будет блокировать запрос.

Я тестировал этот script в IE 7, 8 и 9, а также последние версии Chrome и Firefox, и все одинаково: запрос выполняется, и браузер загружает весь ответ, не делая его доступным для SOP.

Надеюсь, кто-то может объяснить мне, почему спецификации настолько ошибочны в этом или что я понимаю неправильно!

Ответ 1

Это происходит из-за того, что на стороне клиента (браузера) применяется одна и та же политика происхождения, оценивая следующие значения заголовка контроля доступа возвращенный с сервера:

  • Access-Control-Allow-Origin
  • Access-Control-Allow-метода
  • Access-Control-Allow-Headers

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

Вы можете взглянуть на "Приоритеты политики одинакового происхождения" А. Барта.

Ответ 2

См. bobince answer по аналогичному вопросу:

В соответствии с уровнем XMLHttpRequest уровня 2 браузеры позволяют использовать GET с перекрестным началом отправляется без предварительной проверки, но не позволяет читать результаты с ответ, за исключением случаев, когда удаленный домен выбирает. уязвимость здесь, потому что вы уже можете привести GET к произвольному URL-адрес, который нужно отправить (включая строку запроса, для чего она стоит) через несколько более основных интерфейсов.

Например, вы всегда можете создать элемент с его src установлен на адрес в удаленном домене; отнимая это междоменная способность могла бы сломать много существующей сети.

по теме: