Является ли CORS безопасным способом выполнять междоменные запросы AJAX?

Ответ 1

Вы не можете подделать заголовок Origin с помощью JavaScript в веб-браузере. CORS предназначен для предотвращения этого.

За пределами веб-браузера это не имеет значения. Он не предназначен для того, чтобы помешать людям получать данные, доступные для общественности. Вы не можете выставить это на всеобщее обозрение без того, чтобы представители общественности его получили.

Он спроектирован так, что дано:

• Алиса, человек, предоставляющий API, разработанный для доступа через Ajax
• Боб, человек с веб-браузером
• Чарли, третье лицо, управляющее собственным сайтом

Если Боб посещает веб-сайт Чарли, то Чарли не может отправить JS в браузер Боба, чтобы он получал данные с веб-сайта Алисы и отправлял их Чарли.

Вышеуказанная ситуация становится еще более важной, если у Боба есть учетная запись пользователя на веб-сайте Алисы, которая позволяет ему делать такие вещи, как оставлять комментарии, удалять данные или просматривать данные, которые не доступны для широкой публики - поскольку без защиты, Чарли Дж. С. мог сказать Бобу браузеру сделать это за спиной Боба (а затем отправить результаты Чарли).

Если вы хотите, чтобы неавторизованные люди не видели данные, вам нужно защитить их паролями, сертификатами SSL-клиентов или другими средствами аутентификации/авторизации на основе идентификации.

Ответ 2

Цель состоит в том, чтобы предотвратить это -

• Вы перейдете на сайт X
• Автор сайта X написал зло script, которое отправляется в ваш браузер
• что script работает в вашем браузере на вашем веб-сайте банка и делает злое дело, и потому что он работает, как вы в своем браузере, у него есть разрешение на это.

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

Ответ 3

Чтобы добавить ответ @jcoder, весь смысл заголовка Origin не в том, чтобы защитить ресурсы, запрошенные на сервере. Эта задача решается самим сервером с помощью других средств именно потому, что злоумышленник действительно может подделать этот заголовок с помощью соответствующих инструментов.

Смысл заголовка Origin - защитить пользователя. Сценарий следующий:

• злоумышленник создает вредоносный веб-сайт M

• пользователь Алиса обманут, чтобы подключиться к M, который содержит скрипт, который пытается выполнить некоторые действия через CORS на сервере B, который фактически поддерживает CORS

• B, вероятно, не будет иметь M в заголовке Access-Control-Allow-Origin, почему?

• Основным моментом является то, что M не имеет возможности подделать или перезаписать заголовок Origin, потому что запросы инициируются браузером Алисы. Поэтому ее браузер установит (правильный) Origin в значение M, которого нет в Access-Control-Allow-Origin в B, поэтому запрос не будет выполнен.

Алиса может изменить заголовок Origin сама, но зачем ей это, поскольку это будет означать, что она наносит вред себе?

TL; DR: заголовок Origin защищает невинного пользователя. Он не защищает ресурсы на сервере. Он может быть подделан злоумышленником на своей собственной машине, но не может быть подделан на машине, не находящейся под его контролем.

Серверы по-прежнему должны защищать свои ресурсы, поскольку соответствующий заголовок Origin не означает санкционированный доступ. Однако заголовок Origin, который НЕ совпадает, означает несанкционированный доступ.

Ответ 4

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

Ответ 5

Прочитав о CORS, я не понимаю, как это повышает безопасность.

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

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

Давайте возьмем пример. Пользователь заходит на сайт A через cookie. Пользователь загружает вредоносный сайт M, который пытается отправить форму, которая выполняет POST в A. Что случится? Ну, с или без CORS, с или без M в качестве разрешенного домена, браузер отправит запрос на A с файлом cookie авторизации пользователя, и сервер выполнит вредоносный POST, как если бы пользователь инициировал это.

Эта атака называется Подделка межсайтовых запросов, и сама CORS не предпринимает никаких действий для ее устранения. Вот почему защита CSRF так важна, если вы разрешаете запросы на изменение данных от имени пользователей.

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

В общем, CORS является полезной спецификацией для расширения существующей модели безопасности Same Origin Policy на другие принятые домены. Это не добавляет безопасности, и сайтам нужны те же механизмы защиты, что и до CORS.

Ответ 6

Я опаздываю, чтобы ответить, но я не думаю, что любое сообщение здесь действительно дает искомый ответ. Самый большой взнос должен заключаться в том, что браузер является агентом, который записывает значение заголовка origin. Зло script не может записать значение заголовка origin. Когда сервер отвечает заголовком Access-Control-Allow-Origin, браузер пытается убедиться, что этот заголовок содержит значение origin, отправленное ранее. Если нет, он вызывает ошибку и не возвращает значение обратно запрашивающему script. Другие ответы на этот вопрос представляют хороший сценарий, когда вы хотите отказать в ответе на зло script.

@daniel f также дает хороший ответ на вопрос