ローカルストレージを安全と見なすことはできますか？
長期間オフラインで機能するWebアプリケーションを開発する必要があります。これを実行可能にするために、ローカルストレージに機密データ（個人データですが、ハッシュのみを格納するデータの種類ではありません）を保存することを避けられません。
これは推奨されるプラクティスではないことを受け入れますが、選択の余地がほとんどないため、データを保護するために次のことを行っています。
- スタンフォードjavascript暗号ライブラリとAES-256を使用して、ローカルストレージに入るすべてを暗号化する
- ユーザーパスワードは暗号化キーであり、デバイスには保存されません
- sSLを介して単一の信頼できるサーバーからすべてのコンテンツを（オンラインで）提供する
- owasp antisamyプロジェクトを使用して、サーバー上のローカルストレージに出入りするすべてのデータを検証する
- appcacheのネットワークセクションで、*を使用せず、代わりに信頼されたサーバーとの接続に必要なURIのみをリストします
- 一般に、OWASP XSSチートシートで提案されているガイドラインを適用しようとしています。
私は悪魔がしばしば詳細にあることを高く評価しており、一般的にローカルストレージとJavaScriptベースのセキュリティについて多くの懐疑論があることを知っています。誰もが存在するかどうかについてコメントできます：
- 上記のアプローチの基本的な欠陥？
- そのような欠陥の可能な解決策はありますか？
- html 5アプリケーションが長期間オフラインで機能する必要がある場合にローカルストレージを保護するより良い方法はありますか？
助けてくれてありがとう。
WebCrypto
クライアント側（ブラウザ）のJavaScriptの暗号化に関する懸念については、以下で詳しく説明します。これらの懸念の1つを除き、すべては WebCrypto API には適用されませんが、現在は 合理的に十分にサポートされています です。
オフラインアプリの場合、安全なキーストアを設計および実装する必要があります。
余談：Node.jsを使用している場合は、組み込みの crypto APIを使用します。
ネイティブJavascript暗号化（pre-WebCrypto）
私は、あなたのサイトのlocalStorageを読んでいるコンピュータに物理的にアクセスできる人が主な懸念であり、そのアクセスを防ぐために暗号化が必要だと思います。
誰かが物理的なアクセス権を持っている場合、あなたは他の攻撃にさらされ、読書よりも悪いことになります。これらには、キーロガー、オフラインスクリプト変更、ローカルスクリプトインジェクション、ブラウザキャッシュポイズニング、DNSリダイレクトが含まれます（ただし、これらに限定されません）。これらの攻撃は、マシンが侵害された後にユーザーがマシンを使用する場合にのみ機能します。それでも、このようなシナリオでの物理的なアクセスは、より大きな問題があることを意味します。
したがって、ローカル暗号化が貴重である限られたシナリオは、マシンが盗まれた場合であることを覚えておいてください。
目的の機能を実装するライブラリがあります。 Stanford Javascript Crypto Library 。ただし、固有の弱点があります（@ircmaxellの回答からのリンクで参照）。
- エントロピー/乱数生成の欠如;
- セキュリティで保護されたキーストアの欠如。つまり、ローカルに保存する場合、またはオフラインアクセスを禁止するサーバーに保存する場合は、秘密キーをパスワードで保護する必要があります。
- 安全な消去の欠如;
- タイミング特性の欠如。
これらの弱点はそれぞれ、暗号侵害のカテゴリに対応しています。言い換えれば、あなたは名前で「暗号」を持っているかもしれませんが、それは実際に人が望んでいる厳密さよりかなり下にあるでしょう。
そうは言っても、保険数理上の評価は「Javascript暗号が弱いので、使用しないでください」ほど簡単ではありません。これは保証ではなく、厳密に注意してください。上記の弱点の露出、直面するベクトルの頻度とコスト、および障害発生時の緩和または保険の能力を完全に理解する必要があります。その弱点にも関わらず、技術的な能力が限られている泥棒に対してのみ、あなたの露出を減らすかもしれません。ただし、Javascript暗号化は、その情報を標的にしている断固たる有能な攻撃者に対して価値がないと想定する必要があります。実装に固有の多くの弱点が知られている場合、データを「暗号化された」と呼ぶのは誤解を招くと考える人もいます。つまり、技術的なエクスポージャーをわずかに減らすことはできますが、ディスクロージャーによる財務的エクスポージャーを増やすことができます。もちろん、状況はそれぞれ異なります-そして、金融エクスポージャーへの技術的エクスポージャーを減らす分析は重要です。以下に例を示します： 一部の銀行は弱いパスワードを必要とします 、固有のリスクにもかかわらず、彼らは弱いパスワードからの損失にさらされることは、強力なパスワードをサポートするエンドユーザーのコストより少ないためです。
????最後の段落を読んで「インターネットでブライアンという人がJavascript暗号を使用できると言っている」と思ったら、Javascript暗号を使用しないでください。
質問で説明されているユースケースでは、ユーザーがローカルパーティションまたはホームディレクトリを暗号化し、強力なパスワードを使用する方が理にかなっています。このタイプのセキュリティは、一般に十分にテストされ、広く信頼されており、一般に利用可能です。
さて、ここでの基本的な前提は次のとおりです。いいえ、まだ安全ではありません。
基本的に、JavaScriptでcryptoを実行することはできません： JavaScript Crypto Thought Harmful 。
問題は、ブラウザに暗号コードを確実に取得できないことであり、たとえ可能であっても、JSは安全に実行できるようには設計されていません。そのため、ブラウザーに暗号化コンテナー（Encrypted Media Extensionsが提供するが、DRMの目的で反発される）がなければ、安全に実行することはできません。
「より良い方法」に関しては、今のところありません。唯一の選択肢は、データをプレーンテキストで保存し、最善の結果を期待することです。または、情報をまったく保存しないでください。どちらにしても。
それ、またはそのようなセキュリティが必要な場合、ローカルストレージが必要な場合は、カスタムアプリケーションを作成します...
このトピックの調査として、「Web Cryptography APIを使用したTodoMVCのセキュリティ保護」というタイトルのプレゼンテーションがあります（ video 、 code ）。
Web Cryptography API を使用して、アプリケーションをパスワードで保護し、暗号化にパスワード派生キーを使用することにより、暗号化された仕事リストをlocalStorageに保存します。パスワードを忘れたり紛失したりしても、回復することはできません。 （免責事項-これはPOCであり、本番用ではありません。）
他の回答の状態が示すように、これはまだクライアントコンピューターにインストールされているXSSまたはマルウェアの影響を受けやすくなっています。ただし、データがサーバーに保存され、アプリケーションが使用されている場合、機密データもメモリに格納されます。オフラインサポートが魅力的なユースケースになることをお勧めします。
最終的に、localStorageの暗号化は、おそらくシステムまたはそのバックアップへの読み取り専用アクセス権を持つ攻撃者からデータを保護するだけです。 OWASP Top 10アイテムの詳細な防御を追加します A6-Sensitive Data Exposure で、「このデータのいずれかは長期的に平文で保存されますか？」と答えることができます。正しく。
これは本当に興味深い記事です。ローカルストレージを使用するときにセキュリティを提供するために、JS暗号化の実装を検討しています。これは、デバイスが盗難された（そして正しく実装された）場合にのみ保護を提供することは絶対に明らかです。キーロガーなどに対する保護は提供しません。ただし、キーロガーの脅威は実行プラットフォーム（ブラウザ、ネイティブ）に関係なく、すべてのアプリケーションの問題であるため、これはJSの問題ではありません。最初の回答で参照された記事「JavaScript Crypto考慮有害」について、私は1つの批判があります。 「この問題を解決するにはSSL/TLSを使用できますが、それは高価で複雑です」と表示されます。これは非常に野心的な主張だと思います（おそらく偏っているかもしれません）。はい、SSLにはコストがかかりますが、この問題だけのためにWebベースではなく、複数のOSのネイティブアプリケーションを開発するコストを見ると、SSLのコストは取るに足りません。
私の結論-クライアント側の暗号化コードの場所がありますが、すべてのアプリケーションと同様に、開発者はその制限を認識し、必要に応じて実装し、リスクを軽減する方法があることを確認する必要があります。
どのWebページからもアクセスできません（true）が、chrome（ctl-shift-J）などの開発ツールを介して簡単にアクセスおよび編集できます。したがって、値を保存する前にカスタム暗号化が必要です。
ただし、javascriptを（検証のために）復号化する必要がある場合は、復号化アルゴリズムが公開され、操作できます。
Javascriptには、完全に安全なコンテナーと、jsインタープリターのみが使用できるプライベート変数と関数を適切に実装する機能が必要です。しかし、これはユーザーのセキュリティに違反します-追跡データは免責で使用できるためです。
その結果、javascriptが完全に安全になることはありません。