Лучшая практика для рабочего фона для синхронизации рабочего стола с защитой CSRF

Question

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

До сих пор так надежно.

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

Однако это означает, что страница недоступна для получения токена CSRF, и любой токен, связанный с запросом при его создании, может быть недействительным к моменту фактического отправки данных.

Это может показаться общей проблемой с любым прогрессивным веб-сайтом, какова наилучшая практика для его обработки?

Я думаю, что синхронизация фона может запросить новый токен, применить его к данным для отправки, а затем отправить их, и это все равно будет цикл, который злоумышленник CSRF не смог бы использовать, но я не уверен в этом. Может ли кто-нибудь подтвердить это в любом случае?

Есть ли какая-то особенность сервисных работников или фоновая синхронизация, которые мне не хватает?

Answer 1

Я не имею права говорить за «лучшие практики» по теме CSRF, но из моего понимания OWASP guidelines on CSRF ваше мышление верное.

В настоящее время я использую OAuth аналогичным образом: отдельным клиентам выдается обновление и токен-носитель. Токен обновления имеет срок службы значительно дольше, чем токен-носитель. Клиент может выбрать чеканить новые токены-носители, как они считают нужным, используя токен обновления. Некоторые клиенты могут выбрать «полный поворот», новый носитель по каждому запросу. Некоторые могут использовать носитель до тех пор, пока он не сообщит о сбое, а затем отделите новый.

В вашем сценарии ваша синхронизация фона запрашивает и получает как токены обновления, так и токены. Он может идти вперед и строить URL-адрес с токеном-носителем на руках, а затем при синхронизации при попытке выполнить попытку использовать токен обновления, чтобы отличить новый носитель и перестроить URL-адрес с новым каналом. Конечно, если обновление истекло (или было отменено), вы слишком долго не были в автономном режиме, и вам нужно перезапустить.