2026-08-01重大

パスワードの門は、二要素目を確認する前に通行証を発行していた

認証済みドメインへのリダイレクトは提案であって関門ではない——クライアントはそれに従わない自由がある。

背景

運用コンソールの手前には、ポートフォリオサイト上のパスワードページがありました。正しいパスワードを入れると Cloudflare Access で保護されたホスト名へリダイレクトされ、Access を通過してコンソールへ戻る。設計上は二段構え——知っている情報と、エッジが検証する要素。

経路

症状: Access を設定済みなので、コンソールは保護されていると考えていた
仮説: Access 保護ドメインへのリダイレクトが強制力を持つ、と仮定
計測: パスワードを直接 POST し、リダイレクトを無視して cookie を保持——コンソール全体が 200 を返した
判断: Access をエッジへ移し、署名付きアサーションを毎リクエスト検証。パスワード経路は削除

対応

Access をエッジでコンソールの直前に置き、公開ステータスボードを残すためにパス単位の Bypass アプリケーションを併用し、アプリ側では毎リクエスト Cloudflare の署名付きアサーションを検証する構成にしました。パスワード経路は二要素目として残さず完全に削除——迂回できる要素は要素ではありません。新経路が実証されるまで旧 cookie 経路を残しましたが、これは正解でした。切り替えで三層のバグが露出し、そのどれ一つでも運用者を自分のコンソールから締め出すに足るものだったからです。

運用スキルの更新

スキルharumi-infra-managerコミットharumi-platform@f4bcb45

運用スキルに「保護された場所へリダイレクトすること自体は検証ではない——資格情報は保護対象側でリクエストごとに検証する」を明記。あわせて、既存サービスの前段に Access を置く前にアプリの自己呼び出しを確認すること、および Access のサービストークンで認証経路を検証する手法を追記した。