"Cannot modify header information - headers already sent" や "You must call .. before any output has been sent to the browser; output started in ..." のようなエラーが出た場合は、そのメッセージの直接の原因となった部分 (関数あるいはメソッド) がどこなのかをきちんと調べましょう。 HTTP ヘッダを送信するアクション、たとえばブラウザのクッキーの変更などは、 通常の出力 (バッファリングされていない出力) の前に行う必要があります。ただし PHP の出力バッファリングを使用している場合は例外です。

導入: ZF でセッションを用いる際の最も推奨される方法は、 ブラウザのクッキー (ブラウザに保存される、通常のクッキー) を使用することです。個々のユーザを追跡するために、一意な識別子を URL に埋め込むことは、お勧めしません。 デフォルトでは、このコンポーネントは、 クッキーのみを使用してセッション識別子を管理しています。 クッキーの値が、ブラウザのセッションの一意な識別子となります。 PHP の ext/session は、この識別子を使用して ウェブサイトの訪問者との一対一の対応を保持し、 それぞれの訪問者ごとのセッションデータを持続して保持します。 Zend_Session* は、この保存の仕組み ($_SESSION) をオブジェクト指向のインターフェイスでラップしたものです。 残念ながら、もし攻撃者にクッキーの値 (セッション ID) がもれてしまうと、 攻撃者はそのセッションをのっとることができるようになってしまいます。 この問題は、PHP や Zend Framework に限ったものではありません。 regenerateId() メソッドを使用すると、 アプリケーション側でセッション ID (訪問者のクッキーに保存される値) を新しい値に変更できるようになります。この値は、 ランダムで予測不可能です。 注意: 厳密にいうと同じものではないのですが、この節では「ユーザエージェント」 と「ウェブブラウザ」を同じ意味で使用しています。 これは、読みやすさを考慮したためです。

なぜ?: 攻撃者にセッション識別子を知られてしまうと、 その攻撃者は別のユーザ (犠牲者) になりすますことができるようになります。 そして、その犠牲者にしかアクセスできない情報を取得したり、 犠牲者のデータを操作したりといったことが あなたのアプリケーションから行えるようになってしまうのです。 セッション ID を変更することで、セッションハイジャックを防ぐことができます。 セッション ID を変更した後は、変更後の値が攻撃者に知られない限り 攻撃者は新しいセッション ID を使用できません。その結果、 訪問者のセッションをのっとることができなくなります。 仮に攻撃者が古いセッション ID を取得したとしても、 regenerateId() はセッションデータを古いセッション ID から新しいほうに移すので、古いセッション ID からはどのデータにもアクセスできなくなります。

いつ regenerateId() を使うのか?: Zend_Session::regenerateId() を Zend Framework の起動ファイルに追加するのが、もっとも安全かつ確実に ユーザエージェントのクッキーにあるセッション ID を再生成する方法です。 セッション ID をいつ再生成するのかについての条件判断がない場合は、 ここに追加しておくとよいでしょう。 リクエストのたびに再生成するようにしておくと攻撃パターンのいくつかを防げますが、 中にはそれによるパフォーマンスの劣化やネットワーク帯域への負荷がきになる人もいるでしょう。 そこで、アプリケーション内でリスクの大きそうなところがどこかを判断し、 その場面でだけセッション ID を再生成するということも一般に行われています。 ウェブサイト訪問者のセッションの権限が「格上げされる」 (自分の "プロフィール" を編集する前に再度認証を行うなど) 際や、セキュリティ上「重要な」パラメータが変更される際などには、 常に regenerateId() で新しいセッション ID を作成するようにしましょう。 rememberMe() 関数をコールする際には、内部で自動的に regenerateId() がコールされます。 ユーザがウェブサイトへのログインに成功したら、 regenerateId() の代わりに rememberMe() を使うようにしましょう。

クロスサイトスクリプト (XSS) 脆弱性 を避けることは、セッションハイジャックを防ぐ助けになります。 Secunia の統計 によると、XSS 問題は頻繁に発生します。これは、 ウェブアプリケーションの開発言語が何であっても同じです。 XSS 問題が決して起こらないことを期待するよりも、 もしそれが発生した場合の被害を最小限に抑える方法を考えましょう。 XSS があれば、攻撃者は犠牲者のネットワークトラフィックに 直接アクセスする必要がなくなります。 犠牲者がすでにセッションクッキーを取得している場合、 Javascript XSS があると攻撃者がそのクッキーを読み取り、 セッションを盗むことができるようになります。 犠牲者がまだセッションクッキーを持っていない場合は、 攻撃者は XSS を使用して Javascript を注入し、 犠牲者のブラウザに既知の値のセッション ID クッキーを作成します。 そして同じクッキーを攻撃者のシステムに設定し、 犠牲者のセッションをのっとります。 犠牲者が攻撃者のウェブサイトを訪問すると、攻撃者は 犠牲者のユーザエージェントに関するその他の特性もエミュレートできるようになります。 あなたの作成するウェブサイトに XSS 脆弱性があると、 攻撃者はそこに AJAX Javascript を仕込み、知らないうちに攻撃者のウェブサイトを 「訪問」させてしまうことが可能になります。 攻撃者はそれによって犠牲者のブラウザの特性を取得し、 改ざんされたセッションでウェブサイトにアクセスするようになります。 しかし、開発者が save_path オプションに正しい値を設定しておくと、 攻撃者は PHP セッションのサーバ側の状態を任意に変更できることはなくなります。

それ単体では、セッションを最初に使用する際に Zend_Session::regenerateId() をコールしてもセッション固定化攻撃は防げません。そのセッションが、 攻撃者によって偽装されたものであるかどうかを判別できる必要があります。 先ほど説明したこととは矛盾しているように感じられるかもしれません。 しかしここで、攻撃者自身が まず最初にあなたのウェブサイトのセッションを開始した場合のことを考えてみましょう。 セッションを "最初に使用" するのは攻撃者です。 すると彼は、(regenerateId() による) 初期化の結果を知ることになります。 その後、攻撃者や新しいセッション ID と XSS 脆弱性を組み合わせて使用するか、 あるいは自分のウェブサイトにそのセッション ID を使用したリンクを埋め込みます (これは、use_only_cookies = off の場合にのみ動作します)。

同じセッション ID を使用している場合に 攻撃者と犠牲者を区別することができれば、 セッションハイジャックを直接行うことはできなくなります。 しかし、そのような区別を行うと、ユーザビリティが犠牲になってしまうことがあります。 区別するための方法が明確ではないからです。 たとえば、最初にセッションが作成されたときとは別の国に属する IP アドレスからリクエストを受け取った場合、 そのリクエストはおそらく攻撃者からのものだと考えられます。 しかし、次のような条件のもとでは、ウェブサイトへのアクセスが 犠牲者からのものなのか攻撃者からのものなのかを区別する方法はありません。

以下のサンプルコードのようにすると、 攻撃者が犠牲者の現在のセッション ID を知ることがはるかに困難になります。 ただし、上で説明した最初のふたつのステップを実行していない場合に限ります。

<?php
require_once 'Zend/Session.php';
$defaultNamespace = new Zend_Session_Namespace();

if (!isset($defaultNamespace->initialized))
{
    Zend_Session::regenerateId();
    $defaultNamespace->initialized = true;
}
?>