XSS攻撃で読み取ることができるため、JWTトークンをlocalStroageに保存しないでください。提案されたソリューションは、JWTトークンをHTTPOnly Cookieに格納し、二重CSRを使用したCSRF防止を使用することです。 OWASPは、すべてのCSRFソリューションはXSSに対して脆弱であると述べています。その場合、CSRFを含むHTTPOnly CookieのJWTはXSSに対して脆弱ですか?もしそうなら、なぜw/CSRFに煩わされ、JWTをlocalStorageに保存するのでしょうか
XSS攻撃で読み取ることができるため、JWTトークンをlocalStroageに保存しないでください。
そうだね。 JWTに情報を格納し、攻撃者がXSS経由で情報を読み取らないようにするには、それらをhttpOnly Cookieに格納することをお勧めします。
提案されたソリューションは、JWTトークンをHTTPOnly Cookieに格納し、CSRFと二重送信Cookieを使用することです。
ここで2つ混乱していると思います。トークンをhttpOnly Cookieに格納することは、すでにトークンが読み取られないという解決策です。
CSRFは別の問題であり、データの読み取りには使用できません。ただし、そのユーザーが意図していないユーザーのWebサイトでアクションを実行するために使用できます。これに対する1つの解決策は、二重送信Cookieパターンです。
OWASPは、すべてのCSRFソリューションはXSSに対して脆弱であると述べています。
はい、ほとんど。
その場合、CSRFを含むHTTPOnly CookieのJWTはXSSに対して脆弱ですか?
ことは二重送信CookieパターンでhttpOnly Cookieに保存されているCSRF防止トークンを使用することはできませんです。
トークンをフォームに挿入できない場合は、クライアント側でトークンにアクセスする必要があります。
したがって、これを機能させるには、CookieをhttpOnlyにしないか、トークンをCookieに加えて他の場所(ローカルストレージなど)に保存する必要があります。
どちらの方法でも、攻撃者はXSSを取得すると、CSRF保護をバイパスできます。
もしそうなら、なぜw/CSRFに煩わされ、JWTをlocalStorageに保存するだけなのでしょうか。
XSSの脆弱性がある場合でも、JWTのコンテンツを攻撃者から隠したい場合は、JWTをhttpOnly Cookieに保存する必要があります。気にしない場合、または自分で情報にアクセスする必要がある場合は、localStorageも同様に機能します。