Пропустить проверку XSRF-TOKEN для запросов CORS? - PullRequest
0 голосов
/ 29 мая 2019

Общая схема защиты от подделки межсайтовых запросов (CSRF или XSRF) такова:

  1. Клиент отправляет (GET) запрос на сервер.
  2. Сервер включает в себя (не только для http!) Cookie XSRF-TOKEN с криптографически безопасным токеном, идентифицирующим сеанс браузера. Это отправляется дополнительно в обычный файл cookie сеанса, например, JSESSIONID, который доступен только для http.
  3. Клиенты возвращают токен во все последующие неидемпотентные запросы в заголовке "X-XSRF-TOKEN".
  4. Сервер принимает эти запросы, только если токен, прочитанный из заголовка X-XSRF-TOKEN, совпадает с токеном, связанным с сеансом.

Если, однако, запрос отправляется из одного источника в другой после CORS, это невозможно, поскольку клиент (JavaScript) не может получить значение cookie из шага 2, поскольку XMLHttp​Request​.get​AllResponse​Headers() отфильтровывает заголовки «Set-Cookie» ( и "Set-Cookie2").

Правильно ли я понимаю CSRF & CORS с AngularJS + Laravel , что сервер должен вообще пропустить проверку токенов для запросов CORS?

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

Редактировать: Если отключение защиты csrf для запросов CORS является правильным решением, отправляет ли Access-Control-Allow-Origin: * угрозу безопасности? Другими словами, должен ли разрешенный источник всегда быть в белом списке?

Кстати, запросы аутентифицируются с идентификатором сеанса.

...