service-worker - CSRF 保護を使用した Service Worker バックグラウンド同期のベスト プラクティス パターン

Question

CSRF 保護を確保するために、ページに埋め込まれたワンタイム トークンを使用するリクエストがあります。要求ごとに変更され、有効期限が切れる可能性があります。

これまでのところ、とても安全です。

Service Worker とのバックグラウンド同期を実装して、ユーザーがデータをオフラインで投稿し、後で接続を取得したときにそのデータを送信できるようにしたいと考えています。

ただし、これは、CSRF トークンを取得するためにページを使用できないことを意味し、ユーザーがリクエストを作成したときにリクエストにリンクされたトークンは、データが実際に送信されるまでに無効になる可能性があります。

これはプログレッシブ Web サイトの一般的な問題のように思われますが、これを処理するためのベスト プラクティスは何ですか?

バックグラウンド同期は新しいトークンを要求し、それを送信するデータに適用してから送信する可能性があると思いますが、それでもCSRF攻撃者が利用できないループですが、それについては確信が持てません. 誰でもこれを確認できますか？

Service Worker やバックグラウンド同期で不足している機能はありますか?

Answer 1

私は CSRF に関する「ベスト プラクティス」について話す資格はありませんが、CSRFに関する OWASP ガイドラインを理解していることから、あなたの考えは正しいです。

現在、私は同様の方法で OAuth を使用しています。個々のクライアントには更新とベアラー トークンが発行されます。リフレッシュ トークンの有効期間は、ベアラー トークンよりも大幅に長くなります。クライアントは、リフレッシュ トークンを使用して、必要に応じて新しいベアラー トークンを作成することを選択できます。一部のクライアントは、リクエストごとに新しいベアラーである「フルローテーション」を選択する場合があります。失敗が報告されるまでベアラーを使用し、その後新しいベアラーを作成することを選択する人もいます。

あなたのシナリオでは、バックグラウンド同期は更新トークンとベアラー トークンの両方を要求して受け取ります。先に進み、手元のベアラー トークンを使用して URL を構築し、同期の試行が失敗した場合は、更新トークンを使用して新しいベアラーを作成し、新しいベアラーで URL を再構築します。もちろん、更新の有効期限が切れている (または取り消されている) 場合は、オフライン状態が長すぎたため、再認証する必要があります。