web-dev-qa-db-ja.com

HTML5 sessionStorageは、暗号化キーを一時的に保存するのに安全ですか？

ローカルでデータベースを暗号化するために、HTML5でローカルWebアプリケーション（ブラウザ拡張など）を構築していると仮定します。データベースへのアクセスはパスワードによって制御され、暗号マスターキーはPBKDFを使用してパスワードから導出されます。必要に応じてレコードを暗号化および復号化できるように、アプリケーションの使用中にのみ派生マスターキーをメモリに保存したいと思います。

この目的で sessionStorage を使用することを検討しました。利点は、キーがメモリにのみ存在し、現在のブラウザタブで使用できることです。そのタブまたはブラウザが閉じている場合は、キーを削除する必要があります。利点は、ブラウザーのタブを更新する必要がある場合でも、アクティブなセッションとマスターキーが残っていることです。それ以外の場合は、更新するたびにパスワードを再入力する必要があります。ただし、単一ページのアプリであるため、更新が行われることはまれです。

W3CでのsessionStorage仕様の読み取りには、いくつかの懸念があります。

ユーザーエージェントは再起動後のセッションの再開をサポートしている場合があるため、ブラウジングコンテキストの存続期間は、実際のユーザーエージェントプロセス自体の存続期間と無関係である可能性があります。

これはOSの再起動またはブラウザの再起動について話しているのですか？

私が絶対に避けたいのは、暗号化キーをディスクに書き込むことです。上記の引用は、sessionStorageのキーがクラッシュリカバリ/再起動プロセスの一部としてディスクに保存される可能性があることを示していますか？または、この再起動プロセスは通常、メモリのみで処理されますか？

a）Tier 1オープンソースブラウザー（Firefox、Chromium）がsessionStorageを処理する方法、およびコンテンツをディスクに書き込むことができるかどうかについて、誰かが知識を持っていますか？ 、ブラウザがクラッシュした場合でも一時的に？

b）ブラウザーのクラッシュまたは再起動でディスクへのキーのリークを防ぐための緩和策はありますか？いずれかがあります about:configブラウザのクラッシュ後に セッションリカバリを無効にする に使用できる設定？

c）keyの保存にsessionStorageをまったく使用しないのが最も安全なオプションですか？または、フルディスク暗号化を使用してリスクを軽減することもできますか？

ご協力いただきありがとうございます。

cryptographykey-managementsession-managementhtml-5
8
sesses

要するに;ブラウザが再起動します。ただし、すべてのブラウザーがW3Cによって定義された仕様を同じ方法で実装するわけではありません。

a）Tier 1オープンソースブラウザー（Firefox、Chromium）がsessionStorageを処理する方法、およびブラウザーがクラッシュした場合でも一時的にコンテンツをディスクに書き込むことができるかどうかについて、知識はありますか？

当時、sessionStorageにあるデータの保存については触れていません。確実に知るには、各ブラウザの実装を調査する必要があります。

Mozillaのドキュメント を参照してください。この機能をsqliteデータベースに移行するための bug/feature request もあります。

b）ブラウザのクラッシュまたは再起動でディスクへのキーの漏洩を防ぐための緩和策はありますか？ブラウザがクラッシュした後のセッション回復を無効にするために使用できるabout：config設定はありますか？

各ブラウザの拡張機能APIは異なりますが、各はエラー処理を実装する必要がありますだけでなく、クラッシュ発生時のイベントトリガーも実装します。

たとえば Google Chromeのドキュメント は W3C Progress Events標準に準拠していないcrashイベントトリガーを使用しています） RFCドキュメント。

c）セッションストレージをキーの保存にまったく使用しないのが最も安全なオプションですか？または、フルディスク暗号化を使用してリスクを軽減することもできますか？

派生キーを保存する必要はありません。セッション中にレコードが復号化されてDOMに書き込まれると、キーは、暗号化が行われるセッションが終了するまで存続する必要があります。 sessionStorageの使用は、タブ/ブラウザが開いている間のみDOM内のデータを維持するのに適しているため、「セッション」という名前です。

そうは言っても、本当にセーフガードが必要で、完全なディスク暗号化が問題を軽減すると感じる場合は、次のシナリオを検討してください。

  1. フルディスク暗号化マシンのブートパーティションにアクセスすると、initramfs（linuxインストール）を変更して、ディスク暗号化に使用される入力提供キーをキャプチャする方法が可能になります。
  2. TLSなどの暗号化されたプロトコルでラップされていない場合、クライアントアプリケーションにWebアプリケーションを送信するために使用されるトランスポートは、キーボード入力をキャプチャできる悪意のあるコードの注入を可能にする可能性があります。 BeEF インジェクションツールキットを参照してください。

私はこのツールを書きました。 secStore.js 。それはあなたが達成について話していることをします。トランスポート層を暗号化されたトンネルでラップしていることを確認してください セキュリティヘッダー を使用してXSSの試行を軽減し、 ロードされたブラウザープラグイン/拡張機能 をクエリして、悪意のあるエクスプロイトを防止することもできますその道。

お役に立てば幸いです。セキュリティを備えたものはすべて階層化する必要があり、監視が役立つあらゆる攻撃ベクトルをカバーすることはほとんど不可能です。

7
jas-

どうやら、タブを閉じるときにsessionStorageが実際にはクリアされないようです。 「閉じたタブを開く」をクリックすることで簡単に復活

詳細については、こちらをご覧ください： http://blog.guya.net/2015/08/25/the-never-ending-browser-sessions/

4
guya