reactjsを使用してjStorageをlocalStorageに保存しても安全ですか？

現在、reactjsを使用して単一ページアプリケーションを構築しています。localStorageを使用しない理由の多くはXSSの脆弱性によるものだと私は読んだ。Reactはすべてのユーザー入力をエスケープするので、localStorageを使用しても安全ですか？

最近のほとんどの単一ページアプリケーションでは、実際にトークンをクライアント側のどこかに保存する必要があります（最も一般的な使用例-ページの更新後もユーザーをログイン状態に保つため）。

利用可能なオプションは、Webストレージ（セッションストレージ、ローカルストレージ）とクライアント側Cookieの合計2つです。両方のオプションが広く使用されていますが、これはそれらが非常に安全であることを意味しません。

Tom AbbottはJWT sessionStorageおよびlocalStorageセキュリティをうまくまとめています。

Webストレージ（localStorage / sessionStorage）は、同じドメインのJavaScriptを介してアクセスできます。つまり、サイトで実行されているすべてのJavaScriptがWebストレージにアクセスできるため、クロスサイトスクリプティング（XSS）攻撃に対して脆弱になる可能性があります。簡単に言うと、XSSは一種の脆弱性であり、攻撃者がページで実行するJavaScriptを挿入する可能性があります。基本的なXSS攻撃は、フォーム入力を介してJavaScriptを挿入しようとします。攻撃者はフォームに入力<script>alert('You are Hacked');</script>して、ブラウザによって実行され、他のユーザーが表示できるかどうかを確認します。

XSSを防ぐための一般的な応答は、すべての信頼できないデータをエスケープしてエンコードすることです。React（たいてい）はあなたのためにそれをします！ここでは、ReactがXSS脆弱性保護のどれほどの責任を負うかについての素晴らしい議論を示します。

ただし、すべての脆弱性を網羅しているわけではありません。もう1つの潜在的な脅威は、CDNまたは外部インフラストラクチャでホストされているJavaScriptの使用です。

これがトムです。

最新のウェブアプリには、A / Bテスト、目標到達プロセス/市場分析、広告用のサードパーティJavaScriptライブラリが含まれています。Bowerなどのパッケージマネージャーを使用して、他の人のコードをアプリにインポートします。

使用しているスクリプトの1つだけが侵害された場合はどうなりますか？悪意のあるJavaScriptがページに埋め込まれる可能性があり、Webストレージが危険にさらされます。これらのタイプのXSS攻撃は、知らないうちにサイトにアクセスする全員のWebストレージを取得する可能性があります。これがおそらく、多くの組織が価値のあるものを保存したり、Webストレージに情報を信頼したりしないことを勧める理由です。これには、セッション識別子とトークンが含まれます。

したがって、私の結論は、ストレージメカニズムとして、Web Storage は転送中に安全な標準を適用しないということです。Web Storageを読んでそれを使用するユーザーは、JWTを常にHTTPS経由で送信し、HTTP経由では送信しないようにするために十分な注意を払う必要があります。

これは古い質問ですが、@ mikejones1477によると、最新のフロントエンドライブラリとフレームワークはテキストをエスケープしてXSSから保護しています。cookieが資格情報を使用した安全な方法ではない理由は、localStorageが行うときにcookieがCSRFを妨げないためです（cookiesはjavascriptからもアクセスできるため、XSSはここでは大きな問題ではないことを忘れないでください）。この回答が理由を再開します。

認証トークンをローカルストレージに格納し、それを各リクエストに手動で追加することがCSRFから保護される理由は、そのキーワードである手動です。ブラウザはその認証トークンを自動的に送信しないため、evil.comにアクセスしてPOST http://example.com/delete-my-accountを送信できた場合、認証トークンを送信できません。要求は無視されます。

もちろんhttpOnlyは聖杯ですが、reactivejsやjsフレームワークからはアクセスできません。私の推奨はlocalstorageです。または、cookieを使用したい場合は、djangoのようにCSRFの問題に何らかの解決策を実装するようにしてください。

CDNに関しては、たとえばgoogleやbootstrapの提供のようなCDNなどの奇妙なCDNを使用していないことを確認し、コミュニティによって管理され、悪意のあるコードが含まれていないことを確認してください。わからない場合は、自由に確認できます。

基本的に、JWTをlocalStorageに保存しても問題ありません。

これは良い方法だと思います。XSSについて話している場合、CDNを使用するXSSは、クライアントのログイン/パスも取得する潜在的なリスクでもあります。ローカルストレージにデータを保存すると、少なくともCSRF攻撃を防ぐことができます。

両方を認識し、必要なものを選択する必要があります。両方の攻撃は、注意する必要があるすべてのものではありません。覚えておいてください。アプリ全体は、アプリの最も安全なポイントと同じくらい安全です。

