CORS. Какова мотивация внедрения предполетных запросов?

Совместное использование ресурсов – это механизм, позволяющий веб-странице создавать XMLHttpRequests в другом домене (из википедии ), и это очень важно (от меня :).

Я занимаюсь CORS в течение последних нескольких дней, и я думаю, что у меня довольно хорошее представление о том, как все работает.

Поэтому мой вопрос заключается не в том, как работает CORS / preflight, а в том, что причина появления предвоенных очков в качестве нового типа запроса . Я не вижу причин, по которым сервер A должен отправлять предполетную запись (PR) на сервер B только для того, чтобы узнать, будет ли принят реальный запрос (RR), или нет – было бы возможно, чтобы B принимал / отклонял RR без любой предшествующий PR.

После некоторого поиска я нашел эту информацию на сайте www.w3.org (7.1.5):

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

Я считаю, что это труднее всего понять. Моя интерпретация (лучше назвать ее «наилучшей догадкой») заключается в том, что она защищает сервер B от запросов сервера C, которые не знают о спецификации.

Может кто-нибудь объяснить сценарий / показать проблему, что PR + RR решает лучше, чем RR?

    Я потратил некоторое время на то, чтобы смутить насчет цели предполетного запроса, но я думаю, что у меня есть это сейчас.

    Ключевое понимание заключается в том, что предполетные запросы не являются безопасными . Скорее, они не меняются .

    Запросы перед полетом не имеют ничего общего с безопасностью, и они не имеют отношения к приложениям, которые разрабатываются сейчас, с осознанием CORS. Скорее, механизм предполетности приносит пользу серверам, которые были разработаны без осознания CORS, и он функционирует как проверка соответствия между клиентом и сервером, что они оба осведомлены о CORS. Разработчики CORS чувствовали, что там было достаточно серверов, которые полагались на предположение, что они никогда не получат, например, междоменный запрос DELETE, который они изобрели механизм предполета, чтобы позволить обеим сторонам отказаться. Они считали, что альтернатива, которая должна была бы просто разрешить междоменные вызовы, нарушила бы слишком много существующих приложений.

    Здесь есть три сценария:

    1. Старые серверы, которые еще не разрабатывались и разрабатывались до CORS. Эти серверы могут делать предположения, что они никогда не получат, например, запрос DELETE для междоменного домена. Этот сценарий является основным бенефициаром предполетного механизма. Да, эти службы уже могут злоупотреблять злонамеренным или несоответствующим пользовательским агентом (и CORS ничего не меняет), но в мире с CORS механизм предполетности обеспечивает дополнительную «проверку работоспособности», чтобы клиенты и серверы не перерыв, потому что основные правила Интернета изменились.

    2. Серверы, которые все еще находятся в разработке, но которые содержат много старого кода и для которых не представляется возможным / желательно провести аудит всего старого кода, чтобы убедиться, что он работает правильно в междоменном мире. Этот сценарий позволяет серверам постепенно входить в CORS, например, говоря: «Теперь я разрешу этот конкретный заголовок», «Теперь я разрешу этот конкретный HTTP-глагол», «Теперь я разрешу cookies / auth отправлено “и т. д. Этот сценарий зависит от механизма предполета.

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

    Какова была мотивация внедрения предполетных запросов?

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

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

    Можете ли вы привести мне пример?

    Представим себе, что пользователь браузера зарегистрирован на своем банковском сайте на A.com . Когда они переходят на вредоносный B.com , эта страница включает в себя некоторый Javascript, который пытается отправить запрос DELETE на A.com/account . Поскольку пользователь зарегистрирован на A.com , этот запрос, если он отправлен, будет содержать cookies, которые идентифицируют пользователя.

    Перед тем, как CORS, политика одинакового происхождения браузера заблокировала бы его отправку этого запроса. Но поскольку цель CORS заключается в том, чтобы сделать возможным такое перекрестное происхождение, это уже не подходит.

    Браузер мог просто отправить DELETE напрямую и оставить все на сервере. Но что, если A.com не знает протокол CORS? Это может пойти вперед и выполнить опасный DELETE . Он предположил, что он никогда не сможет получить такой запрос из-за политики одинакового происхождения браузера, и поэтому он никогда не был разработан, чтобы помешать такой атаке.

    Чтобы защитить такие серверы, не поддерживающие CORS, тогда для протокола требуется, чтобы браузер сначала отправил запрос предварительной проверки . Этот новый вид запроса – это то, что только серверы, поддерживающие CORS, могут правильно реагировать, позволяя браузеру знать, безопасно ли отправлять фактический DELETE .

    Почему все эти проблемы в браузере, не может злоумышленник просто отправить запрос DELETE со своего компьютера?

    Конечно, но такой запрос не будет содержать cookies пользователя. Атака, которая предназначена для предотвращения, полагается на то, что браузер отправит cookies (в частности, информацию аутентификации для пользователя) для другого домена вместе с запросом.

    Это похоже на кросс-сайт запроса Forgery , где форма на сайте B.com может POST на A.com с cookie пользователя и наносить урон.

    Это верно. Другим способом для этого является то, что запросы предполета были созданы, чтобы не увеличивать поверхность атаки CSRF для серверов, не поддерживающих CORS.

    Но, глядя на требования к «простым» запросам, которые не требуют предвоенных рейсов, я вижу, что POST по-прежнему разрешен. Это может изменить состояние и удалить данные, как DELETE !

    Это правда! CORS не защищает ваш сайт от атак CSRF. Опять же, без CORS вы также не защищены от атак CSRF. objective предполетных запросов – просто ограничить воздействие CSRF на то, что уже существовало в мире pre-CORS.

    Вздох. Хорошо, я неохотно согласен с необходимостью предполетных запросов. Но почему мы должны делать это для каждого ресурса (URL) на сервере? Сервер либо обрабатывает CORS, либо нет.

    Вы уверены, что? Для нескольких серверов нередко обрабатываются запросы для одного домена. Например, может случиться так, что запросы на A.com/url1 обрабатываются одним типом сервера, а запросы на A.com/url2 обрабатываются другим типом сервера. Как правило, сервер, обрабатывающий один ресурс, не может гарантировать безопасность всех ресурсов в этом домене.

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

    Хорошая идея! На самом деле для этой цели был предложен заголовок Access-Control-Policy-Path . В конечном счете, однако, это было исключено из спецификации, по- видимому, потому, что некоторые серверы неправильно реализовали спецификацию URI таким образом, что запросы к путям, которые выглядели безопасными для браузера, на самом деле не были бы безопасными на сломанных серверах.

    Было ли это разумным решением о приоритете безопасности в отношении производительности, позволяя браузерам немедленно реализовать спецификацию CORS без риска для существующих серверов? Или это близоруко, чтобы обречь интернет на трату впустую и удвоить латентность, просто чтобы разместить ошибки на определенном сервере в определенное время?

    Мнения различаются.

    Ну, по крайней мере, браузеры будут кэшировать предполетные баллы для одного URL-адреса?

    Да. Хотя, вероятно, не очень долго. В браузерах WebKit максимальное время кэша перед полетом составляет 10 минут .

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

    Ваш единственный реальный вариант – убедиться, что вы отвечаете требованиям «простых» запросов. Это может означать отказ от пользовательских заголовков, которые вы могли бы включить (например, X-Requested-With ), лежащих на Content-Type или больше.

    Независимо от того, что вы делаете, вы должны убедиться, что у вас есть надлежащая защита CSRF, поскольку спецификация CORS не направлена ​​на отказ от «простых» запросов, включая небезопасный POST . Как указано в спецификации : «ресурсы, для которых простые запросы имеют значение, отличные от поиска, должны защищать себя от подделки запросов на межсайтовый запрос».

    Рассмотрим мир междоменных запросов до CORS. Вы можете выполнить стандартную форму POST или использовать script или тег image для выдачи запроса GET. Вы не могли бы сделать другой тип запроса, кроме GET / POST, и вы не могли бы выпускать какие-либо пользовательские заголовки для этих запросов.

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

    Таким образом, запросы GET / POST без каких-либо пользовательских заголовков не нуждаются в предполетной проверке, так как эти запросы уже были возможны до CORS. Но любой запрос с пользовательскими заголовками или запросы PUT / DELETE нуждаются в предполетной проверке, поскольку они новы к спецификации CORS. Если сервер ничего не знает о CORS, он будет отвечать без каких-либо заголовков CORS, и фактический запрос не будет выполнен.

    Без запроса предполетных серверов серверы могут начинать видеть неожиданные запросы от браузеров. Это может привести к проблеме безопасности, если серверы не были подготовлены к этим типам запросов. Предварительная проверка CORS позволяет безопасно вводить междоменные запросы в сеть.

    CORS позволяет указать больше заголовков и типов методов, чем это было возможно ранее с помощью cross-origin или

    .

    Некоторые серверы могли быть (плохо) защищены с допущением, что браузер не может выполнить, например, запрос DELETE перекрестного происхождения или запрос с кросс-началом с заголовком X-Requested-With , поэтому такие запросы являются «доверенными».

    Чтобы убедиться, что сервер действительно поддерживает CORS и не просто реагирует на случайные запросы, выполняется предварительный просмотр.

    Вот еще один способ взглянуть на него, используя код:

        

    Pre-CORS, попытка эксплойта выше завершилась неудачей, поскольку она нарушает политику одного и того же происхождения. Разработанный таким образом API не нуждался в защите XSRF, поскольку он был защищен собственной моделью безопасности браузера. Невозможно, чтобы браузер pre-CORS создавал JSON POST с перекрестным происхождением.

    Теперь CORS выйдет на сцену – если отказ в CORS через предполетный рейс не потребовался, внезапно этот сайт будет иметь огромную уязвимость, не по своей вине.

    Чтобы объяснить, почему некоторым запросам разрешено пропустить предварительный рейс, на это отвечает спецификация:

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

    Чтобы распутать это, GET не является предварительным, потому что это «простой метод», как это определено в 7.1.5. (Заголовки также должны быть «простыми», чтобы избежать предполетного полета). Обоснование этого заключается в том, что «простой» запрос GET с перекрестным происхождением уже можно выполнить, например, (так работает JSONP). Поскольку любой элемент с атрибутом src может запускать GET с перекрестным происхождением, без предполетного полета, не было бы никакой выгоды в плане безопасности, требующей предварительного боя на «простых» XHR.

    Я чувствую, что другие ответы не сосредотачиваются на том, что пред-бой усиливает безопасность.

    Сценарии:

    1) С предварительным полетом . Злоумышленник подделывает запрос с сайта dummy-forums.com, пока пользователь аутентифицирован на safe-bank.com
    Если сервер не проверяет происхождение и каким-то образом имеет недостатки, браузер выдаст запрос перед полетом, метод OPTION. Сервер не знает ни одного из этих CORS, которые браузер ожидает в качестве ответа, поэтому браузер не будет действовать (никакого вреда вообще)

    2) Без предполетного полета . Злоумышленник подделывает запрос по тому же сценарию, что и выше, браузер немедленно выдаст запрос POST или PUT, сервер принимает его и может его обработать, это потенциально может нанести некоторый вред.

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

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

    Кроме того, для методов HTTP-запросов, которые могут вызывать побочные эффекты для пользовательских данных (в частности, для HTTP-методов, отличных от GET, или для использования POST с определенными типами MIME), спецификация требует, чтобы браузеры «предваряли» запрос

    Источник

    Не заданы ли предпродажные запросы о производительности ? При запросах с предполетным запросом клиент может быстро узнать, разрешена ли операция, прежде чем отправлять большой объем данных, например, в JSON с помощью метода PUT. Или перед переносом конфиденциальных данных в заголовках аутентификации по проводке.

    Факт PUT, DELETE и других методов, помимо пользовательских заголовков, по умолчанию не разрешен (им требуется явное разрешение с помощью «Access-Control-Request-Methods» и «Access-Control-Request-Headers»), что звучит как двойная проверка, потому что эти операции могут иметь большее значение для пользовательских данных, а не для запросов GET. Таким образом, это звучит так:

    «Я видел, что вы разрешаете межсайтовые запросы из http: //foo.example , НО ВЫ УВЕРЕНЫ, что вы разрешите DELETE-запросы? Вы считали, какие воздействия могут вызвать эти запросы в пользовательских данных?»

    Я не понял приведенную корреляцию между запросами на предварительную проверку и преимуществами старых серверов. Веб-служба, которая была внедрена до CORS, или без осведомленности о CORS, никогда не получит ЛЮБОГО кросс-сайта, потому что сначала их ответ не будет иметь заголовок «Access-Control-Allow-Origin».

    В браузере, поддерживающем CORS, запросы чтения (например, GET) уже защищены политикой одного и того же происхождения: вредоносный веб-сайт, пытающийся выполнить аутентифицированный междоменный запрос (например, на веб-сайт интернет-банкинга жертвы или интерфейс конфигурации маршрутизатора) не будет иметь возможность читать возвращаемые данные, потому что банк или маршрутизатор не устанавливают заголовок Access-Control-Allow-Origin .

    Тем не менее, при написании запросов (например, POST) урон происходит, когда запрос поступает на веб-сервер. * Вебсервер может проверить заголовок Origin чтобы определить, является ли запрос законным, но эта проверка часто не выполняется, поскольку либо на веб-сервере нет потребность в CORS или веб-сервере старше CORS и поэтому предполагает, что междоменные POST полностью запрещены политикой одного и того же происхождения.

    Вот почему веб-серверам предоставляется возможность принять участие в получении запросов на междоменную запись .

    * По существу версия CSRF AJAX.

    Interesting Posts

    чтение строки с пробелами с помощью sscanf

    Как передать объект в int

    Лог%% по процессу со временем

    Каков самый простой способ jQuery иметь «позицию: фиксированный» (всегда сверху) div?

    Почему оцененные ряды очень сильно отличаются по результатам phpmyadmin?

    Импорт библиотеки google-play-service, показывающей красный X рядом с этим справочным андроидом

    Как определить жесткий диск или USB-диск данного диска с помощью cmd?

    Как предотвратить множественную отправку формы в .NET MVC без использования Javascript?

    Могу ли я обновить зашифрованную WindowsCryptor машину Windows 8.1 до Windows 10?

    Целочисленное деление всегда равно нулю

    Как вы заказываете цвета заливки в ggplot2 geom_bar

    Изменение системной яркости программно

    Есть ли библиотека Java, которая может «отличать» два объекта?

    Как предоставить файлы данных для тестов на андроид

    Как сохранить экран в своем приложении?

    Давайте будем гением компьютера.