セッション管理の不備、つまりセッション・ハイジャック、セッション・フィクセーションの脆弱性と、クロスサイト・リクエスト・フォージェリ（CSRF）の脆弱性について、EC-CUBE 2.12.6 を対象に見てみました。
結論をまず申し上げますと、「対策はなされていますけれども、わたくしのレベルが低くて充分なセキュリティ強度があるかどうかは結局わからなかった」です。
ウェブ健康診断仕様の 18 ページ、 (K) セッション管理の不備の検出パターン、「1 ログインの前後でセッションID が変化するか」で「セッションID が変わらない場合」に脆弱性ありとしています。
EC-CUBE 2.12.6 を調べてみましたら、会員ログイン時も、店舗管理者ログイン時も、ログイン前後でセッション ID は不変でございました。脆弱性がありますわ！まあ！どういたしましょう！
そう思いつつ、安全なウェブサイトの作り方の対応セクション、16 ページからの「1.4 セッション管理の不備」を拝見いたしますと、■ 根本的解決の部分に次のようにありました。
- ■ 根本的解決「4-(iv)-a ログイン成功後に、新しくセッションを開始する。」
あら、やっぱり EC-CUBE 2.12.6 には脆弱性があるのでしょうか？もう少し読み込んでみますと、次の対策でも良いとのこと。
- ■ 根本的解決「4-(iv)-b ログイン成功後に、既存のセッションIDとは別に秘密情報を発行し、ページの遷移ごとにその値を確認する。」
また、同様のことが書籍『体系的に学ぶ安全なWebアプリケーションの作り方』にも記載されております。
- P181 に、認証後に「セッションIDの変更ができない場合はトークンにより対策する」ことで、「トークンによりセッションIDの固定化攻撃を防御できます」とのこと。
この対策は、EC-CUBE 2.12.6 のログイン機能に施されているでしょうか？調べましたので記録を残しておきます。
なお、セッション管理の不備について調べていくうちに、トークンをページ遷移ごとに確認する方法はクロスサイト・リクエスト・フォージェリ対策にもなることに気が付きましたのでまとめてノートです♪