本書の著者は、内容の正確性について一切の責任を負いません。本プロジェクトは、セキュリティ研究者が何かが脆弱であるかどうかを判断するための手助けを目的としていますが、正確性を保証するものではありません。本プロジェクトはコミュニティからの貢献に大きく依存しており、したがって、何かが脆弱であることを証明するかどうかは、セキュリティ研究者およびバグ報奨金プログラムの唯一の裁量に委ねられています。
さらに、本プロジェクトは、さまざまなサービスが実施するセキュリティ対策に対するバイパスを特定したり開示したりすることを目的としていないことを明確にしておきます。そのようなバイパスは、適切な対応のために影響を受けるサービスに直接報告されることが期待されています。
最後に、一部のバグ報奨金プログラムでは、侵害の証明を必要とせずに、ぶら下がりDNSレコードの報告を受け付ける場合があることに注意してください。
サブドメイン乗っ取りの脆弱性は、サブドメイン（subdomain.example.com）が削除または削除されたサービス（例：GitHub Pages、Herokuなど）を指している場合に発生します。これにより、攻撃者は使用されていたサービス上にページを設定し、そのページをそのサブドメインに向けることができます。例えば、subdomain.example.comがGitHubページを指していて、ユーザーがGitHubページを削除した場合、攻撃者は新しいGitHubページを作成し、subdomain.example.comを含むCNAMEファイルを追加して、subdomain.example.comを主張することができます。
詳細については、以下の記事をご覧ください：
個人的な経験に基づくと、サブドメインをこっそりと主張し、隠しページに無害なファイルを配置するだけで、通常はセキュリティ脆弱性を実証するのに十分です。インデックスページにコンテンツを配置しないでください。良い概念実証としては、ランダムなパス経由で提供されるHTMLコメントが考えられます：``` $ cat aelfjj1or81uegj9ea8z31zro.html
これは、ターゲットとするバグ報奨金プログラムによって異なることにご注意ください。不明な点がある場合は、バグ報奨金プログラムのセキュリティポリシーを参照するか、プログラムのチームに確認を依頼してください。
## このプロジェクトの使用方法
ターゲットとするサービスの名前をIssuesタブで検索することをお勧めします。そうすることで、進行中の議論や、目的のサブドメインを主張するためのより詳細な手順を確認できます。
## 貢献方法
新しいサービスはこちらから提出できます： https://github.com/EdOverflow/can-i-take-over-xyz/issues/new?template=new-entry.md。
チェック可能なサービスのリスト（ただし、このリストでの重複を先に確認してください）はこちらにあります： https://github.com/EdOverflow/can-i-take-over-xyz/issues/26。
# 全エントリ
注： `fingerprints.json` はこのテーブルの内容に基づいて自動更新されます。
カラムヘッダーの定義：
- `Engine`: サービスの名前
- `Status`: サービスが脆弱かどうか
- `Verified by CI/CD`: 自動フィンガープリントチェックが現在合格しているかどうか
- `Domains`: カンマ区切りのドメイン（フィンガープリント自動検証に使用）
- `Fingerprint`: 脆弱なページを示す正規表現（または存在しないDNSレコードを示す `NXDOMAIN`）
- `Discussion`: 議論のためのこのリポジトリのIssueへのリンク
- `Documentation`: 公式ドキュメントへのリンク