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
下記のような回答は推奨されていません。
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
このような回答には修正を依頼しましょう。
回答へのコメント
関連した質問
Q&A
解決済
ボタンのcssが一部にしか効かない
回答2
クリップ0
更新
2020/03/04
Q&A
受付中
Java Servletによるログイン→画面遷移をしたいが404エラーが出てしまう
回答1
クリップ0
更新
2023/03/24
Q&A
受付中
java.lang.NumberFormatException:エラーの解決方法が知りたいです.
回答1
クリップ0
更新
2023/03/26
Q&A
解決済
そのエラーが箇所が下記のPHPには見当たりません。
回答2
クリップ0
更新
2023/03/17
意見交換
受付中
データベースの負荷を下げたい
回答27
クリップ0
更新
2023/03/26
Q&A
解決済
Googleフォーム回答後のGASでの自動返信メールを、SendGrid経由で送信したい。
回答2
クリップ1
更新
2023/03/21
Q&A
解決済
sshのログインが急に出来なくなりました。
回答2
クリップ0
更新
2023/03/16
Q&A
解決済
cookieとセッションの乗っ取りについて(セッションハイジャック)
回答3
クリップ4
更新
2023/01/02
同じタグがついた質問を見る
HTTPにおけるCookieとは、クライアントのウェブブラウザ上に保存された一時的なデータを指します。クライアント側のJavaScriptでも、サーバー側のHTTPヘッダーでもクッキーの読み書き・修正・削除が可能です。
DjangoはPythonで書かれた、オープンソースウェブアプリケーションのフレームワークです。複雑なデータベースを扱うウェブサイトを開発する際に必要な労力を減らす為にデザインされました。
Python 3はPythonプログラミング言語の最新バージョンであり、2008年12月3日にリリースされました。
Sessionはクライアントがサーバに送ったすべてのリクエストのことを指します。
ログインは、ユーザーがコンピューターシステムにアクセスするプロセスの事を呼びます。
下記のような回答は推奨されていません。
このような回答には修正を依頼しましょう。
2023/01/01 23:13