【ITニュース解説】徳丸本実習環境でHTTPヘッダインジェクションとセッションIDの固定化を組み合わせた演習手順

Webアプリケーションのセキュリティは、システムエンジニアにとって非常に重要な分野だ。現代のWebサービスは複雑化しており、その安全性はユーザーの信頼に直結する。ここでは、Webアプリケーションに潜む一般的な脆弱性の一つであるHTTPヘッダインジェクションと、それを利用したセッションIDの固定化という攻撃について、初心者にも理解できるよう解説する。

まず、Webアプリケーションとブラウザの間で行われる「HTTP通信」の基本から説明する。WebブラウザがWebサーバーに情報を要求する際、これは「リクエスト」と呼ばれる。そして、Webサーバーがブラウザに情報（Webページの内容など）を返す際、これは「レスポンス」と呼ばれる。これらのリクエストとレスポンスには、それぞれ「ヘッダ」と「ボディ」という二つの部分がある。ボディにはWebページ本体のHTMLデータなどが含まれるが、ヘッダには通信に関する様々な情報が含まれる。たとえば、レスポンスヘッダには、ページのキャッシュ方法や、ブラウザに保存させるべき情報（クッキーなど）、別のページへの転送指示（リダイレクト）といったメタデータが格納される。

「HTTPヘッダインジェクション」とは、このレスポンスヘッダに、攻撃者が意図しない不正な情報を挿入する攻撃手法のことだ。Webアプリケーションがユーザーからの入力値を適切に処理せず、その値をレスポンスヘッダの一部として出力してしまう場合に発生する。具体的には、ユーザー入力値に「改行コード（\r\n）」が含まれていると、アプリケーションはそれを改行として解釈し、ヘッダの区切りと認識してしまう。その結果、攻撃者は改行コードに続けて好きな内容を記述することで、既存のヘッダを改ざんしたり、全く新しいヘッダを追加したりできるようになる。 たとえば、リダイレクト先のURLを指定するLocationヘッダにユーザー入力がそのまま使われる場合、攻撃者はLocationヘッダの後に改行コードを挿入し、続けてSet-Cookieヘッダを追加することで、ユーザーのブラウザに任意のクッキーを設定させることが可能となる。

このHTTPヘッダインジェクションが悪用される代表的な例が、「セッションIDの固定化（Session Fixation）」という攻撃だ。Webアプリケーションでは、ユーザーがログイン状態を維持したり、カートの中身を記憶したりするために、「セッション」という仕組みを利用している。セッションは、個々のユーザーを識別するための「セッションID」という一意の文字列をユーザーのブラウザに発行し、それをクッキーとして保存することで管理される。ブラウザはWebサーバーにリクエストを送るたびに、このセッションIDをサーバーに提示し、サーバーはそのIDに対応するユーザーの状態を特定する。 セッションIDの固定化攻撃は、攻撃者が特定のセッションIDをユーザーに強制的に使わせることで発生する。攻撃者は、まず自分でWebサイトにアクセスして有効なセッションIDを一つ取得する。そして、そのセッションIDを含む細工したURLを作成する。この時、HTTPヘッダインジェクションの脆弱性を利用し、攻撃者が用意したセッションIDをSet-Cookieヘッダとしてユーザーのブラウザに設定させることが可能となる。

具体的な攻撃の流れはこうだ。まず、攻撃者はWebアプリケーションの脆弱な部分を見つける。次に、攻撃者は自身でセッションIDを生成し、そのIDを使って作られた不正なSet-Cookieヘッダと、リダイレクト先のURLを組み合わせたURLを生成する。このURLを被害者であるユーザーに送りつけ、クリックさせる。ユーザーがこのURLにアクセスすると、WebアプリケーションはHTTPヘッダインジェクションの脆弱性により、攻撃者が用意したSet-Cookieヘッダを含むレスポンスを返す。これにより、ユーザーのブラウザには攻撃者が指定したセッションIDが保存されることになる。その後、ユーザーがそのWebサイトでログインを行うと、この攻撃者が指定したセッションIDが正規の認証済みセッションとして使用されてしまう。攻撃者は、すでに知っているセッションIDを使って再度Webサイトにアクセスすることで、ログイン済みのユーザーになりすまして、そのユーザーの情報を閲覧したり、不正な操作を行ったりできるようになるのだ。

この攻撃を防ぐためには、いくつかの重要な対策が必要となる。まず、HTTPヘッダインジェクション自体を防ぐことだ。これは、Webアプリケーションがユーザーからの入力値をレスポンスヘッダに出力する際に、改行コード（\rや\n）を厳密に除去したり、あるいは想定される文字だけを許可する「ホワイトリスト方式」で入力値を検証したりすることで実現できる。特に、リダイレクト先のURLなど、外部からの入力値を受け付けるLocationヘッダには細心の注意が必要だ。安全なリダイレクト先をアプリケーション内部で固定するか、正規のURLのみを許可する厳格なチェックを実装しなければならない。

次に、セッションIDの固定化を防ぐための対策として最も効果的なのが、「ログインが成功した際に、必ず新しいセッションIDを再発行する」ことだ。Webアプリケーションがユーザーの認証を完了したら、その直前に使われていたセッションIDを破棄し、新たにランダムなセッションIDを生成してユーザーに付与し直す。PHPなどのプログラミング言語では、session_regenerate_id()のような関数を使用することでこれを簡単に行える。これにより、たとえ攻撃者が事前にセッションIDをユーザーのブラウザに仕込んでいたとしても、ログイン処理が完了した時点でそのIDは無効となり、攻撃者はユーザーのセッションを乗っ取ることができなくなる。

システムエンジニアを目指す上で、このようなWebアプリケーションの脆弱性とその対策を理解することは非常に重要だ。セキュアなコードを書く習慣を身につけ、常にセキュリティの観点からアプリケーションの設計や実装を考えることが、安全なWebサービスを提供する上で不可欠となる。これらの知識は、Webアプリケーション開発に携わる全ての人にとって基礎となる。