Use Enumeration in the login process から学ぶ - The light of hope to the other side of the tunnel

ソース：

脆弱性：情報漏洩

訳：

サーバーの応答時間

アプリケーションのログインセクションの評価中に、存在しないユーザー名を使用した場合の応答の速さと比較して、既存のユーザー名を使用した場合の読み込みアニメーションの顕著な遅延が観察されました。
この矛盾をさらに詳しく調べるために、実際の応答時間を調査するリクエストをリピーターに送信しました。

Burp の右下隅では、サーバーがリクエストに対する応答を送信するのにかかった時間を示す時間を監視できます。

既存のユーザー名と存在しないユーザー名の両方を使用してリクエストをディスパッチすると、応答時間が大幅に異なることに気づきました。
既存ユーザーのリクエストには約 520 ミリ秒かかりましたが、存在しないユーザーのリクエストはわずか 40 ミリ秒で完了しました。

- Response time ~520ms

POST /user/login HTTP/2
Host: <redacted>
Content-Length: 56
Content-Type: application/json

{"username":"DoesExist","password":"SomePassword"}

- Response time ~40ms

POST /user/login HTTP/2
Host: <redacted>
Content-Length: 56
Content-Type: application/json

{"username":"DoesNotExist","password":"SomePassword"}

この応答時間の不一致は、データベース内でユーザーが見つかった場合にのみアプリケーションがパスワードチェックを実行するという事実に起因すると考えられます。

この問題に対処するには、応答時間を 1 秒に正規化することで変動の影響を軽減し、より一貫したユーザーエクスペリエンスを確保することが考えられます。

ロックアウトエラーメッセージ

ログイン試行が 5 回連続して失敗した後に 2 つの異なるロックアウトエラーメッセージが表示される場合、アプリケーション内でのユーザー列挙に対する別のアプローチが発生します。
ユーザー名とパスワードの間違った組み合わせがアプリケーションに入力されると、ログインを試みるたびに「ユーザー名またはパスワードが間違っています」というエラーメッセージが表示されます。
ただし、正しいユーザー名を入力すると、ログイン試行が 5 回連続して失敗すると、「ログイン試行の失敗が多すぎるため、ロックアウトされました」というエラーメッセージが表示されます。
特に、この特定のエラーメッセージは、間違ったユーザー名が使用された場合には表示されません。
したがって、攻撃者はランダムなパスワードでログインを 5 回試行し、エラーメッセージを識別することでユーザー名を列挙できる可能性があります。
メッセージに「ユーザー名またはパスワードが間違っています」と表示されている場合は、ユーザー名が間違っています。
逆に、「ログイン試行の失敗が多すぎるためロックアウトされました」と表示されている場合は、ユーザー名は正しいです。
この問題の解決策は、一貫したエラーメッセージを実装し、ログインプロセス中の既存ユーザーと存在しないユーザーの区別をなくすことにあります。
これにより、潜在的な攻撃者が異なるエラーメッセージに基づいて有効なユーザー名を識別することができなくなり、セキュリティが強化されます。

Web サイトでユーザー名を列挙するための、やや型破りな 2 つの方法を検討してきました。
これらの例は、応答時間やわかりやすいエラーメッセージなど、一見些細な詳細に注意を払うことの重要性を示しています。
このような小さなニュアンスによって、重要な情報が潜在的な攻撃者に誤って漏洩してしまう可能性があります。

ほなほな。