カスタムヘッダーのセッションID

Question

リクエストヘッダーでセッションIDが渡された場合、XSSが存在する状態でセッション固定攻撃を実行する方法はありますか？

私が見る限り、理論的には3つの方法があります。

ログイン時にリクエストをインターセプトし、セッションIDを置き換えます（クライアントの追加インストールなしでJSを使用する方法が見つからない service worker など、まだ機能していないか、ブラウザ拡張機能がありません）
サーバーからの応答をインターセプトし、サーバーによって提供された代替セッションID（上記のオプションで予期される情報もありません）。
ローカルストレージからセッションIDを取得します（現時点では、セッションCookieがどこに保存されているのか明確ではありません）。 localStorageをsetItemで上書きするb。 sessionStorageをsetItemで上書きc。 document.cookieを上書きd。セッションを格納するカスタムの方法が使用されている場合は、クライアントコードをリバースエンジニアリングして、XSSでの方法と使用方法を見つけます。カスタムヘッダーはセッションを操作する標準的な方法ではないため、保存されたセッションIDを保存および取得する責任はクライアントJSにあることを理解しています。したがって、ローカルストレージをCookieで上書きする方法が必要です。

利用可能なオプションの概要が正しい場合（間違いがあった場合は修正してください）、すべてのオプションのうち、実際に見えるのはストレージを攻撃しているオプションのみです。この記事では、

ご覧のとおり、セッショントークンはカスタムHTTPヘッダーX-AUTH-TOKENで送信されます。カスタムHTTPヘッダーでセッショントークンを送信して、クロスサイトリクエストフォージェリ（CSRF）攻撃からアプリケーションを保護します。残念ながら、リクエストに含まれるためには、トークンを格納するグローバルCookieがJavaScriptから利用可能でなければならないため、アプリケーションがトークンの盗難に対して非常に脆弱になります。

ローカルストレージ攻撃に関しては、私は一般的に理解していますが、要求と応答をインターセプトしてオンザフライで変更することについてはどうですか？私が理解している限り、要求と応答をインターセプトするには、悪意のあるブラウザ拡張機能がクライアントにインストールされている必要があります。 HTMLからカスタムヘッダーを設定することはできません。唯一のオプションはJSです（JSはXHRで設定できることを知っていますが、それはセッション固定のオプションではない別のリクエストになります）。しかし、どれほど正確に、そしてそれが可能かどうかは、まだはっきりしていません。それを行う方法はありますか？誰かがこれについて何かアドバイスをすることはできますか？

Conor Mancone · Accepted Answer

httpOnly Cookie

明確にするために、あなたの質問は、暗黙的にhttpOnly CookieにセッションIDを保存するサイトを除外することです。その理由は、そのようなCookieはJavaScriptに完全にアクセスできないため、セッションIDがhttpOnly Cookieに保存されている場合、カスタムヘッダーでセッションIDを送信することができないためです。あなたはすでにこれを知っていますが、私はこの要件を大声で述べたいと思います。

セッション管理の他のすべての方法

文字通り、他のすべてのセッション管理のケースでは、XSS攻撃が発生した場合、セッションの固定が可能です。つまり、セッションIDがカスタムヘッダー内にある場合は、それをアタッチできるように、JavaScriptにアクセスできる必要があります。 JavaScriptにアクセスできる場合、攻撃者のJavaScriptにアクセスできます。 JavaScriptがアクセスできない唯一のデータソースはhttpOnly Cookieであり、ここでは使用されていません。

セッションIDはローカルストレージに保存されますか？攻撃者のJavaScriptは、ローカルストレージに保存されている値を置き換えることができます。セッションIDは非httpOnly Cookieに保存されますか？攻撃者はそこでも置き換えることができます。 httpOnly Cookie以外に、攻撃者のJavaScriptではなくJavaScriptにアクセスできるデータソースはありません。その結果、セッションの固定は、JavaScriptをリバースエンジニアリングしてトークンが格納されている場所を特定するだけの問題です。リクエストをインターセプトしたり、Webワーカーをインストールしたりする必要はありません（ただし、可能であれば Webワーカーなしでリクエストをインターセプトする）。悪意のある拡張機能は、転送中のリクエストを確実に変更する可能性がありますが、これも必要ありません。XSS攻撃だけで十分です。

繰り返しますが、ここで重要なポイントを強調しようとします。要求をインターセプトしようとするのは面倒です。それはかなりの痛みかもしれません。あなたがする必要があるのは、セッションIDがクライアント側にどこにどのように保存されているかを理解し、そこに選択したセッションIDを注入することです。 JavaScriptにアクセスできるため、攻撃者のJavaScriptにアクセスできます。