Авторизация JWT в файлах cookie с сервером без сохранения состояния и без рендеринга на стороне сервера

Question

Я пытаюсь реализовать jwt в файлах cookie для аутентификации на одностраничном интерфейсе приложения, который взаимодействует с различными узлами микросервисов, работающих под управлением Express.

Я делаю это, так как хранение jwt в sessionstorage делает приложение уязвимым для XSS.

Однако при использовании файлов cookie API теперь уязвимы для атак csrf.

Традиционно атаки csrf смягчаются созданием токена csrf, сохранением его в сеансе сервера, а затем отображением в скрытом поле формы. Затем при отправке формы значение токена csrf сверяется со значением сеанса сервера, чтобы проверить, совпадают ли они.

Я не могу использовать этот подход как: - серверы не имеют состояния - нет рендеринга на стороне сервера.

Так что я не понимаю, какой метод csrf мне следует использовать. Я прочитал о двойном методе отправки, когда вы отправляете токен csrf при каждом запросе ajax и сохраняете одинаковое значение в cookie, а затем сервер проверяет оба на совпадение.

Тем не менее, я не могу вначале получить токен csrf в html, поскольку нет рендеринга на стороне сервера.

Какова наилучшая практика для достижения jwt в файлах cookie с защитой csrf в архитектуре без сохранения состояния без рендеринга на стороне сервера?

Answer 1

Просто не храните токен JWT в файле cookie

CSRF-атаки возможны, потому что браузеры будут отправлять куки с HTTP-запросами, даже если они инициированы скриптом, запущенным на стороннем сайте. Таким образом, evilsite.com может отправить DELETE http://yoursite.com/items/1 запрос на вашему веб-сервису . Эта конечная точка требует, чтобы вы вошли в систему, но поскольку браузер будет отправлять любые файлы cookie, сохраненные для yoursite.com, если аутентификация основана на файлах cookie, то evilsite.com может добавить обратно ваш метод аутентификации и вызвать методы аутентификации, которые ваш пользователь не намеревался позвонить от их имени.

Однако аутентификация не обязательно должна основываться на cookie. Если вы создаете клиентское приложение JavaScript, то просто отправить маркер аутентификации в виде заголовка HTTP, а не в виде файла cookie. Если вы сделаете это, то evilsite.com не сможет использовать ваш токен (они могут использовать только токены, хранящиеся в файлах cookie), и у вас никогда не возникнет проблема.