ハクソク

世界を動かす技術を、日本語で。

ウェブセキュリティは難しすぎる

2026年8月5日原文(textslashplain.com)

概要

Cloudflareの新機能に関するツイートから始まった体験談。 新しいドメインやUIがフィッシング攻撃に見えた経緯。 最終的には正規の新サービスだったことが判明。 Web開発者・ユーザー・セキュリティ関係者への教訓。 実際の事例を通じてセキュリティUIの重要性を訴求。

Cloudflare新機能の“フィッシング”疑惑体験

  • Cloudflare の新製品リリースのツイートを発見、興味を持ちサイトへアクセス

  • 自分の希望する @ericlaw ハンドルがまだ取得可能、急いで確保しようと決意

  • 既存ユーザーのため、 Cloudflareアカウント でサインインを求められる流れ

  • 新機能の認可が必要と表示、ここまでは一般的な手順

  • しかし、 cloudflare.pay という見慣れないドメインへの遷移に違和感

    • cloudflare.com 配下ではなく、.payドメインは誰でも取得可能なため信頼性に疑念
    • .bankなどと異なり、 .pay は特別な審査なしで取得可能

  • 許可画面の 緑色チェックマーク やUIが、過去のConsent Phishing手法と酷似

    • 攻撃者がアイコンや表示名に偽装要素を仕込むのと同じパターン
    • Microsoft Outlook のOAuthフィッシングの事例を想起

  • Cloudflareのようなセキュリティ重視の企業でも、 「これは攻撃だ！」 と直感

    • 競争心を煽られ急いでしまう心理的な罠

  • 許可画面に 「不審なリクエストを報告」 するリンクがない

    • ダッシュボードからWallet機能を探すが見つからず、ドキュメントにも情報なし

  • チャットAIに質問するためアクセス許可を求められるが、 最初にフルコントロールを提案

    • 最小権限の原則に反する設計と感じる

  • 結果、 Cloudflare公式も「攻撃の可能性」と回答

    • すぐにフィッシング報告を試みるが、後で正規サービスと判明
    • 緑チェックマーク は本来のセキュリティUI要素だったが、配置が悪く誤解を招いた

  • セキュリティ報告は HackerOne 経由だが、CAPTCHAの不具合でログイン不可

正規サイトが“フィッシング”に見える難しさ

  • 正規サイトでも フィッシングに見えるUI/UX が存在
  • URLレピュテーションサービス（ Microsoft SmartScreen や Google SafeBrowsing）の難しさ
    • 毎週何百万もの新規サイトが追加され、誤検知リスクが高い

Web開発者・ユーザー・セキュリティ担当者への教訓

  • Web開発者への提言

    • アプリや重要機能は 信頼できるドメイン配下 でホスティング（例: cloudflare.com/pay, pay.cloudflare.com）
    • 新ドメインを使う場合は、必ず 信頼ドメインから直接リンク
    • セキュリティ判断を求めるUIでは、 明確かつ信頼できる情報表示
    • 不審なリクエスト報告機能 を容易に設置
    • セキュリティ報告フローが 正しく機能・監視 されているか定期的にテスト

  • ユーザーへのアドバイス

    • 不用意なクリックを避ける、疑問があれば一旦待つ
    • 急かされる状況では特に慎重に行動

  • セキュリティ関係者へのメッセージ

    • 被害者を責めない、ユーザーには困難な判断が求められている現実

  • 体験談から得られる最大の教訓

    • セキュリティUI/UXの設計と運用は、 信頼性とユーザー心理 を徹底的に考慮する必要

Hackerたちの意見

これからの教訓は「セキュリティは難しい」ってことじゃなくて、Cloudflareがかなり無能だってことだね。

└

教訓は、みんなセキュリティを難しくしてるってこと。みんな、セキュリティの推奨を無効にするような他のドメインを持つというアンチパターンをやってる。GitHubはずっと前からgithubnext.comみたいなものがあって、同じOAuthの手続きをさせられた（確か、もっとひどかったと思うけど - 明確に「GitHubじゃない」って書いてあった）。Appleは、apple.tvみたいなマイクロサイトを持ってて、そこでコンテンツをホストしてた。銀行も「正当な」調査やコミュニケーションをqualtropics.comみたいな第三者のドメインから送ってくるよ。

傍観者から見るのは簡単だけど、サイトのスクリーンショットは、最初のツイートじゃなくても明らかに詐欺じゃなかった？文脈から言えるかもしれないけど、俺はタイトルしか読んでなくて、目がスクリーンショットに飛んじゃったんだよね。

└

記事の残りを読んで、恥ずかしながら戻ってきたよ。作者の言いたいことを証明しちゃったみたいだ。

記事のある部分で、著者がCloudflareのボットにウォレット製品を出すか聞いたら、ノーって答えた。 > 「私たちのドキュメントやダッシュボードにはそのような製品はありませんので、『Cloudflare Wallet』を名乗るメールやウェブサイト、メッセージはフィッシングの試みと見なしてください。」こんな無知なAIチャットボットを追加する意味って何なの？

└

それって何の意味があるの？サポートメールを担当する人間にお金を払うのを節約するため？その人も同じ理由で無知だっただろうし。

└

投資家に今の流行に全力投球してるってシグナルを送るのがポイントなんだよね。だから株価が上がるってわけ。

└

へへ、俺もclaude desktopを使った数少ない時の一つでこれに遭遇した。どんな機能があるのか、どれがないのか、アプリ内のボタンの位置も全然わからなかった。チャットボットには知っておいてほしい基本的な知識じゃない？

└

要するに、どれだけAIっぽいかを見せることがポイントなんだ。

これはセキュリティの失敗じゃないよ。pay.cloudflare.comを確立するのがなんでこんなに難しいの？マーケティングがエンジニアリングをいつも圧倒するのはなんで？Cloudflareのサービスには、この人が経験した理由から、怪しい.pay TLDを避けてほしいんだ。

└

おそらく、怖いシステム管理者たちは *.cloudflare.com のDNSレコードにアクセスできるんだろうね。マーケティングは今すぐこれを進めたいから、pay.cloudflare.comの承認を待つよりも、ピカピカの新しいTLDを持つ新しいドメインを買う方が楽なんだと思う。cloudflare.com/payも似たような承認の流れがあるだろうし、もしすべてのマーケティングアイデアに独自のトップレベルルートがあったら、大企業だとかなり混乱しそう。

└

なぜ pay.cloudflare.com の設立がこんなに難しいのか？マーケティングサイトを作るエンジニアが、*.cloudflare.com と同じオリジンに置こうとすると、1,000ものセキュリティクリアランスや顧客通知のハードルを越えなきゃいけない。 > pay.cloudflare.com は、25年前のWordPressの脆弱性を防ぐための適切なWAFがないから立ち上げられない。pay.cloudflare.com/wp-admin.php がブロックされていることを確認してね。Zigアプリケーションだからって関係ないよ。スタートアップのためにSOC2をやった時、EC2インスタンスを立ち上げるのにいくつもの手順を踏まなきゃいけなかったのを思い出すよ。「コンプライアンスに合ってる」っていうだけで。もし何か問題が起きたら？「2,000ステップのプロセスを守らなかったのはなぜ？」って言われるんだ。こんな問題に対処しなきゃいけない人は本当に大変だと思う。

Hacker Newsで議論の続きを見る