もう一度保存しても問題ありませんが、XSS、CSRFなどの脆弱性はありません

CDNを使用する場合は安全ではありません。

悪意のあるJavaScriptがページに埋め込まれる可能性があり、Webストレージが危険にさらされます。これらのタイプのXSS攻撃は、知らないうちにサイトにアクセスする全員のWebストレージを取得する可能性があります。これがおそらく、多くの組織が価値のあるものを保存したり、Webストレージに情報を信頼したりしないことを勧める理由です。これには、セッション識別子とトークンが含まれます。

ストームパス経由

外部から必要なスクリプトはすべて侵害される可能性があり、クライアントのストレージからJWTSを取得し、個人データを攻撃者のサーバーに送り返す可能性があります。

LocalstorageはJavaScriptからアクセスできるように設計されているため、XSS保護は提供されません。他の回答で述べたように、XSS攻撃を実行する方法はたくさんありますが、デフォルトではlocalstorageが保護されていません。

ただし、Cookieには、XSSおよびCSRF攻撃から保護するセキュリティフラグがあります。HttpOnlyフラグは、クライアント側のJavaScriptがCookieにアクセスできないようにします。Secureフラグは、ブラウザーがsslを介してCookieを転送することのみを許可し、SameSiteフラグは、Cookieが確実にオリジンに送信されるようにします。チェックしたところ、SameSiteは現在OperaとChromeでのみサポートされているため、CSRFから保護するには、他の戦略を使用することをお勧めします。たとえば、暗号化されたトークンをいくつかのパブリックユーザーデータと共に別のCookieで送信します。

したがって、Cookieは認証データを格納するためのより安全な選択肢です。

これを調べる方法は、リスクまたは危害のレベルを検討することです。

ユーザーなしのアプリ、POC / MVPを構築していますか？市場に出て、アプリをすばやくテストする必要がある新興企業ですか？もしそうなら、私はおそらく最も単純なソリューションを実装し、製品と市場の適合性を見つけることに焦点を当て続けるでしょう。多くの場合、実装が簡単なlocalStorageを使用します。

日常のアクティブユーザーが多いアプリのv2を構築していますか、それとも、人や企業が大きく依存しているアプリですか。ハッキングされたということは、回復の余地がほとんどないか、まったくないということですか？もしそうなら、私はあなたの依存関係を長く見て、http専用のcookieにトークン情報を保存することを検討します。

localStorageとcookie / sessionストレージの両方を使用することには、それぞれ長所と短所があります。

最初の回答で述べたように、アプリケーションにXSSの脆弱性がある場合、どちらもユーザーを保護しません。最近のほとんどのアプリケーションには12以上の異なる依存関係があるため、アプリケーションの依存関係の1つにXSSの脆弱性がないことを保証することがますます困難になります。

アプリケーションにXSSの脆弱性があり、ハッカーがそれを悪用できる場合、ハッカーはユーザーに代わってアクションを実行できます。ハッカーはlocalStorageからトークンを取得してGET / POSTリクエストを実行したり、トークンがhttp専用のcookieに保存されている場合はPOSTリクエストを実行したりできます。

トークンをローカルストレージに保存することの唯一の欠点は、ハッカーがトークンを読み取ることができることです。

localStorageもhttpOnly Cookieも受け入れられませんか？侵害されたサードパーティのライブラリに関して、機密情報の盗難を削減または防止することがわかっている唯一のソリューションは、サブリソースの整合性を強化することです。

サブリソース整合性（SRI）は、ブラウザーがフェッチするリソース（CDNなどから）が予期しない操作なしで配信されていることをブラウザーが確認できるようにするセキュリティ機能です。これは、フェッチしたリソースが一致しなければならない暗号化ハッシュを提供できるようにすることで機能します。

侵害されたサードパーティのライブラリがWebサイトでアクティブである限り、キーロガーはユーザー名、パスワードなど、サイトに入力したその他の情報の収集を開始できます。

httpOnly Cookieは別のコンピューターからのアクセスを防ぎますが、ハッカーがユーザーのコンピューターを操作するのを防ぐことはできません。

トークンを暗号化する限り、トークンをlocalStorageに保存しても安全です。以下は、多くの方法の1つを示す圧縮コードスニペットです。

    import SimpleCrypto from 'simple-crypto-js';

    const saveToken = (token = '') => {
          const encryptInit = new SimpleCrypto('PRIVATE_KEY_STORED_IN_ENV_FILE');
          const encryptedToken = encryptInit.encrypt(token);

          localStorage.setItem('token', encryptedToken);
     }

次に、トークンを使用する前に、 PRIVATE_KEY_STORED_IN_ENV_FILE