セッションハイジャック攻撃　[セキュリティ研究室]

日付:
　こんにちは！
　ナビゲータのEVEです。

　現在、ログイン時のセキュリティクラスの製造に手間取っています。っというか、長い間使っていなかったDBクラスのバグというか、なんというか、プリシアードステートメントにステートメントを設定するロジックがないことに気づかず数時間も掛けてしまった恥ずかしい話なのですが・・・。
　プリシアードステートメントにバインド変数を設定して、SQL文を編集するのですが、そうした場合、実際に実行したSQL文がログに残すことができません。そのためシステムがデバックモードになっている場合、SQL文を残すという普段なら不要なロジックを作ったためだと思うのですが、ステートメントを設定するロジックが抜けていました。普段から、SQL文に関するメソッドを作っているならすぐに気づけたのでしょうが、作ってからかなりの時間が経っています。気づかずChatGPTとかなりあぁ～でもない、こうでもないといろいろやってしまいました。ChatGPTも、PHPの通常関数のプログラミングなら、すぐに解答できるのでしょうが、私もいろいろつくりこんでいるので・・・。今日の午前中まるまるつぶれてしまいました・・・。
　一応ログイン画面は今週末で終わらせて、来週から、ログイン後のシステムの製造に入ります。そこまでいけば、仕様的に悩むことがなくなるので、製造が軌道に乗るとは思うのですが・・・。まっ、その辺も不確かなので、軌道にのるのは、5月からとし、そこからスケジュールを確定し再公表します。こんな、状況を振り返って思うのは、フレームワークの基本的な部分は、やはり、少人数で作った方が良いようです。仕様については、事前に考えているのですが、作ってみるといろいろと違うっていうことがあるからです。そんな状況に、大所帯のプロジェクトなら金がかかってしかたがないでしょう？私の場合は、1人なので、気が楽です。
　では、本日は、先週の続きで、ログイン画面におけるセキュリティについてお話ししましょう。本日は、セッションハイジャックについてです。

[セッションハイジャック]

1. セッションハイジャックの攻撃手法
■被害例
　攻撃者がユーザーのセッションIDを盗み、なりすましログインを行う。

■類似攻撃
★MITM攻撃（中間者攻撃）
　攻撃者が通信を傍受し、平文でやりとりされたセッションIDを盗む。

★セッションフィクセーション
　攻撃者がユーザーにあらかじめ決めたセッションIDを使わせることで、セッションを乗っ取る。

★ネットワークスニッフィング
　攻撃者がWiresharkなどのツールを使って通信を盗聴し、セッションIDを取得。

■対策：
・HTTPSを使用（session.cookie_secure = 1）
・VPNを利用
・安全なネットワークを使用（公共Wi-Fiを避ける）

　セッションハイジャック攻撃とセッションフィクセーション攻撃は異なる攻撃手法ですが、どちらもセッション管理に関わる問題です。セッションフィクセーション攻撃では、攻撃者が特定のセッションIDをユーザーに強制的に割り当て、ユーザーがそのIDで認証された後に攻撃者がそのセッションIDを利用して不正アクセスするものです。一方、セッションハイジャック攻撃は、攻撃者が有効なセッションIDを盗み、そのセッションを乗っ取る攻撃です。
　セッションIDが簡単に予測できる場合や、SSL/TLS通信を使用していない場合、これらの攻撃が成立しやすくなります。特に、セッションIDを平文で送信する場合、攻撃者がセッションIDを盗聴するリスクが高まります。したがって、SSL/TLS通信（HTTPS）を使用してセッションIDを保護することが非常に重要です。
　また、JavaScriptでクッキーを操作できる場合、そのクッキーの内容が攻撃者に盗まれる可能性があります。このリスクを防ぐためには、HttpOnly属性をクッキーに設定することが推奨されます。HttpOnlyを設定することで、クッキーはHTTPリクエストでのみ送信され、JavaScriptからアクセスできなくなります。これにより、XSS攻撃などによってクッキー情報が盗まれるリスクを減らせます。
　セッションIDを複雑かつ予測不可能に保つことも重要です。PHPでは、デフォルトで生成されるセッションIDは十分にランダムで予測不可能ですが、セッションIDが固定されるとセッションフィクセーション攻撃に対して脆弱になります。そのため、ユーザーがログイン後にセッションIDを再生成することが推奨されます。session_regenerate_id(true)を使用して、セッションIDを再生成することができます。
　さらに、心配な場合は、セッションIDを定期的に変更することも効果的です。セッションIDの再生成は、攻撃者が以前のIDを盗んでも無効にできるため、セキュリティを強化する手段の一つです。
　最後に、セッションIDにはクッキーとサーバーサイドで管理されるセッションが関係しています。セッションIDは通常、クッキー（PHPSESSIDなど）に格納され、サーバー側でそのIDに紐づけられたセッションデータ（例えば、ログイン情報）にアクセスします。セッションID自体はクライアント側で取得できますが、その内容を保護するためには、HttpOnly属性を設定することが重要です。

[あとがき]

　最後の文章については、誤った情報を避けるためにChatGPTに手伝ってもらいました。ここで混乱しやすいのは、クライアントとサーバーがやり取りするIDには「クッキー」と「セッションID」の2種類があるという点です。それぞれの扱いは異なり、まだ完全に理解できていない部分もありますが、簡単に言えば、セッションIDはサーバー側で管理され、クッキーはクライアント側で設定・送信されるものです。そのため、両者の扱い方には違いがあります。
　会議などで「クッキー」と一言で済ませる場面も多いですが、クライアント側で保持するクッキーのIDと、サーバーが管理するセッションIDが混同されることもあります。どちらについて話しているのかを明確にしながら議論することが重要です。ぜひ注意してください。

　では、また！

コメント

コメントを投稿