Cloudflare Advent Calendar 2025

Cloudflareで"流出済みパスワード使い回し"を止めてみる～Leaked credentials detection活用編～

Last updated at 2025-12-10Posted at 2025-12-10

みなさんこんにちは。
アドカレ用の記事を書こうと思った矢先、某脆弱性の対応でだいぶ時間を持っていかれました。
今回は完全な新規ネタではありませんが、アップデートされてより活用しやすくなったクラウドフレアの"Leaked credentials detection"を改めて触ってみました。

本記事は2025/12時点の確認結果を元に記載しています。進化の早いクラウドサービスに関連する情報ですので、仕様は随時変化していく可能性がある点にご注意ください。

Leaked credentials detectionとは？

この機能は、Cloudflare が「認証リクエスト」と判断したトラフィックに対し、

抽出したユーザー名・パスワード (※恐らくハッシュ値)
既知の漏洩リスト

を照合して、その結果を Exposed-Credential-Check ヘッダを付与する仕組みです。

検出結果はカスタムルールやレート制限ルールにおいてルールの条件として利用できるので、例えばレート制限ルールと組み合わせて 「パスワードリスト攻撃の兆候を検知する」 みたいな活用ができそうです。
※注意: ユーザーとパスワードの組み合わせによる条件は、Proプラン以上で使用できるようです。

機能の詳細や設定方法については以下の記事が参考になると思います。

どのパラメータがユーザー名・パスワードとして扱われる？

ここで気になるのが、
「クラウドフレアは認証リクエストのどのパラメータをユーザー名・パスワードとして扱っているのか？」
という点ですよね。

公式ドキュメントによると、デフォルトでは Joomla! や WordPress などの一般的なCMS、
Webアプリケーションでよく使われるパラメータ名がスキャン対象として登録されているようです。
参考: Cloudflare Docs: Default scan locations

一方で、アプリケーションが独自のパラメータ名を使っている場合は、Enterpriseプランにおいて、カスタムのパラメータを設定できる機能も提供されています。
参考: Cloudflare Docs: Custom detection locations

カスタムのパラメータはクラウドフレアダッシュボードの
セキュリティ > 設定 > 漏洩した資格情報の検出 > 構成 でカスタムの構成を設定できます。
「カスタムパラメータの追加」が可能になったことで、エンタープライズ環境ではより実用度が上がった印象です。

アプリケーションに組み込んで試してみた

ここからは、せっかくなのでアプリケーション側でどう活用できるかを試してみた話です。

今回は「ユーザー登録画面」において、
利用者が流出済みのユーザー名・パスワードを使いまわして登録しようとした場合に警告を表示する
という動きを試してみました。

検証はWordPressのユーザー作成画面(user-new.php)を題材にしています。

1. カスタムのパラメータをクラウドフレアに登録

ユーザー登録は認証リクエストとは異なるため、当然ながらクラウドフレアのデフォルト設定では認証リクエストとして識別されませんでした。
そこで、ユーザー作成画面で使用されているパラメータ

ユーザー名：user_login
パスワード：pass1

をクラウドフレアにカスタムパラメータとして追加します。

2. Exposed-Credential-Check ヘッダを付与するようにクラウドフレアを設定

ルール > 設定 > Managed Transforms の画面にある
「漏洩した資格情報チェックヘッダーを追加する」
を有効化します。
参考: Cloudflare Docs: Add leaked credentials checks header

3. アプリ側でヘッダをチェック

続いて、ユーザー作成処理の中で Exposed-Credential-Check ヘッダの値を確認する処理を、プラグインとして追加してみました。
※あくまでも今回の検証用に簡易的に用意したものです。

wp-content/plugins/exposed-cred-check/exposed-cred-check.php

add_action('user_profile_update_errors', function($errors, $update, $user) {
    // ～～一部抜粋～～
    // ヘッダ値が "1" の場合、パスワードに対してエラーを追加する
    if ($_SERVER['Exposed-Credential-Check'] === '1') {
        $errors->add(
            'exposed_cred_check',
            __('Please use a different password.')
        );
    }
    // ～～一部抜粋～～
}, 10, 3);

実際にテストしてみる

クラウドフレアが公開している検出テスト用の認証情報でユーザー登録しようとすると...

想定通り、警告メッセージが表示され、登録処理を止めることができました！

参考: この時のオリジンサーバ側のHTTPリクエストログ。cf.waf.credential_checkが"1"となっています。
※一部を抜粋。IPアドレスやホスト名などはサンプル値に置換しています。

access.log

[09/Dec/2025:15:49:22 +0900] "POST /wp-admin/user-new.php HTTP/1.1" 200 125208 443 "cf.waf.credential_check:1"

まとめ

クラウドフレア側の設定はとてもシンプルで、アプリケーション側を工夫することで

二段階認証の要求
パスワードの再設定を求める

など、いろいろな応用ができそうだなと感じました。

クラウドフレアを使用している方は、ぜひ一度動作を確かめつつ、自社アプリへの組み込みも試してみてください！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

Cloudflareで"流出済みパスワード使い回し"を止めてみる ～Leaked credentials detection活用編～