Q&A
「セッションIDの再生成機能」を利用しても、結局のところツールで無作為に選ばれたセッションIDとかぶったら、なりすましログイン可能になってしまいますよね？
Djangoでログイン認証画面を作成しています。
そこでふと、疑問に思ったので、質問させてください。
ECサイトなどのショッピングサイトで、ログイン者の情報などをセッションとクッキーを使って管理していると思います。
例えば下記のような形式でセッションIDがクッキーに保存されているとき
(key) (value) SESSION_KEY: asioudasfdawefas
ChromeプラグインのEditThisCookieなどのツールを用いて、ブルートフォース攻撃でvalueを改変・編集をした場合に容易に第三者になりますしてログインされてしまうんじゃないかと思ってしまいました。
ログイン画面のときのブルートフォース攻撃は、認証に3回失敗したら、しばらく無効になるとか対策をよく見ますが、クッキー改変による不正ログインに対しては、対策があるとはまったく聞きませんし、見たこともありません。
もし、そのような対策がしかれているのであれば、ご教示いただけませんでしょうか？
逆に、対策がされていないとなると、世の中のログインサイトは自分が思っている以上に相当危険な場所なのでしょうか？
回答3件
3
ベストアンサー
セッションハイジャックのための手段としては以下の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 11:56
総合スコア2438
0
普通はフレームワークに「セッションIDの再生成機能」がある。LaravelにもRailsにもある。
昔のDjangoにはなかったようだけど今は不明なのでまずはDjangoに機能があるか確認。
今もないなら自分で再生成しないとDjangoでは危険。
投稿2023/01/01 10:14
総合スコア10169
回答へのコメント
0
確かに気になりますね。
現実的にはブルートフォースアタックされてもほぼ問題ないような確率の長い文字列をセッションキーにするぐらいでしょうか。
他の対策法もあるみたいですが根本対策になるかというと微妙ですね。
- ログイン成功後に新しくセッションを開始する
Webアプリケーションの実装によってはログイン前のセッションIDとログイン後のセッションIDが同じ場合があります。 ログイン前後でセッションIDが同じ場合、セッションの固定化攻撃に脆弱になる可能性があります。 ログイン後は既存のセッションを無効化し、新しいセッションを開始することが必要です。 既存のセッションを無効化することで、攻撃者によって事前に取得されていたセッションIDでのアクセスを防ぐことができます。
- ログイン成功後に、既存のセッション ID とは別に秘密情報を発行し、ページの遷移ごとにその値を確認する
セッションIDとは別に秘密情報を作成し、セッションIDと秘密情報の値が一致することで正規の利用者である確認します。 この対策を行う場合はすべてのページでセッションIDと秘密情報の値が一致することを確認する必要があります。 また対策4.を実施している場合は、本対策は不要です
投稿2023/01/01 06:41
総合スコア1427
回答へのコメント
結局のところ、ブルートフォースされたらどんな機構で待ち受けていても無駄ってことですよね。
長い文字列にして、いかにブルートフォースでヒットする確率をどれだけさげられるかにつきますか。
でも、そのリスクを銀行とかの金融機関でのログインでもと考えたらちょっと怖いですよね。
金融機関の場合はワンタイムパスワードなどの仕組みがあるので、振り込みなどの重要な操作ではより厳しい認証が要求されますね
下記のような回答は推奨されていません。
このような回答には修正を依頼しましょう。
2023/01/01 23:13