7

WebView キャッシュに書き込まれたすべてのデータを暗号化できる方法を探しています。非推奨になったため、CacheManager の使用を避けようとしています。私の現在の戦略は、キャッシュへの書き込みの試みをすべてキャッチし、データを書き込む直前にデータを暗号化し、キャッシュからのデータに対するすべてのリクエストをキャッチして、要求されたデータを返す前にデータを復号化できるようにすることです。

4

2 に答える 2

5

すべてのデータを暗号化することは可能だと思います。ただし、使用後にデータを消去することは、おそらくより良い実践とセキュリティです。CacheManager は非推奨であるため、使用しないでください。

Android のセキュリティ設計では、キャッシュをクリアすることを推奨しています。

アプリケーションが WebView を使用して機密データにアクセスする場合は、clearCache() メソッドを使用して、ローカルに保存されているファイルを削除することをお勧めします。no-cache などのサーバー側ヘッダーを使用して、アプリケーションが特定のコンテンツをキャッシュしてはならないことを示すこともできます。

ここから: http://developer.android.com/guide/practices/security.html

ただし、データを暗号化したい場合は、手動で行う必要があります。そのため、Android がキャッシュを保存するディレクトリに移動し、自分で暗号化する必要があります。達成しようとしていることに応じて、これを行うにはさまざまな方法があります。いつ、どのようにそれを行うかはあなた次第です。

あなたがウェブブラウザアプリケーションを作ろうとしているなら、私の頭の上から。これを行う最善の方法は、ここにある CookieStore または CookieManager クラスのラッパー クラスを作成することです。

http://developer.android.com/reference/java/net/package-summary.html

これが役立つことを願っています

于 2012-10-02T20:31:36.653 に答える
0

現在、WebView キャッシュを暗号化できるソリューションに取り組んでいます。あなたの考えによると、私はいくつかの可能な解決策をブレインストーミングしています...

私が今直面しているいくつかの可能な(または不可能な)解決策:

1. libchromeXX.so の GoT フック読み書き

プロ

  • キャッシュを決定論的に暗号化および復号化します。ディスク上に暗号化されていないデータはありません。

短所

  • 非常に危険です (フィールドで発生する可能性のあるアーキテクチャ/デバイス固有の問題、可能性のある Android バージョン固有の問題、可能性のある WebView 実装固有の問題)

2. inotify で fs の変更をリッスンし、jit を暗号化します (ジャスト イン タイム)。次回のアプリ起動時に復号化

プロ

  • 「パブリック」API のみ

短所

  • 一部の Android デバイスは「inotify」をサポートしていない可能性があります
  • 実行時にデータを操作できます (ルート/システム uid のみを使用してください。攻撃者がこの権限を持っている場合、とにかくプロセスに何かをフックする可能性があります)。

3.すべてのデータまたは最終変更日/サイズの組み合わせに対してハッシュを作成し、個別に保存します

プロ

  • 「パブリック」API のみ
  • たぶん暗号化より速い

短所

  • データが操作されたかどうかのみを検証します
  • ダイジェストはどこかに保存する必要がありますか?

4. 何らかの方法で ETag メカニズムを使用してデータを検証する

これは今のところそれほど深く調査していませんが、ETag が特定のリソースのハッシュを表している可能性があり、ハッシュがサーバー提供のダイジェストと一致するかどうかを検証する可能性があります。キャッシュを反復処理して ETag とリソースのペアを検索する必要がありますか、それともすぐに使用できるブラウザー機能がありますか? 私はそうではないと思います:(

プロ

  • ブラウザーがサポートしている場合、検証はすぐに使用できる可能性があります

短所

  • ETag が機能していないか、意図した使用法ではない可能性があります

キャッシュされたリソースの整合性を検証するメカニズムはありませんか?

于 2020-06-16T14:51:27.177 に答える