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

прочитав о CORS (Cross-Origin Resource Sharing), я не понимаю, как это улучшает безопасность. Междоменная связь AJAX разрешена, если отправлен правильный заголовок ORIGIN. В качестве примера, если я отправлю

происхождение:http://example.com

сервер проверяет, находится ли этот домен в белом списке и, если он есть, заголовок:

Access-Control-Allow-Origin: [полученный url Здесь]

отправляется обратно вместе с ответ (это простой случай, есть также предварительные запросы, но вопрос тот же).

Это действительно безопасно? Если кто-то хочет получить информацию, подделка заголовков ORIGIN кажется действительно тривиальной задачей. Также стандарт говорит, что политика применяется в браузере, блокируя ответ, если Access-Control-Allow-Origin неверен. Очевидно, что если кто-то пытается получить эту информацию, он не будет использовать стандартный браузер для ее блокировки.

70
ajax cors cross-domain javascript

6 ответов

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

Он разработан таким образом, что задано:

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

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

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

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

42

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

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

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

127

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

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

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

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

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

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

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

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

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

38

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

14

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

CORS не улучшает безопасность. CORS предоставляет механизм для серверов, чтобы сообщить браузерам, как они должны быть доступны для иностранных доменов, и он пытается сделать это таким образом, чтобы это соответствовало модели безопасности браузера, которая существовала до CORS (а именно Та Же Политика Происхождения).

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

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

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

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

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

3

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

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

1