Laravel, похоже, использует 2 разных шаблона для CSRF-атак.
Первый: Laravel сохраняет токен в сеансе сервера с именем _token и обновляет его для каждого запроса. Затем поместите {{ csrf_field() }} в форму, чтобы при отправке формы она передавала скрытое входное значение, содержащее токен csrf, обратно на сервер, чтобы проверить, соответствует ли оно значению _token, сохраненному в сеансе. Это шаблон токена синхронизатора.
Но меня беспокоит второе. Laravel использует шаблон Double Submit Cook ie для вызовов AJAX. Laravel хранит повар ie с именем XSRF-TOKEN на стороне клиента вместе с зашифрованным идентификатором session_id cook ie. Клиентское приложение прочитает это XSRF-Token cook ie, чтобы настроить заголовок запроса X-XSRF-TOKEN, и поместит значение cook ie в этот заголовок. Поэтому Laravel будет только проверять, соответствует ли XSRF-Token cook ie значение X-XSRF-TOKEN заголовка запроса или нет.
Это проблема. Почему Laravel не привело к тому, что значение XSRF-Token cook ie и значение заголовка X-XSRF-TOKEN были такими же, как _token в сеансе? Если Laravel слепо доверяет клиенту cook ie и заголовку запроса, что произойдет, если атакуемый владеет поддоменом и перезапишет XSRF-TOKEN cook ie и подделает запрос?
Как Laravel может защитить себя от атаки на поддомене ie, если он использует шаблон Double Submit Cook ie для своего AJAX call?