セッションハイジャックとセッションIDの固定化攻撃セキュアコーディングの啓蒙第5回

はじめに

こんにちは！

株式会社ユーザベーススピーダ事業 Product Team（以下 Product Team）の下川です。

ユーザベースの Product Team には、全社のセキュリティを担うチームとは別に、プロダクトセキュリティの底上げを担うセキュリティチーム、通称 Blue Team というチームがあります。

私たちはそのチームの一員として、日頃の開発業務に加えてユーザベースのプロダクトのセキュリティを横断的に向上するための活動を行なっています。

現在、 Blue Team の取り組みのひとつとして、脆弱性のリスクや対策方法について継続的に記事にまとめ、Product Team 内の各開発チームで読み合わせを行なってもらう施策を実施しています。

このテックブログがユーザベースに興味を持っていただくきっかけになればと思っています！

第5回はセッションハイジャックとセッションIDの固定化攻撃を取り上げます！

どのような攻撃なのか？

どちらも悪意のある攻撃者が正規ユーザーになりすましてサービスを利用することが目的です。

攻撃が成功してしまうと、ユーザーになりすますことができるので多岐にわたる攻撃が可能になってしまいます。(ex. 送金、機密データの漏洩、システム操作 etc…)

IPA の資料では、これらはセッション管理の不備としてセッションハイジャックがあり、セッションハイジャックの攻撃手段の1つとしてセッションIDの固定化攻撃があると記載されています。

セッションハイジャックとは？

セッションハイジャックとは、認証済みのユーザーが使用するセッションIDを攻撃者が盗み、そのセッションを乗っ取る攻撃です。攻撃者は盗んだセッションIDを使い、正規ユーザーになりすまし正規ユーザーの権限でシステムにアクセスできます。ユーザーIDやログインパスワードの窃取をすることなくアカウントの乗っ取りができてしまいます。

セッションIDの固定化攻撃とは？

セッションIDの固定化攻撃とは、攻撃者があらかじめ取得または作成したセッションをなにかしらの方法で正規ユーザーに使わせる攻撃です。正規ユーザーが、攻撃者が用意したセッションIDで認証をすることで、攻撃者が持っているセッションIDが認証済みの有効なセッションIDとなってしまい正規ユーザーになりすまし正規ユーザーの権限でシステムにアクセスできます。

どの程度の被害が出ているのか？

IPA（情報処理推進機構）の報告によると、セッション管理の不備に関する届出は全体の数パーセントで、他の攻撃手法に比べると件数は少ないです。しかし、件数が少ないとはいえセッション管理の不備は非常に重大な問題です。

実際、IPAがセキュリティ関連の届出受付を開始して以来、継続的にセッション管理に関する問題が報告され続けているそうです。そのような状況からもセッション管理の不備は件数は少なくても根深い問題であり、被害が発生した場合には多大な影響を及ぼす可能性があります。攻撃者にとって一度成功すれば、ユーザーになりすまし、重要なデータやシステムへアクセスできるため、企業やサービス提供者、そしてそれを開発するエンジニアにとっては常に警戒を怠ることができないリスクです。

どのように攻撃が行われるのか？

セッションハイジャックの例

正規のユーザーが正規のサイトにログインして、セッションIDを取得する
攻撃者が何かしらの方法を使ってセッションIDを盗む
- セッションIDを推測する
  - 連番や正規ユーザーの登録情報から連想しやすいもの(生年月日やユーザーIDなど)でセッションIDを生成している場合などは推測されやすくなります。
- XSSを悪用してセッションIDを盗む
  - セッション情報の管理が不適切な場合、XSSによって埋め込まれたスクリプトからセッションIDが盗まれる可能性があります。
- 通信を盗聴する
  - 通信が暗号化されていない場合、パケットキャプチャソフトを使ってサーバーに届くまでの通信を盗聴しセッションIDが盗まれる可能性があります。
- セッションIDの固定化攻撃で攻撃者が用意したセッションIDの利用を強制する
  - セッションIDの固定化攻撃の詳細は後述します。
攻撃者が盗んだセッションIDを使って正規サイトにアクセスすることで、なりすましができる

セッションIDの固定化攻撃の例

