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

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

[esumi (15966)]

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

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

Re:

[Ryo.F (3896)]

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

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

Re:

[esumi (15966)]

普通、そういった一致のチェックを何度も連続失敗した場合、一時的にロック掛けるのが昨今では普通ではないでしょうか

＃今時だとブルートフォース攻撃を許す認証の仕様そのものがそもそも間違いだと思うんだ

Re:

[Ryo.F (3896)]

普通、そういった一致のチェックを何度も連続失敗した場合、一時的にロック掛けるのが昨今では普通ではないでしょうか

「普通」が重なってるよ。というのはさておき。

そんなチェックをするくらいだったら、クライアントからのデータに関係なく、そのセッションがアクセス中の口座番号をサーバ内で管理した方がよくない？

それに、セッションIDがあるのに、わざわざ別にランダムコードを準備するのは普通なの？
単にランダムコードって言うけど、実は乱数生成ってそんなに簡単じゃない。下手な方法を使うと、ブルートフォース攻撃どころか、予測

Re:

[esumi (15966)]

>そんなチェックをするくらいだったら、クライアントからのデータに関係なく、そのセッションがアクセス中の口座番号をサーバ内で管理した方がよくない？
そう言ったつもりだったんだけど言い方おかしかったのかなぁ

＃なんでそんな細かいところに拘るのかイマイチ解りませんがこれで手打ちにして良いですか？

Re:

[Ryo.F (3896)]

そんなチェックをするくらいだったら、クライアントからのデータに関係なく、そのセッションがアクセス中の口座番号をサーバ内で管理した方がよくない？

そう言ったつもりだったんだけど言い方おかしかったのかなぁ

言い方がおかしいね。元のコメントには、

認証後はランダムに作成された英数字をクライアントに渡し

で、「クライアントからのデータに関係なく」なんて内容ではないね。

＃なんでそんな細か

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

[esumi (15966)]

すみませんそもそも仕事でも無いですし、私は貴方のようにそんな真剣に本件に取り組めません。
なので、このスレ上で完璧な対処や実装を模索されるのは貴方にお任せします。どうぞ拘りを持って気が済むまでどうぞ。

＃どうせ堅いレスが入ってるんだろうなぁと思い、嫌になった為見返すのが遅くなり真に申し訳ありませんでした
＃もっとも回答を遅らせた以外については全く悪いとは思ってませんが

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

[Ryo.F (3896)]

すみませんそもそも仕事でも無いですし、私は貴方のようにそんな真剣に本件に取り組めません。

謝罪には及ばないと思いますよ。
ただ、esumi説がその程度のいい加減さだった、ということが判ったので、それで十分なんじゃないかと思います。

なので、このスレ上で完璧な対処や実装を模索されるのは貴方にお任せします。

いやいや。私の意見など、所詮実際に実装をしない素人の意見に過ぎませんよ。現実は、もっと厳しいって事です。
もちろん、esumiさんが考えてるよりもっと、と言う意味でもありますが。