盗まれたセッションIDと認証トークンのセキュリティリスク

Question

this SO question および付随するブログ投稿の議論に興味をそそられました。メカニズムをよりよく理解しようとしています2つのシステムのうち、私が思いついた質問の1つは、セッションIDと比較してトークンが盗まれるのがどれほど悪いかということです。

これが私がこれまでに理解したことです、そして私が間違っているなら私を訂正してください：

セッションIDは、サーバーに保存されている実際のセッションデータへの不透明な参照です。簡単に推測されないほどランダムである限り安全であり、データはフロントエンドから直接アクセスできない、またはフロントエンドに守られないため安全です。認証されたリクエストを簡素化するために、セッションIDはCookieに保存されます。

認証トークンは、データの整合性を検証する暗号化署名を含むJSONユーザーデータのプレーンテキストセグメントです。署名のために改ざん防止されているため、誰も自分のトークンを思いつくことはできません。それがアクセスを許可するデータは、もちろんトークンに存在するものを除いてサーバー上で安全です（必要な場合でも暗号化できます）。認証されたリクエストを簡素化するために、トークンはCookieに保存されることもよくあります。

だからここに私が理解していないものがあります。私の現在の見方では、セッションIDとしてトークンが盗まれる可能性が高いようです。私のSSLを突破して私のトークンを見た人は、セッションIDも見ることができます。どちらのイベントでも、攻撃者は私のアカウントへの完全なアクセスとすべての関連する承認を与えます。では、イベントの可能性とその結果生じる損害という点で、認証トークンは本当にセッションIDよりも悪いのでしょうか。

トークンの場合に悪化する可能性があると思われるのは、署名の秘密がどういうわけか判明した場合です。その場合、攻撃者はanythingを私のものではなく、誰のアカウントでも。しかし、私はこれを、RSAを最初に破る誰かの合理的な可能性にこれを委ねたいと思います。その場合、彼らはSSLを通過でき、それからセッションIDは何といいますか

rdegges · Accepted Answer

私はあなたが参照したブログ投稿の著者であり、リンクしたSO質問への回答でもあります。ここであなたが探している回答を示します。

セッションIDは、サーバーに保存されている実際のセッションデータへの不透明な参照です。簡単に推測されないほどランダムである限り安全であり、データはフロントエンドから直接アクセスできない、またはフロントエンドに守られないため安全です。認証されたリクエストを簡素化するために、セッションIDはCookieに保存されます。

ちょっと。セッションIDがhttpOnly Cookieに格納されると、Cookie自体が暗号で署名されます（暗号化することもできます）。 JavaScriptコードはhttpOnly cookieにneverでアクセスできます（httpOnlyフラグにより、JSコードがcookieを表示できなくなります）。

認証トークンは、データの整合性を検証する暗号化署名を含むJSONユーザーデータのプレーンテキストセグメントです。署名のために改ざん防止されているため、誰も自分のトークンを思いつくことはできません。それがアクセスを許可するデータは、もちろんトークンに存在するものを除いてサーバー上で安全です（必要な場合でも暗号化できます）。認証されたリクエストを簡素化するために、トークンはCookieに保存されることもよくあります。

ちょっと正解です。ほとんどのトークンは、大きすぎてhttpOnly Cookieに収まらないため、HTML5 LocalStorage（JavaScript）に保存されます。 Cookieの最大データストレージサイズは4kbです。トークンが4kbよりも大きい場合（ほとんどの場合、ユーザーがトークンを使用してユーザー情報を運ぶため）、あなたは他の場所に保管する必要があります。そして、Cookieの外にそれらを保存する最も簡単な方法は... LocalStorageであると推測しました。

残念ながら、これには深刻な副作用があります。

だからここに私が理解していないものがあります。私の現在の見方では、セッションIDとしてトークンが盗まれる可能性が高いようです。私のSSLを突破して私のトークンを見た人は、セッションIDも見ることができます。どちらのイベントでも、攻撃者は私のアカウントへの完全なアクセスとすべての関連する承認を与えます。では、イベントの可能性とその結果生じる損害という点で、認証トークンは本当にセッションIDよりも悪いのでしょうか。

誰かがLocalStorageからトークンを盗む可能性は、安全なhttpOnly Cookieが盗まれる可能性よりもはるかに高いです。また、盗まれたトークンが騒乱を引き起こすのも大幅に簡単です。理由は次のとおりです。

攻撃者が盗んだトークンを使用して、任意の場所（攻撃者のネットワーク、プロキシなど）からユーザーを偽装することができます。
ただし、攻撃者がJSコードをWebサイトに挿入できる場合、Cookieへのアクセスは許可されないため、攻撃者はJSコードを実行してユーザーを偽装することしかできませんユーザーがまだWebサイトにいる間。ユーザーがブラウザのタブを閉じると、攻撃者が実行していたJSコードは実行されなくなります。

ここには、非常に異なる乱用シナリオがあります。

トークンの場合に悪化する可能性があると思われるのは、署名の秘密が何らかの理由で判明した場合です。その場合、攻撃者は私のものではなく、誰のアカウントでも何でも実行できます。しかし、私はこれを、RSAを最初に破る誰かの合理的な可能性にこれを委ねたいと思います。その場合、彼らはSSLを通過でき、それからセッションIDは何といいますか

攻撃者が署名鍵を理解できれば、既存のトークンを改ざんできる（または独自の偽のトークンを作成できる）のはあなたの言うとおりです。ただし、署名鍵はサーバー側に保持する必要があるため、これはほとんどありません。たとえば、誤って署名鍵を漏らした場合、それは基本的にサーバーのパスワードを誰かと共有することと同じです。明らかに、あなたは悪い時間を過ごすことになります。

ここでの主な違いは、虐待がどのように展開するかです。上記にリンクした記事は、私が書いた別の投稿で、これをより明確な方法で詳しく説明しています。お役に立てれば！