JWTストレージのセキュリティ問題
サイトのJWTログインメカニズムを作成しています。
JWTの保管方法については、2つの非常に反対の意見があります。ストームパスはクッキーのみで誓うhttponly： https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage Auth0 swear by localStorage： https://auth0.com/blog/cookies-vs-tokens-definitive-guide
最初はAuth0を使用し、次にStormpathを使用しましたが、今ではlocalStorageが最適であると考えています。 localStorageの落とし穴はxss攻撃がJWTをキャプチャできることであり、auth0の落とし穴はcsrf攻撃がcookieを盗むことができることです。
開発者は、ハッカーがCSRFを介してアクセスすることをCookieメソッドに本当に困難にすることができるようですが、不可能ではありません。ただし、開発者がlocalStorageを使用してコードベースを管理し、入力をサニタイズする場合、ハッカーが介入できないようですが、これは間違いですか？
ローカルストレージの主な引数は次のようです。
xSRFから保護するよりもXSSから保護する方が簡単です
そのための議論は、CSRSは理解するのが難しい一方で、XSSはおそらく自動入力衛生によって解決されるということです。
2番目の点は正しい場合とそうでない場合がありますが、ソースの説明によると、CSRFからの完全な保護は比較的簡単です。アプリケーションが落ち着いている場合は、CSRFトークンのすべてのPOSTリクエストをチェックするだけです。*.
一方、XSSはそれほど単純ではありません。入力衛生は解決策ではなく、出力をエンコードすることは解決策です。そして問題は、このエンコーディングがコンテキストに依存することです。たとえば、JavaScriptまたはHTMLコンテキストの場合は、別のエンコーディングが必要です。
一部のフレームワークはテンプレートエンジンに自動エンコーディングを提供しますが、他のフレームワークは提供しません。また、自動エンコードは通常HTMLエンコードのみですが、JavaScriptコンテキストではXSSを考慮しません。さらに、多くの開発者がテンプレートエンジンをスキップしてユーザー入力を直接出力することに加えて、XSSはCSRFよりも防御するのが難しいと主張します。
*これは少し簡略化されており、他に考慮すべき点があります。たとえば、HTMLインジェクションはCSRFトークンをリークする可能性があり、アプリケーションは実際にGETリクエストを使用してサーバーの状態を変更する可能性があります。
結論
XSSはCSRFよりも防御が容易であることに同意しません。これがローカルストレージの主な論点であるため、私はCookieアプローチを採用します。 XSSに小さな緩和策を提供し、関連データがHTTPS経由でのみ送信されるようにするという追加の利点もあります（安全なCookie属性を介して）。
開発者およびペンテスターとしての私の経験では、CSRFに対する保護が組み込まれているWeb開発フレームワークを使用する方が、開発者がXSSを正しく保護するよりもおそらく簡単だと主張します。これはStormpathのソリューションを示唆しています。
おそらく、とにかく両方の攻撃から保護したいと思うかもしれません。
おそらく両方の組み合わせを使用すると、各ストアが1つの形式の攻撃（XSSまたはCSRF）からユーザーを保護するため、より安全です。これは同じことについての素晴らしい記事です：