質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.45%
Cookie

HTTPにおけるCookieとは、クライアントのウェブブラウザ上に保存された一時的なデータを指します。クライアント側のJavaScriptでも、サーバー側のHTTPヘッダーでもクッキーの読み書き・修正・削除が可能です。

Django

DjangoはPythonで書かれた、オープンソースウェブアプリケーションのフレームワークです。複雑なデータベースを扱うウェブサイトを開発する際に必要な労力を減らす為にデザインされました。

Python 3.x

Python 3はPythonプログラミング言語の最新バージョンであり、2008年12月3日にリリースされました。

セッション

Sessionはクライアントがサーバに送ったすべてのリクエストのことを指します。

ログイン

ログインは、ユーザーがコンピューターシステムにアクセスするプロセスの事を呼びます。

Q&A

解決済

3回答

1467閲覧

cookieとセッションの乗っ取りについて(セッションハイジャック)

EzrealTrueshot

総合スコア388

Cookie

HTTPにおけるCookieとは、クライアントのウェブブラウザ上に保存された一時的なデータを指します。クライアント側のJavaScriptでも、サーバー側のHTTPヘッダーでもクッキーの読み書き・修正・削除が可能です。

Django

DjangoはPythonで書かれた、オープンソースウェブアプリケーションのフレームワークです。複雑なデータベースを扱うウェブサイトを開発する際に必要な労力を減らす為にデザインされました。

Python 3.x

Python 3はPythonプログラミング言語の最新バージョンであり、2008年12月3日にリリースされました。

セッション

Sessionはクライアントがサーバに送ったすべてのリクエストのことを指します。

ログイン

ログインは、ユーザーがコンピューターシステムにアクセスするプロセスの事を呼びます。

0グッド

4クリップ

投稿2023/01/01 06:18

Djangoでログイン認証画面を作成しています。
そこでふと、疑問に思ったので、質問させてください。

ECサイトなどのショッピングサイトで、ログイン者の情報などをセッションとクッキーを使って管理していると思います。

例えば下記のような形式でセッションIDがクッキーに保存されているとき

(key) (value) SESSION_KEY: asioudasfdawefas

ChromeプラグインのEditThisCookieなどのツールを用いて、ブルートフォース攻撃でvalueを改変・編集をした場合に容易に第三者になりますしてログインされてしまうんじゃないかと思ってしまいました。

ログイン画面のときのブルートフォース攻撃は、認証に3回失敗したら、しばらく無効になるとか対策をよく見ますが、クッキー改変による不正ログインに対しては、対策があるとはまったく聞きませんし、見たこともありません。

もし、そのような対策がしかれているのであれば、ご教示いただけませんでしょうか?

逆に、対策がされていないとなると、世の中のログインサイトは自分が思っている以上に相当危険な場所なのでしょうか?

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答3

0

ベストアンサー

セッションハイジャックのための手段としては以下の3種類があると考えられます(徳丸本 p.204 より引用)。

  1. セッションIDの推測
  2. セッションIDの盗み出し
  3. セッション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

arcxor

総合スコア2859

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

EzrealTrueshot

2023/01/01 23:13

>一方で、L3 の推測困難性のものであれば「あてずっぽうで当たる可能性が現実的に無いに等しい」と評価できるため、安全に使用できます。 そうなんです!ここなのです! たとえば、自動化ツールなどをもちいて、ランダムな数字をクッキーに埋め込み、サイトにアクセスをするというのをPCの計算処理能力を用いて、1兆回くらい試せば、なにかしらヒットしてしまうんじゃないか?と思ったのです。ただ、128bitなら問題なさそうですね。勉強になりました。 >一般的な安全に設計されたシステムでは、L3 のセッションIDを用いているため、先に述べたとおり、ブルートフォース攻撃に対するこの観点では危険ではないと言えます。 djangoの認証機構がL3状態なのかこのあと確認してみようと思います! ありがとうございました!
guest

0

普通はフレームワークに「セッションIDの再生成機能」がある。LaravelにもRailsにもある。
昔のDjangoにはなかったようだけど今は不明なのでまずはDjangoに機能があるか確認。
今もないなら自分で再生成しないとDjangoでは危険。

投稿2023/01/01 10:14

kawax

総合スコア10377

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

EzrealTrueshot

2023/01/01 10:57

「セッションIDの再生成機能」を利用しても、結局のところツールで無作為に選ばれたセッションIDとかぶったら、なりすましログイン可能になってしまいますよね?
guest

0

確かに気になりますね。
現実的にはブルートフォースアタックされてもほぼ問題ないような確率の長い文字列をセッションキーにするぐらいでしょうか。

他の対策法もあるみたいですが根本対策になるかというと微妙ですね。

  1. ログイン成功後に新しくセッションを開始する

Webアプリケーションの実装によってはログイン前のセッションIDとログイン後のセッションIDが同じ場合があります。 ログイン前後でセッションIDが同じ場合、セッションの固定化攻撃に脆弱になる可能性があります。 ログイン後は既存のセッションを無効化し、新しいセッションを開始することが必要です。 既存のセッションを無効化することで、攻撃者によって事前に取得されていたセッションIDでのアクセスを防ぐことができます。

  1. ログイン成功後に、既存のセッション ID とは別に秘密情報を発行し、ページの遷移ごとにその値を確認する

セッションIDとは別に秘密情報を作成し、セッションIDと秘密情報の値が一致することで正規の利用者である確認します。 この対策を行う場合はすべてのページでセッションIDと秘密情報の値が一致することを確認する必要があります。 また対策4.を実施している場合は、本対策は不要です

https://www.ubsecure.jp/blog/session_hijacking

投稿2023/01/01 06:41

yuma.inaura

総合スコア1453

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

EzrealTrueshot

2023/01/01 10:55

結局のところ、ブルートフォースされたらどんな機構で待ち受けていても無駄ってことですよね。 長い文字列にして、いかにブルートフォースでヒットする確率をどれだけさげられるかにつきますか。 でも、そのリスクを銀行とかの金融機関でのログインでもと考えたらちょっと怖いですよね。
yuma.inaura

2023/01/01 11:16

金融機関の場合はワンタイムパスワードなどの仕組みがあるので、振り込みなどの重要な操作ではより厳しい認証が要求されますね
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.45%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問