多くの Web アプリケーションは、近年 クレデンシャルスタッフィング攻撃を受けています。この攻撃では、露出した認証情報のデータベースから得たユーザー名とパスワードの組を使い、大量のログイン試行が行われます。
Cloudflare は、Cloudflare Web Application Firewall (WAF) で、露出した認証情報の自動チェックを提供します。
WAF はこのチェックに、次の 2 つの仕組みを使います。
-
Exposed Credentials Check Managed Ruleset — 人気の CMS アプリケーション向けの定義済みルールを含みます。ゾーンでこのルールセットを有効にすると、これらのよく知られたアプリケーションに対する露出した認証情報のチェックがすぐに有効になります。マネージドルールセットは、すべての有料プランで利用できます。
-
アカウントレベルで、独自の条件に従って露出した認証情報をチェックする カスタムルールを作成 する機能です。この設定オプションは、有料アドオン付きの Enterprise のお客様が利用できます。
Cloudflare は、露出した認証情報チェック機能を支える露出認証情報のデータベースを定期的に更新します。
平文のユーザー名とパスワードが Cloudflare ネットワークの外に出ることはありません。WAF は、以前に露出した認証情報があるかどうかを判定するとき、ユーザー名とパスワードの匿名化した版だけを使います。Cloudflare は、次のブログ記事で説明する k-Anonymity という数学的性質に基づく手法を使います。Validating Leaked Passwords with k-Anonymity ↗
WAF は、露出した認証情報を検出すると、次のいずれかのアクションを実行できます。
-
Exposed-Credential-Check Header: 露出した認証情報を含む HTTP リクエストに、新しい HTTP ヘッダーを追加します。オリジン側のアプリケーションは、パスワードリセットを強制したり、二要素認証を開始したり、その他の処理を行えます。追加される HTTP ヘッダーの名前は
Exposed-Credential-Check、値は1です。Security Events では、アクション名はRewriteです。 -
Non-Interactive Challenge: 露出した認証情報を含む HTTP リクエストを送るクライアントに、非対話型チャレンジを提示します。
-
Managed Challenge: インターネット全体で、人が CAPTCHA を解く時間を減らすのに役立ちます。リクエストの特性に応じて、Cloudflare は特定の基準に基づき適切なチャレンジ種別を動的に選びます。
-
Block: 露出した認証情報を含む HTTP リクエストをブロックします。
-
Log: Enterprise プランでのみ利用できます。露出した認証情報を含むリクエストを Cloudflare ログに記録します。より厳しいアクションに進む前に、ルールを検証する場合におすすめです。
-
Interactive Challenge: 露出した認証情報を含む HTTP リクエストを送るクライアントに、対話型チャレンジを提示します。
Exposed Credentials Check Managed Ruleset 内のルールのデフォルトアクションは Exposed-Credential-Check Header です（API では rewrite）。
次のアクションだけを使うことをおすすめします。Exposed-Credential-Check Header（API では rewrite）と Log（log）です。
Exposed Credentials Check Managed Ruleset を有効にするほか、カスタムルール でも露出した認証情報をチェックできます。よくある使い方は、アプリケーションのエンドユーザー認証エンドポイントにカスタムルールを作成し、露出した認証情報をチェックすることです。露出した認証情報をチェックするルールは、レート制限ルールより前に実行されます。
カスタムルールで露出した認証情報をチェックするには、アカウントレベルのルール定義に露出した認証情報のチェックを含め、HTTP リクエストからユーザー名とパスワードの値をどう取得するかを指定します。詳細は、露出した認証情報をチェックするカスタムルールを作成する を参照してください。