session、クッキーの推測によるWebサイトへのログイン

Question

python の flask でsessionを設定しているのですが、クライアント側でsession値を書き換えることで簡単に他者になりすますことができてしまうのではないでしょうか？

銀行などのお金を扱う会社は責任がとても大きいと思うのですが、もしかして私の知らない方法がまだあるのでしょうか？

@app.route('/login', methods=['POST'])
def login_post():
    uid = request.form["uid"]
    pwd = request.form["pwd"]
 
    #ユーザが登録済みであった場合
    if uid in user_data:
        # IDとパスワードの組み合わせが合っていれば、ログイン済みにする
        if user_data[uid] == pwd:
            session["flag"] = True
        #　ログイン済みにしない
        else:
            session["flag"] = False
    #ユーザが登録していなかった場合、登録してログイン済みにする
    else:
        user_data[uid] = pwd
        session["flag"] = True
 
    session["uid"] = uid
 
    if session["flag"]:
        return redirect("/")
    else:
        return render_template("login.html",
                               title="ログインページ",
                               message="パスワードが違います")

質問
ステートフルなWebサイトを実装した場合に、推測によるセッションハイジャックを防ぐ方法があるようでしたらご教示いただけませんでしょうか？
そんなものはないという回答でも構いません。

よろしくお願い致します。

Answer 1

推測によるセッションハイジャックを防ぐ方法があるようでしたらご教示いただけませんでしょうか？

セッションキーを「品質の充分な暗号学的疑似乱数」で「充分な長さ」のものにしておけば、推測する手がかりはありませんし、総当りしたところでまず当たりません。

Comments

[maisumakun]

「総当りすれば当たる」というのは、総当たりにかかる時間が現実的な場合にのみ脆弱性と考えられます。

どれだけ桁が大きくても、一発で当てる確率は理論的には0ではありませんが、桁数を伸ばせばその可能性は指数関数的に減りますので、隕石が当たってサーバが壊れるリスクより小さくできます。

[EzrealTrueshot]

なるほどですね！
ありがとうございます。
それでも、総当たりで試していそうな悪者は世の中に存在してそうですよね。
その場合は、IPアドレスか何かではじくような設定を入れ込むなどして対策しているのでしょうか？

[maisumakun]

そんな攻撃をするよりもっと割のいい方法がありますので、「ランダムかつ一時的なセッションキーを狙い撃つ」ような攻撃は現実的な脅威ではありません。

ビットコインのマイニングもハッシュ値をある特定の範囲内に抑えたブロックを見つけ出す作業ですが、キー1つを探す作業はそれよりなお分が悪いです。

[maisumakun]

特定のターゲットがいるなら、ソーシャルエンジニアリング・買収・標的型攻撃といった手段のほうが効果的です。

[otolab]

対策としては、maisumakunさんの言うように十分にランダムに長くすること、セッションの期限を設けること。

それから総当たり時に発生するセッションIDのエラーをちゃんと見張って遮断できる仕組みを作っておくこと（その場合にはIPではじくのは良くある手）。

総当たりの対象数を増やす（法則のない良いランダムにする、桁を増やす）、総当たりの回数を減らす（時間切れを作る、頻度を制限する）。ということをやって理論上十分安全であるとみなせれば良いわけです。

あと正直、セッションIDよりパスワードの方がずっと脆弱です。

[退会済みユーザー]

> あと正直、セッションIDよりパスワードの方がずっと脆弱です。

これ、総当たりに対しての桁数の話なんだと思いますけど、同じ土俵で語る内容ではないと思いますよ。
パスワードは一般的にハッシュ化されているでしょうし、その際、ストレッチングを行い、総当たり攻撃に対して時間がかかる仕組みが取り入れられていたりします。

また、ユーザ入力桁数としても最近は制限をあまり見なくなった気がします。
session id と同等程度の桁数を設定している人もそれなりにいるかと。

[otolab]

「パスワードの方が脆弱」というのは言葉足らずでした。ずっと強度の低い値が容易に設定でき、たいていはずっと脆弱な値が使われている。という意図でした。

単純な強度という意味では、たかだか20桁のランダムな文字列というだけでかなり強いです。

https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/303.html

> 例えば、英数小文字大文字で20桁の値を考えた場合、組み合わせとしては「(26+26+10)^20」通りとなる。

https://www.jagat.or.jp/2020cm_securepassword

> 現在は、文字種を増やすよりも文字数を多くしたパスワードのほうが強固であるとされています。つまり「J41g2@t3」のような記号や数字を混ぜた8文字のパスワードよりも、「irohanihoheto」のような記号を使わない12文字以上のパスワードのほうがセキュリティ強度が高いとして推奨されています。

パスワードを十分長く強くすることは（ユーザに依存するため）現実的には難しいので、試行回数を制限するなどしてその弱さを補っていると見なすことができます。対してセッションIDはシステム内部で作られるので、必要があればいくらでも伸ばせます。

最近のパスワードスプレー攻撃などパスワードを狙った手口は多いですが、セッションIDを狙った攻撃というのはあんまり聞いた覚えがありません。

セッションIDを利用する攻撃はセッション固定化攻撃などがあるようですが、総当たりとは異なるタイプの攻撃みたいです。
https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/305.html

[退会済みユーザー]

> 最近のパスワードスプレー攻撃などパスワードを狙った手口は多いですが、セッションIDを狙った攻撃というのはあんまり聞いた覚えがありません。

まぁそうでしょうね。フレームワークや言語の標準的な session 機構を使用している限り、適切な処理がなされているので。
逆説的ですが、自作 session 機構を使用すると、総当たりが十分現実的な脅威になります。
maisumakun が言っている「品質の充分な暗号学的疑似乱数」で「充分な長さ」あたりが適切でなければ、そこそこ攻撃しやすいものとなります。

> パスワードを十分長く強くすることは（ユーザに依存するため）現実的には難しいので、

そーでもないです。短い password に salt & pepper でゲタはかせるとか、「ブラウザに記憶させるんだから長くていいよね」とかいろいろ対策はあるかと。(salt & pepper はオフライン攻撃対策だからまたちょっと違うか＾＾；)

いずれにしても、session id と password は、同じ土俵で語る内容ではないと思います。
コンセプトも攻撃手法も違うので。

余談)
> セッションIDを利用する攻撃はセッション固定化攻撃などがあるようですが、総当たりとは異なるタイプの攻撃みたいです。

あと、XSS がやばいですね。