攻撃者が正規のサイトにアクセスしてセッションIDを取得する
- このタイミングではログインをする必要があるとは限りません
攻撃者が取得したセッションIDを何かしらの方法で正規のユーザーに送りつけて利用を強制させる
- セッションIDをURLに含めて送信する実装をしている場合、SMSやメールで強制させたいセッションIDを含めたメールを送信します(フィッシングメール)。正規ユーザーがアクセスしてログインするとURLに含まれたセッションIDの利用が強制されてしまいます。
```
 http://example.com/hoge?sessionId=HogehogeSession
```
- XSS脆弱性を悪用してセッションIDを強制することができる
  - XSS を利用して Cookie に任意のセッションIDを保存し、利用を強制させます。
```
 <script>document.cookie="sessionId=HogehogeSession"; </script>
```
- HTTPヘッダインジェクション脆弱性を悪用してCookieを強制追加する
  - HTTPヘッダインジェクション脆弱性の詳細はここでは割愛しますが、簡単に説明すると実装の不備によってユーザーの入力値などをHTTPヘッダに追加できてしまう脆弱性です。
```
 http://example.com%0d%0aSet-Cookie:%20sessionId=HogehogeSession
```
正規のユーザーが強制されたセッションIDを使ってログインする
正規のユーザーがログインに成功すると強制されたセッションIDが認証済みの有効なセッションIDとなる
攻撃者はそのセッションを使って正規サイトになりすましでアクセスができる

どのように対策するのか

セッションハイジャック対策

セッションIDが盗まれないための仕組みで対策をします。

HTTPSの導入:
- すべての通信を暗号化しネットワークスニッフィング(通信の盗聴)による情報漏えいを防ぎます。
クッキーのセキュリティ設定:
- セッションIDを保存するクッキーにHttpOnly、Secure属性を付与し、JavaScriptからのアクセスを防ぎます。
セッションIDの複雑化
- 推測されにくいセッションIDを発行するようにします。

セッションIDの固定化攻撃対策

外部から受け取ったセッションを利用できない仕組みで対策します。

認証後のセッションID再生成:
- ログイン後にセッションIDを更新する処理を入れます。また新しいセッションを作成したら古いセッションは破棄します。
- セッションIDの再生成ができない場合、ランダムな値を生成してその値とセッションIDの紐付けをサーバー側で管理し、ページ遷移のたびに検証をします。
  - セッションIDの再生成はベストプラクティスの1つであるため最近のフレームワークでセッションIDが再生成できない制約は聞くことはないです。ただ古いフレームワークやセッション管理の独自実装を使っているアプリケーションでは再生成が困難な可能性があります。
セッションの有効期限と適切な設定:
- セッションの有効期限を短く設定し、攻撃者がセッションを長時間利用できないようにします。
URLにセッションIDを含めない:
- フィッシングメールやSNSなどでセッションIDの固定化攻撃を狙ったURLの公開、配信がされても被害がでないようにします。
クッキーのセキュリティ設定:
- 攻撃者が用意したセッションIDを Cookie に書き込ませないために、Cookieの HTTPOnly 属性を有効にしてクライアントサイドのコードからのアクセスを許可しないようにします。

余談

Q: セッションIDの固定化攻撃の対策でセッションIDの再生成が対策として有効とあるが、ログイン前にセッションIDが発行されるケースがあるのでしょうか？

A: 発行しているケースもあります。

例えば EC サイトの場合、ログイン前にカートに商品を入れて、購入時にログインを求められてログインすると、ログイン前のカートの情報が引き継がれていると思います。これはログイン前にセッションIDを発行していて、カートの情報をそのセッションIDに紐付けているからです。

※ あくまで一例で全ての EC サイトがそうであるとは限りません。

まとめ

セッションハイジャックとセッションIDの固定化攻撃は、セッション管理の脆弱性を悪用した攻撃手法です。適切なセキュリティ対策（HTTPS の利用、セッションIDの再生成、クッキーのセキュリティ設定）を正しく実装することで、リスクを大幅に軽減できます。開発者は、これらの脆弱性を理解し、セキュリティを考慮した設計を行うことが求められます。