サービスワーカーのベストプラクティスパターンbackground-sync with CSRF protection

Question

CSRF保護を確実にするために、ページに埋め込まれた1回のトークンを使用する要求があります。攻撃者がユーザーに不正なリクエストをしてもらう可能性があります彼らは、トークンを取得することはできません、そして、彼らはそれが各リクエストで変更されたり、期限切れになることができる場合であっても。

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

私はサービスワーカーとバックグラウンドシンクを実装したいので、ユーザーはデータをオフラインで投稿し、後でそのデータを送信することができます。

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

これはどのプログレッシブウェブサイトでも一般的な問題であるようですが、それを処理するベストプラクティスは何ですか？

バックグラウンドシンクは新しいトークンを要求し、送信して送信するデータに適用し、それでもCSRF攻撃者が利用できなかったループになると思いますが、それは確かではありません。誰でもこれをどちらの方法でも確認できますか？

私が欠けていることをサービス従事者やバックグラウンド同期のいくつかの機能はありますか？

Answer 1

私はCSRFの主題について「ベストプラクティス」について話す資格はありませんが、OWASP guidelines on CSRFのあなたの考えは正しいと思います。

現在、私は同様の方法でOAuthを使用しています。個々のクライアントには、リフレッシュとベアラトークンが発行されます。リフレッシュトークンは、ベアラトークンよりもかなり長い存続期間を有する。クライアントは、リフレッシュトークンを使用して新しいベアラトークンを作成することもできます。一部のクライアントは、すべての要求に対して新しいベアラを「フルローテーション」することを選択することがあります。障害を報告するまでベアラを使用してから新しいものを作成する人もいます。

あなたのバックグラウンドシンクでは、リフレッシュトークンとベアラトークンの両方が要求され、受信されます。これは、先に行くと、その後、手持ちのベアラトークンでURLを構築する試みが失敗した場合に同期する際に、ミントに新しいベアラをリフレッシュトークンを使用して、新しいベアラにURLを再構築することができます。リフレッシュの有効期限が切れている（または無効にされて）場合はもちろん、あなたはオフライン長すぎると、あなたはREAUTHする必要があります。応答のための