「米シティグループ顧客情報流出、その手口は単純だった」記事へのコメント

どうしてこうなったか推理してみるテスト

[esumi (15966)]

・当初は、submitの際、ユーザー認証に必要な情報も常に同時送信され、認証も都度行う仕様で一応記事のような問題は起きない状態だった
・が、時代の移り変わりと共に、セキュリティ・カードが導入されるようになり、認証は１度で済ますよう、途中で変更が加えられた
・その時深く考えずに認証後の口座情報引き出し部の仕様のみ従来のままで変更せず通してしまった
・気付かない　＞　ｵｱｰ

＃認証後はﾗﾝﾀﾞﾑに作成された英数字をｸﾗｲｱﾝﾄに渡し、その英数字と口座番号等の情報をログアウトまで一時的にｻｰﾊﾞ側で紐付け記憶させとけば良かったですかね

Re:

[Ryo.F (3896)]

＃認証後はランダムに作成された英数字をクライアントに渡し、その英数字と口座番号等の情報をログアウトまで一時的にサーバ側で紐付け記憶させとけば良かったですかね

そのランダムコードをブルートフォース攻撃されたりして。

Re:

[Anonymous Coward]

セッションの存続時間と、攻撃に必要な時間を天秤にかけて
安全性を担保していることを理解していますか？

Re:どうしてこうなったか推理してみるテスト

[Ryo.F (3896)]

セッションの存続時間と、攻撃に必要な時間を天秤にかけて安全性を担保していることを理解していますか？

はい。理解しています。ランダムコードが十分に長ければ、被害は少なくなるとは思います。でも、そこを明らかにしておかないと、無意味とまでは言いませんけど、被害が出やすくなってしまいますね。
そもそも、そのセッションと、そのセッションからアクセスできる口座番号を結びつけて管理しておくべきではないですか？
#1970960 [srad.jp]では、ランダムコードの長さも、セッションと口座番号との関連付けも、言及されていませんね。

しかし、セッション云々と言うのなら、新たなランダムコードなんか必要ないとも思いますが。ユーザ対口座が1:nの関係だったとしても、その口座を切り替える処理があればいいような気がします。

Re:

[Anonymous Coward]

理解しているかという質問は
セッションIDにブルートフォース攻撃とはどういうことなの？
という意味でしょう。

Re:どうしてこうなったか推理してみるテスト

[Ryo.F (3896)]

セッションIDにブルートフォース攻撃とはどういうことなの？

セッションIDへのブルートフォース攻撃は、ありえますよ。まともに生成されたセッションIDなら、その危険性は十分に下がるというだけです。
それが、セッションとの関連が定かではない「口座番号等の情報」と関連付けられた「ランダムに作成された英数字 [srad.jp]」程度思い付きだと、どんな攻撃を防ぎ得るかも定かではありません。そもそも、セッションIDですらありませんしね。
そんな面倒なことをするよりは、もっといい方法がありそうですよね。