アカウント名:
パスワード:
[独自記事]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 のアクセ
7iDのAPIは認証通れば、フル住所・生年月日・メールアドレス・電話番号・パスワードハッシュ他、あらゆる情報全取得可能。
証拠https://pbs.twimg.com/media/D-yY32pU0AAXuxl.jpg:large [twimg.com]https://pbs.twimg.com/media/D-yY32pU0AAXuxl.jpg:large [twimg.com]
認証通っているなら良いのでは? というのは間違い。だって、7iDのパスワードと追加認証の決済パスワードが同じなら、パスワードハッシュから解析できてしまうし(弱いパスワードはハッシュからでも解析可能)、APIから取得できる情報が、決済パスワードリセットの本人確認情報にもなるので、そこから攻めることもできる。
OpenID Connect (OIDC) 1.0 準拠の分権的な認証プロトコルのオープンスタンダードを採用と聞くと、モダンで最先端なスラド民が喜びそうだが、大した知識がないのにそういう最先端の実装をすると、個人情報も何もかもオープンになってしまうのである。omni7を認証基盤にして、シンプルで最先端でかっこよいシステムを作ろうとして墓穴を掘った感じ。
たいしたスキルも無いのに、オープンソースとか、オープンスタンダードだとか、そういうのを重視する「意識高い系」の人は大迷惑。
最先端のシステム(OpenID Connectやら7iD認証基盤)を導入せずに、素直に独自のIDとパスワードで認証して、初回設定時と新規ログイン時にはSMSで確認コードを送る(二段階認証)という、古臭くてレガシーな仕様にしとけばこんな問題(不正ログインや不正チャージなど)はおきなかった。
画像のURLミスっておんなじ画像になってたので修正
sp-api.omni7.jpのAPIにトークン投げた結果
証拠画像1: https://pbs.twimg.com/media/D-yY32pU0AAXuxl.jpg:large [twimg.com]証拠画像2: https://pbs.twimg.com/media/D-yY4uKVUAEzApG.jpg:large [twimg.com]証拠画像3: https://pbs.twimg.com/media/D-1pQMHUIAEYw-7.jpg:large [twimg.com]
技術者としてはJSONでこう綺麗にあらゆるデータがまとまって返ってくるのは気持ちいいんんですけどねクラッカーにとっても気持ちいい設計です
firstNameKana: ラlastNameKana: マとは?
何がおかしいのか分からないんだが……
こういうのってACCS不正アクセス事件みたいに不正アクセス禁止法違反にならんの?
まあ今のセブンの立場で実験者告発してたらノンストップ炎上になるとは思うが(やらない保証はない)。
ACCS不正アクセス事件じゃ、試験目的だから良いだろ~ってノリで試験して実証したらACCSが告発して研究員刑事処分されたしなあ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
パスワードなしで他人のアカウントにログインできた (スコア: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 のアクセ
トレンドに乗ろうとして、最先端の認証プロトコルのオープンスタンダードを採用するから…… (スコア:2, 参考になる)
7iDのAPIは認証通れば、フル住所・生年月日・メールアドレス・電話番号・パスワードハッシュ他、あらゆる情報全取得可能。
証拠
https://pbs.twimg.com/media/D-yY32pU0AAXuxl.jpg:large [twimg.com]
https://pbs.twimg.com/media/D-yY32pU0AAXuxl.jpg:large [twimg.com]
認証通っているなら良いのでは? というのは間違い。
だって、7iDのパスワードと追加認証の決済パスワードが同じなら、パスワードハッシュから解析できてしまうし(弱いパスワードはハッシュからでも解析可能)、
APIから取得できる情報が、決済パスワードリセットの本人確認情報にもなるので、そこから攻めることもできる。
OpenID Connect (OIDC) 1.0 準拠の分権的な認証プロトコルのオープンスタンダードを採用と聞くと、モダンで最先端なスラド民が喜びそうだが、大した知識がないのにそういう最先端の実装をすると、個人情報も何もかもオープンになってしまうのである。
omni7を認証基盤にして、シンプルで最先端でかっこよいシステムを作ろうとして墓穴を掘った感じ。
たいしたスキルも無いのに、オープンソースとか、オープンスタンダードだとか、そういうのを重視する「意識高い系」の人は大迷惑。
最先端のシステム(OpenID Connectやら7iD認証基盤)を導入せずに、素直に独自のIDとパスワードで認証して、初回設定時と新規ログイン時にはSMSで確認コードを送る(二段階認証)という、古臭くてレガシーな仕様にしとけばこんな問題(不正ログインや不正チャージなど)はおきなかった。
素晴らしいAPIとJSONの活用 (スコア:2, 参考になる)
画像のURLミスっておんなじ画像になってたので修正
sp-api.omni7.jpのAPIにトークン投げた結果
証拠画像1: https://pbs.twimg.com/media/D-yY32pU0AAXuxl.jpg:large [twimg.com]
証拠画像2: https://pbs.twimg.com/media/D-yY4uKVUAEzApG.jpg:large [twimg.com]
証拠画像3: https://pbs.twimg.com/media/D-1pQMHUIAEYw-7.jpg:large [twimg.com]
技術者としてはJSONでこう綺麗にあらゆるデータがまとまって返ってくるのは気持ちいいんんですけどね
クラッカーにとっても気持ちいい設計です
Re: (スコア:0)
firstNameKana: ラ
lastNameKana: マ
とは?
Re: (スコア:0)
何がおかしいのか分からないんだが……
Re: (スコア:0)
こういうのってACCS不正アクセス事件みたいに不正アクセス禁止法違反にならんの?
まあ今のセブンの立場で実験者告発してたらノンストップ炎上になるとは思うが(やらない保証はない)。
ACCS不正アクセス事件じゃ、試験目的だから良いだろ~ってノリで試験して実証したらACCSが告発して研究員刑事処分されたしなあ。