2014-02-18 3 views
11

Я пытаюсь понять, почему CORS работает так, как работает.Понимание AJAX CORS и соображения безопасности

Как я узнал из this post, когда страница из www.a.com делает запрос AJAX к www.b.com, то это www.b.com, который решает, если запрос должен быть разрешен или не.

Но что конкретно защищено на клиенте в такой модели? Например, если хакеру удалось выполнить инъекцию скрипта XSS на мою страницу, он делает запрос AJAX в своем домене для хранения пользовательских данных. Таким образом, домен хакера позволит такой запрос точно.

Я думал, что www.a.com должен решить, к каким доменам разрешить запрос. Итак, теоретически в заголовке Access-Control-Allow-Origin Я хотел бы разместить весь список доменов, разрешенных для запросов AJAX CORS.

Может ли кто-нибудь объяснить, какие проблемы безопасности выполняет текущая реализация CORS?

+0

Да, это правильно, домен, обслуживающий данные (саамы), может перечислить его «разрешенные» домены. (ACAO). После этого SaaS несет ответственность за обеспечение безопасности запросов (посредством регулярного «веб-сервера» - средства для очистки строк, улов DSA и т. Д.), –

ответ

17

Как я узнал из этого поста, когда страница из www.a.com делает запрос AJAX к www.b.com, то это www.b.com решает, если запрос должен быть разрешен или нет.

Не совсем. Запрос не заблокирован.

По умолчанию JavaScript, работающий на www.a.com, запрещен к доступу к ответу от www.b.com.

CORS разрешает www.b.com предоставлять разрешение JavaScript от www.a.com для доступа к ответу.

Но что конкретно защищено на клиенте в такой модели?

Он останавливает автор www.a.com от чтения данных из www.b.com с помощью браузера пользователя, который посетил оба место и аутентифицированный www.b.com (и, таким образом, имеет доступ к данным, не является общедоступным).

Например, Алиса зарегистрирована в Google. Алиса посещает malicious.example, которая использует XMLHttpRequest для доступа к данным от gmail.com. У Алисы есть учетная запись GMail, поэтому в ответе есть список самых последних писем в ее почтовых ящиках. Такая же политика происхождения предотвращает чтение malicious.example.

Например, успех хакера для внедрения XSS-скрипта на мою страницу, затем он делает запрос AJAX в его домен для хранения пользовательских данных. Таким образом, домен хакеров позволит такой запрос точно.

Исправить. XSS - это другая проблема безопасности, которая должна быть устранена в источнике (т. Е. В www.a.com, а не в браузере).

5

В дополнение к @Quentin's excellent answer существует еще одна технология, известная как Content Security Policy, которая описывает, что вы после.

Я думал, что www.a.com должен решить, к каким доменам разрешить запрос. Поэтому теоретически в заголовке Access-Control-Allow-Origin я хотел бы поместить весь список доменов, разрешенных для запросов AJAX CORS.

С ПСОМ, вы можете установить заголовок из вашего домена (www.a.com в вашем примере), чтобы ограничить AJAX запросы:

подключающихся-Src ограничивает происхождение, к которому можно подключить (через XHR, WebSockets , и EventSource).

Так, чтобы использовать это, вы можете добавить этот заголовок Content-Security-Policy HTTP на ваш HTML ответ:

Content-Security-Policy: connect-src 'self' 

Это ограничит AJAX запросы www.a.com если заголовок в ответе www.a.com:

«self» соответствует текущему происхождению, но не его поддоменам

See here для поддерживаемых браузеров.

Смежные вопросы