GitHub Pages のサブドメインテイクオーバー対策｜Web 担当者向け実践手順
目次
この記事でわかること
- GitHub Pages 特有のサブドメインテイクオーバーパターン
- dangling CNAME を検出する具体手順
- 是正の 3 ステップ
- GitHub の Verified Domains による予防策
GitHub Pages のテイクオーバーが成立する条件
危険な状態
www.example.co.jp CNAME username.github.io
↑ リポジトリが削除済 / アカウント削除済
GitHub Pages では、同じユーザー名・リポジトリ名で誰でも新規作成可能な仕組み上、過去に使った GitHub アカウント / リポジトリの名前が解放されると 攻撃者が再取得できます。
攻撃成立のパターン
- 御社が以前
https://username.github.io/site/で社内資料を公開 - リポジトリを削除して GitHub Pages を停止
- しかし
www.example.co.jpの CNAME はそのまま残置 - 攻撃者が
username/siteリポジトリを新規作成 - カスタムドメインに
www.example.co.jpを設定 - 御社のドメインで攻撃者のページが配信される
自社で確認する手順
1. CNAME が GitHub Pages に向いているか確認
dig +short CNAME www.example.co.jp
# → username.github.io. が返れば対象
*.github.io パターンの CNAME は全て確認候補。
2. 対象リポジトリが存在するか確認
ブラウザで https://username.github.io/repo/ を開いて、以下のメッセージが表示されたら dangling 確定:
There isn't a GitHub Pages site here.
3. アカウント削除済みの場合
https://github.com/username が Not Found を返したら、ユーザー名自体が解放済 → 攻撃者が同名アカウントを作成できる状態です。
是正の 3 ステップ
ステップ 1: 即座に DNS から CNAME を削除
最優先。利用予定がない CNAME はすぐ消す。
ステップ 2: 自社で同名リポジトリを再取得（攻撃者より先に）
将来また使う可能性がある名前は、自社の GitHub アカウントで username/repo を作成して占有しておきます。GitHub Pages を有効化する必要はなく、空リポジトリで OK。
ステップ 3: GitHub Verified Domains を有効化（中長期）
GitHub の Settings → Pages → Verified Domains を有効化すると、カスタムドメインを DNS TXT レコードで所有確認できます。所有確認していないドメインは別アカウントから設定不可になり、攻撃の表面積が下がります。
_github-pages-challenge-username.example.co.jp TXT "abc...xyz"
Web 担当者向け Verified Domains の運用
| 項目 | 推奨設定 |
|---|---|
| 対象 | GitHub Pages を使う全カスタムドメイン |
| TXT レコード | _github-pages-challenge-{username} の形 |
| 失効時 | アカウント削除前に「ドメイン所有を移譲」or「TXT を削除」 |
| 監視 | 半年〜1 年に 1 回、Verified Domains リストの整合性確認 |
検出を自動化する
毎回手作業は大変なので、ドメイン番人の サブドメイン棚卸し 単発チェック では *.github.io パターンの dangling CNAME を自動検出します。CT log + DoH 解決 + SaaS パターン照合を 30 秒で実行。
まずは現状を把握しましょう
棚卸しと是正の支援は サブドメイン棚卸し＋テイクオーバーリスク診断（5 万円〜）でご相談ください。
関連記事:
- サブドメインテイクオーバーとは？仕組みと EC・スタートアップ・制作会社への影響
- dangling CNAME のリスクと検出方法
- Heroku のサブドメインテイクオーバー対策
- AWS S3 のサブドメインテイクオーバー対策
総合点検は 無料のドメイン診断、SSL 単独は SSL 単発チェック をご利用ください。