アカウントの有無によるレスポンス時間の差の調査結果

[ji-eunsoo]

概要(Overview)

パスワード再発行画面において、アカウントが存在するかどうかによってレスポンス時間が変化するため、
レスポンス速度を確認することで、存在アカウントのチェックが可能です。

再現手順(Procedure)

・結果 (4.2.3で実施した、5回の平均値を記載)

Version	接続先	ユーザー登録あり(ms)	ユーザー登録無し(ms)
4.2.3	gmail	3978	649
4.2.3	postfix	151	97

・結論

登録があるユーザーとないユーザーでは実際にResponse時間に明確に差が生じている。

環境(Environment)

EC-CUBE : 4.0.0 ~ 4.2.3
EC-CUBE : 3.x

[ji-eunsoo]

以下、検討してみました。

A案：全体の処理時間を決め、レスポンスを同じ時間内に処理する（レスポンスの同時性確保）

• パスワードリセット1件あたりの処理時間がかかる可能性があり、レスポンスの時間がかかるようになる
• DoS攻撃の影響が出やすい可能性があるため、見送り

B案：登録なしのメールアドレスの場合、ダミーのメールアドレスに実際にメール送信を行う

• 攻撃が来たことがわかるメリットがあるが、ダミーのメールアドレスのメールボックスが溢れる可能性もある
• 特定のアカウントに存在しないメールを送ることは避けたいため、見送り

C案：メッセージキューを使用して非同期でメールを送信する

• 共有レンタルサーバーでの稼動を想定しているため、メッセージキューの利用が難しい
• 一部の共有レンタルサーバーでは、WebサーバーからPHPのCLI版のコマンドを呼び出せない場合があるため、見送り

[ji-eunsoo]

4.2からは新規会員登録画面・パスワード再発行画面にスロットリングを実装しており、リスクを低減できている状態となります。

また、会員の登録有無が特定される問題は、新規会員登録画面においても同様の事象があります。
こちらは、他のサービスとも比較した結果、仕様として情報を公開しております。
#5279

ことから、本件は脆弱性としては扱わず、不具合として今後のバージョンで修正を実施できればと考えております。

是非、修正案についてご意見ください！

[mipsparc]

脆弱性報告したものです。

他の画面にもあり、仕様として公開されていて、さらに上記案も難しいようなら、何もできることはなさそうな気もしますね...

[mipsparc]

ちなみに、スロットリング(IPアドレスごとにレートリミット)は、大量のIPアドレスから試行する方法がありふれているので、なんらかのCAPTCHAを仕込むのがいいと思います

[ji-eunsoo]

@mipsparc
ありがとうございます、おっしゃるとおりかと思います。
recapthaはプラグインとしていくつかリリースされており、そちらと合わせて対策されている方もいらっしゃいますね。