アカウント名:
パスワード:
［独自記事］7pay不正利用問題、「7iD」に潜んでいた脆弱性の一端が判明 https://tech.nikkeibp.co.jp/atcl/nxt/news/18/05498/ [nikkeibp.co.jp]
が分かりやすいです。
ただし、上記記事は、全く異なる2つの脆弱性の話が書かれているので、混同しないようにご注意ください。
【脆弱1 : OpenID Connectのアクセストークン未検証】
OpenID Connectのアクセストークンを検証していなかったので、ID（メールアドレス等）さえわかれば、パスワードが分からなくても、OAuthが成功したことにして他人がログインできる脆弱性があった。あまりにも酷すぎる脆弱性ですね！
【脆弱性2 : 7iD の API のアクセ
結局のところ、7payは、OAuthの認証が成功したというデータを送り付けるだけで、OpenIDのID(メールアドレス等)が分かるだけでログインできたのでした。
つまり、チャージされた残高は、メールアドレスさえわかれば、第三者が使用可能でした。
そして、登録されているクレジットカードからのチャージには、OpenIDでログインした場合を含めて追加で認証パスワードが必要なのですが、OpenIDでログインした状態ならば画面に表示される、お問い合わせ番号、7iDメアド、nanaco番号（すべてアプリに表示）だけあれば、それもリセットできました。https://twitter.com/ppp_payland/status/1146924240970514432 [twitter.com]
7payの悪用はリスト型攻撃だと言われてましたが、メールアドレスとパスワードのリストではなく、メールアドレスだけのリストで攻撃可能だったのです。
まぁ、リスト型攻撃には変わりないといったら変わりないのですが……。
すげーなー、というしかないなぁ。7payと社長が矢面に立たされ袋叩きにされたけど、実際はベンダーの方の責任の可能性が高いってことか。今後のことを考えると、どこなのか公開して欲しいところ・・・
でも、その成果物を受け取って検収し、サービスインしたのは7-11側なので一義的に責任は7-11側にある。どこがベンダーであっても一緒ですよ。それをもってサービス提供側をを甘やかしてはならない。
確かにそうだが、検証できるだけの技術ある人もいないだろうに。まぁそれが問題なんだけど。
なんで日本の大企業は自分とこで技術者抱えて作ろうとしないんだろ。本当にバカだよねぇ。
脳筋脳花企業では往々にしてシステム屋と言う「何か訳のわからん事をやっている奴ら」は隅っこに追いやられるか、子会社に追放される。
そういう業者に発注したのもセブン側でしょ。
とりあえずモックだけ作って本格実装は後回しにして開発進めていたら、その開発期間では無理です、実装が間に合いませんと問題を申告した技術者が本部の意向で左遷されて、後任のYESマンはなにもわからず本部の言われるとおりにした結果、本番環境でもモックのままサービスインしてしまった．．．みたいなことだって、ありえるんだから。
合言葉は「動いているから良いじゃない」。
責任者が被害しゃぶるのは良くないよ。
苦汁「しゃぶれよ」
あるいは発注者側責任者『何か起きたら全部責任は俺が取る！』と豪語する↓900件5500万円のクラック被害発生、セブングループとコード決済の信用が地に落ちる↓発注者側責任者『』、あるいは他グループ、競合他社に夜逃げ、あるいは首吊り自殺
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
パスワードなしで他人のアカウントにログインできた (スコア:5, 参考になる)
［独自記事］7pay不正利用問題、「7iD」に潜んでいた脆弱性の一端が判明
https://tech.nikkeibp.co.jp/atcl/nxt/news/18/05498/ [nikkeibp.co.jp]
が分かりやすいです。
ただし、上記記事は、全く異なる2つの脆弱性の話が書かれているので、混同しないようにご注意ください。
【脆弱1 : OpenID Connectのアクセストークン未検証】
OpenID Connectのアクセストークンを検証していなかったので、ID（メールアドレス等）さえわかれば、
パスワードが分からなくても、OAuthが成功したことにして他人がログインできる脆弱性があった。
あまりにも酷すぎる脆弱性ですね！
【脆弱性2 : 7iD の API のアクセ
メールアドレスだけで決済もクレジットカードチャージも可能 (スコア:5, 参考になる)
結局のところ、7payは、OAuthの認証が成功したというデータを送り付けるだけで、OpenIDのID(メールアドレス等)が分かるだけでログインできたのでした。
つまり、チャージされた残高は、メールアドレスさえわかれば、第三者が使用可能でした。
そして、登録されているクレジットカードからのチャージには、OpenIDでログインした場合を含めて追加で認証パスワードが必要なのですが、
OpenIDでログインした状態ならば画面に表示される、お問い合わせ番号、7iDメアド、nanaco番号（すべてアプリに表示）だけあれば、それもリセットできました。
https://twitter.com/ppp_payland/status/1146924240970514432 [twitter.com]
7payの悪用はリスト型攻撃だと言われてましたが、メールアドレスとパスワードのリストではなく、メールアドレスだけのリストで攻撃可能だったのです。
まぁ、リスト型攻撃には変わりないといったら変わりないのですが……。
Re: (スコア:0)
すげーなー、というしかないなぁ。
7payと社長が矢面に立たされ袋叩きにされたけど、実際はベンダーの方の責任の可能性が高いってことか。
今後のことを考えると、どこなのか公開して欲しいところ・・・
Re:メールアドレスだけで決済もクレジットカードチャージも可能 (スコア:1)
でも、その成果物を受け取って検収し、サービスインしたのは7-11側なので一義的に責任は7-11側にある。
どこがベンダーであっても一緒ですよ。それをもってサービス提供側をを甘やかしてはならない。
Re: (スコア:0)
確かにそうだが、検証できるだけの技術ある人もいないだろうに。まぁそれが問題なんだけど。
なんで日本の大企業は自分とこで技術者抱えて作ろうとしないんだろ。
本当にバカだよねぇ。
Re: (スコア:0)
脳筋脳花企業では往々にしてシステム屋と言う「何か訳のわからん事をやっている奴ら」は隅っこに追いやられるか、子会社に追放される。
Re: (スコア:0)
そういう業者に発注したのもセブン側でしょ。
とりあえずモックだけ作って本格実装は後回しにして開発進めていたら、その開発
期間では無理です、実装が間に合いませんと問題を申告した技術者が本部の意向で
左遷されて、後任のYESマンはなにもわからず本部の言われるとおりにした結果、
本番環境でもモックのままサービスインしてしまった．．．
みたいなことだって、ありえるんだから。
合言葉は「動いているから良いじゃない」。
責任者が被害しゃぶるのは良くないよ。
Re: (スコア:0)
苦汁「しゃぶれよ」
Re: (スコア:0)
あるいは
発注者側責任者『何か起きたら全部責任は俺が取る！』と豪語する
↓
900件5500万円のクラック被害発生、セブングループとコード決済の信用が地に落ちる
↓
発注者側責任者『』、あるいは他グループ、競合他社に夜逃げ、あるいは首吊り自殺