セッションハイジャックのための手段としては以下の3種類があると考えられます(徳丸本 p.204 より引用)。
- セッションIDの推測
- セッションIDの盗み出し
- セッションIDの強制
まず、質問者さんの疑問は「セッションIDの推測」によるセッションハイジャックの可能性についてですね。「セッションIDの強制(Session Fixation)」によるセッションハイジャックではないので、ログイン後にセッションIDを再生成する話は無関係です(他の回答で言及されているので)。
逆に、対策がされていないとなると、世の中のログインサイトは自分が思っている以上に相当危険な場所なのでしょうか?
この懸念は杞憂です。危険ではないものがほとんどです。なぜなら、安全に設計されたシステムであれば、セッションIDの推測が理論上困難(=現実的に不可能)であるからです。
セッションIDの推測によって攻撃が成立してしまうケースでは、セッションIDが推測可能であるという前提が必要です。
この推測可能性については、大きく次のように分類できます(以下の分類は私個人の見解です)。
- (L3) 理論的に推測困難(=現実的に推測不可能)である。十分な長さ(128ビット相当以上)があればこれが担保される。十分な長さに関する考察は セッション管理に関するチートシート - OWASP を参照ください。
- (L2) 推測が容易ではないが、現実的に推測可能である。不十分な長さの文字列であったり、L1 から導出可能な文字列の場合。導出可能とは、例えば使っている文字列自体は128ビット長のハッシュ値であったとしても、そのハッシュ値の生成が第三者にとって容易な場合です。
- (L1) 推測が容易である。連番や日時情報、ユーザID情報など、第三者が参照可能な文字列の場合。
要するに、L2 以下の推測困難性のもの(つまり推測が可能であるもの)をセッションIDとして用いた場合は、懸念されている通り、ブルートフォース攻撃でセッションハイジャックされる危険性があります。
一方で、L3 の推測困難性のものであれば「あてずっぽうで当たる可能性が現実的に無いに等しい」と評価できるため、安全に使用できます。
一般的な安全に設計されたシステムでは、L3 のセッションIDを用いているため、先に述べたとおり、ブルートフォース攻撃に対するこの観点では危険ではないと言えます。
ログイン画面のときのブルートフォース攻撃は、認証に3回失敗したら、しばらく無効になるとか対策をよく見ますが、クッキー改変による不正ログインに対しては、対策があるとはまったく聞きませんし、見たこともありません。
ログイン画面でのパスワード認証時に数回失敗したらロックするという処理が必要なのは、保護されるべき文字列であるパスワードを決めるのがユーザであるためです。セッションIDを決めるのはユーザではなくシステムです。
ユーザが決めた文字列は、システムをどう設計しようと L3 文字列を保証することができません。一方で、システムが生成した文字列であれば L3 であることを保証できます。この違いが、数回の失敗に対して認証操作のロックをかけるかどうかの違いに現れます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2023/01/01 23:13