Что именно делает заголовок Access-Control-Allow-Credentials?


167

Я пытаюсь понять, как использовать CORS, и я не совсем понимаю, что Access-Control-Allow-Credentialsделает заголовок.

В документации сказано

Указывает, может ли быть предоставлен ответ на запрос, если флаг учетных данных имеет значение true.

Но я не понимаю, что означает «разоблачение» ответа.

Кто-нибудь может объяснить, что на самом деле делает этот заголовок, установленный в true (в сочетании с флагом credentials, установленным в true)?


xhr.withCredential документ на стороне клиента developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/...
Weishi Zeng

Ответы:


265

По умолчанию CORS не включает файлы cookie в запросах разных источников. Это отличается от других методов перекрестного происхождения, таких как JSON-P. JSON-P всегда включает файлы cookie с запросом, и это может привести к классу уязвимостей, называемому подделкой межсайтовых запросов или CSRF.

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

Код клиента должен установить withCredentialsсвойство на XMLHttpRequestдля trueтого, чтобы дать разрешение.

Однако одного этого заголовка недостаточно. Сервер должен ответить Access-Control-Allow-Credentialsзаголовком. Ответ с этим заголовком trueозначает, что сервер разрешает использование файлов cookie (или других учетных данных пользователя) в запросах разных источников.

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

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


1
Я уточнил ответ, чтобы покрыть ваш вопрос. В основном JSON-P делает это неправильно и менее безопасен.
Монсур

28
Просто хочу добавить к этому немного, чтобы прокомментировать значение слова «выставлено». Спецификация не требует предварительной проверки (дополнительная информация туда и обратно, чтобы проверить, разрешит ли сервер учетные данные) для запросов GET. Вместо withCredentialsпредварительной проверки браузер просто всегда делает запрос, отправляя файлы cookie, если он установлен, но затем, когда он получает ответ, если было установлено значение withCredentials, он только доставит / предоставит результат вызывающему javascript, если ответ имеет доступ -Control-Allow-Credentials set header. Если заголовок отсутствует, он не раскрывает ответ, эффективно скрывая его.
heavyi5ide

4
@ heavyi5ide, да, даже если браузер не отображает ответ на код клиента, запрос с cookie все равно был отправлен (для запросов без предварительной проверки). Так что CSRF все равно будет сделано.
Pacerier

7
Поскольку это очень популярный ответ, я собираюсь добавить еще одну важную информацию: помимо правильной настройки заголовков запросов и ответов, вам также необходимо убедиться, что ваш браузер не блокирует сторонние файлы cookie, если вы хотите, чтобы кросс-исходные учетные запросы работали. См stackoverflow.com/a/16634887/2970321
alexw

5
Это такой четкий ответ, что любой, кто читает его в первый раз, может понять и исправить свой код, который, кажется, не очень хорошо работает с файлами cookie. Спасибо!
спрашивает
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.