アカウント名:
パスワード:
[独自記事]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 のアクセスコントロールがガバガバな仕様】これを脆弱性と呼んでる人たち正直技術者としては二段階認証を知らない社長と同レベルでは?という疑問がある問題が切り分けできないなら技術的なこと喋るのやめたほうがいいですよ。
技術者得意の答え『それは仕様です』って奴ですか?
ま7iD側がID Providerやるケースはレアケースで、実際にそれを設定していたユーザもごく少数でしょうから、900件の情報漏えいルートとしての可能性は低いでしょう。
ただし、この脆弱性だけでも(5500万円損害事故が起きて無くても)個人情報漏洩事故として官庁(内閣府個人情報保護委員会等)に対し速やかに報告が義務付けられるレベルだけど!?
んー、情報が全部取れ流のは最悪仕様としてもパスワードハッシュが取れるのは脆弱性かな? 不必要だし。とはいえ、脆弱性1に比べれば大した話では無い。監査とかでは指摘あると思うけどね。このレベルでも。事業者側でリスク判断レベルで。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
パスワードなしで他人のアカウントにログインできた (スコア: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 のアクセ
Re:パスワードなしで他人のアカウントにログインできた (スコア:0)
>【脆弱性2 : 7iD の API のアクセスコントロールがガバガバな仕様】
これを脆弱性と呼んでる人たち正直技術者としては二段階認証を知らない社長と同レベルでは?という疑問がある
問題が切り分けできないなら技術的なこと喋るのやめたほうがいいですよ。
Re: (スコア:0)
技術者得意の答え『それは仕様です』って奴ですか?
ま7iD側がID Providerやるケースはレアケースで、実際にそれを設定していたユーザもごく少数でしょうから、900件の情報漏えいルートとしての可能性は低いでしょう。
ただし、この脆弱性だけでも(5500万円損害事故が起きて無くても)個人情報漏洩事故として官庁(内閣府個人情報保護委員会等)に対し速やかに報告が義務付けられるレベルだけど!?
Re: (スコア:0)
んー、情報が全部取れ流のは最悪仕様としてもパスワードハッシュが取れるのは脆弱性かな? 不必要だし。
とはいえ、脆弱性1に比べれば大した話では無い。監査とかでは指摘あると思うけどね。このレベルでも。事業者側でリスク判断レベルで。