Последствия для безопасности добавления всех доменов в CORS (Access-Control-Allow-Origin: *)

Говорят, что вместо добавления всех доменов в CORS нужно добавить только набор доменов. Тем не менее иногда нет тривиального добавления набора доменов. Например. если я хочу публично выставлять API, то для каждого домена, который хочет сделать вызов этого API, мне нужно будет связаться с ним, чтобы добавить этот домен в список разрешенных доменов.

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

Единственными проблемами безопасности, которые я вижу, являются DoS-атаки и CSRF атак. Атаки CSRF уже могут быть достигнуты с помощью элементов IMG и элементов FORM. Атаки DoS, связанные с CORS, можно преодолеть, заблокировав запросы в заголовке referrer.

Мне не хватает последствий для безопасности?

=== Изменить ===

Предполагается, что заголовок Access-Control-Allow-Credentials не установлен
Я знаю, как добавить данный список доменов "CORS access", и поэтому меня интересуют только последствия безопасности для добавления всех доменов "доступ CORS".

Ответ 1

За исключением csauve один, ни один из ответов не отвечает на мой первоначальный вопрос.

Чтобы ответить на мой вопрос; Похоже, что пока Access-Control-Allow-Credentials не установлен, проблема безопасности не возникает.

(что заставляет меня задаться вопросом, почему спецификация требует предполета, когда Access-Control-Allow-Credentials не установлен?)

Ответ 2

Абоненты поддельных запросов Forgery являются далекими и первоочередными в отношении адресов Access-Control-Allow-Origin.

Райан, безусловно, прав в отношении поиска контента. Тем не менее, по поводу просьбы здесь можно сказать больше. Многие веб-сайты теперь предоставляют веб-службы RESTful, которые предоставляют широкий спектр функций, которые могут включать существенные изменения в бэкэнд. Очень часто эти службы RESTful предназначены для вызова с помощью запроса XHR (например, AJAX) (возможно, с помощью Single page Application" в качестве интерфейса). Если у пользователя есть активный сеанс, предоставляющий доступ к этим службам при посещении злоумышленного стороннего сайта, этот сайт может попытаться вызвать эти конечные точки REST за кулисами, передав значения, которые могут нанести ущерб пользователю или сайту. В зависимости от того, как определены службы REST, существуют различные способы защиты от этого.

В конкретном случае веб-служб REST для приложения с одной страницей вы можете диктовать, что все запросы к конечным точкам REST-сервера выполняются с помощью XHR и отказываются от любого запроса, отличного от XHR. Вы можете диктовать это, проверяя наличие пользовательского заголовка запроса (что-то вроде jQuery X-Requested-With). Только запросы XHR-типа могут устанавливать эти заголовки; простые запросы GET и POST из форм и встроенных ресурсов не могут. Наконец, причина, по которой мы хотим диктовать XHR-запросы, возвращает нас к исходному вопросу - запросы XHR подчиняются правилам CORS.

Если вы разрешили Access-Control-Allow-Origin: *, то любой сайт мог бы сделать любой запрос AJAX от имени пользователя конечным точкам REST. Если конечные точки REST включают в себя какие-либо конфиденциальные данные или позволяют сохранять данные, это неприемлемая уязвимость системы безопасности. Вместо этого применяйте запросы XHR-only, как описано мной, и определяйте белый список источников, разрешенных для выполнения этих запросов.

Стоит отметить, что если конечные точки REST не раскрывают какую-либо конфиденциальную информацию или если они не позволяют пользователю делать какие-либо постоянные изменения данных, то может быть подходящим решением Access-Control-Allow-Origin: *, Карты Google, например, предоставляют просмотр только для чтения в общедоступных данных карты; нет оснований ограничивать сторонние сайты, которые могут захотеть использовать эти службы.

Ответ 3

Вы можете отправить более одного, например:

Access-Control-Allow-Origin: http://my.domain.com https://my.domain.com http://my.otherdomain.com

но я бы посоветовал это сделать. Вместо этого сохраните белый список разрешенных доменов. Допустим:

allowed = [ "X", "Y", "A.Z" ];

Затем, если вы получите запрос от X, вы ответите:

Access-Control-Allow-Origin: X

Если вы получите запрос от A.Z, вы ответите:

Access-Control-Allow-Origin: A.Z

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

Все запросы XHR отправят заголовок Origin, поэтому используйте это. И вам нужно только отправить заголовки политики CORS для запроса OPTIONS, а не следующий запрос GET/POST/HEAD.

Основная проблема, которую я вижу, заключается в том, что вы раскрываете все свои домены. Возможно, у вас есть безопасный домен администратора, например: https://admin.mydomain.com, или, возможно, у вас есть веб-сайт продукта, который еще не готов к запуску. Вы не хотите включать что-либо, что не является абсолютно необходимым для запроса.

И * просто предельно ленив.

Ответ 4

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

Если вы не установили Access-Control-Allow-Credentials, и вы используете аутентификацию без cookie (т.е. вызывающий абонент отправляет заголовок авторизации на предъявителя), вам не нужно указывать источники белого списка. Просто откликните начало координат в Access-Control-Allow-Origin.

Хорошо структурированный REST API можно безопасно называть из любого источника.

Ответ 5

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

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

Пример:

Представьте, что ваша спина позволяет CORS для всех доменов. Теперь я создаю веб-сайт, который делает запрос на вашimaginarybank.com/balance

Запрос IMG ничего не сделает, потому что мой javascript не может получить то, что было в html этой страницы на вашем веб-сайте банка. Теперь, когда они включили CORS, javascript на моем сайте фактически возвращает HTML-страницу с вашим балансом на ней и сохраняет ее на моем сервере. Я не только могу сделать запрос GET, как раньше, но теперь я могу видеть, что внутри. Это огромная проблема безопасности.

Как решить проблему без добавления большого списка в заголовки? Каждый запрос CORS выполняется с заголовком Origin. Лучшим решением, вероятно, является чтение заголовка Origin, а затем запрос базы данных, чтобы увидеть, если он включен в белый список, как предложил Фриц в его ответе.

Ответ 6

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

Afaik, в этот заголовок даже нельзя добавить несколько доменов. Таким образом, это либо *, либо один конкретный домен, и я всегда предпочел бы не добавлять *