Google Dorkingで見つかる脆弱なサイト・デバイスと防御策
概要
Google Dorking（グーグルドーキング）は、Googleの高度な検索演算子を用いて、通常の検索では見つからない公開された機密情報や誤設定を抽出するテクニックです。攻撃者はこれを足がかりに脆弱性を突き、情報漏えいや不正アクセスを行う場合があります。一方で、セキュリティ担当者は同じ手法を使って自社の露出を監査し、早期に修正できます。
1行定義: Google Dorkingは「検索演算子で公開インデックスを照会し、機密情報や誤設定を探す技術」です。
背景と歴史
2002年、Johnny LongがGoogle検索で見つかった興味深いクエリ（後に「Google dorks」と呼ばれる）を収集し始めたことが現在の呼称の起源です。以降、シンプルなクエリで隠れたファイルやログインページを見つける手法と、複雑なクエリで脆弱なターゲットを特定する手法の両方が発展しました。
何が見つかるか（攻撃側の典型的な発見物）
- 管理パネルやログインページ
- 平文や半平文のユーザー名・パスワード（設定ファイル、スプレッドシート、ログ）
- 秘密または機密ドキュメント（契約書、財務データ）
- メールリスト、連絡先情報
- SQLインジェクションの痕跡やXMLRPCの公開などウェブアプリ脆弱性
- IoT機器の管理インターフェイスやポート情報
用語メモ（1行）
- Dork: 特定の検索演算子やキーワードを組み合わせた検索クエリ。
- 演算子: site:, inurl:, filetype: などGoogleの高度検索オプション。
Googleの高級演算子（簡潔な早見表）
| 演算子 | 機能（日本語） |
|---|---|
| allintext: | 指定したキーワードが本文に全部含まれるページを検索 |
| intext: | 本文中にキーワードが含まれるページを検索（単語ごとまたは一括） |
| inurl: | URLにキーワードが含まれるページを検索 |
| allinurl: | URLに指定したキーワードがすべて含まれるページを検索 |
| intitle: | タイトルにキーワードが含まれるページを検索 |
| allintitle: | タイトルに指定したキーワードがすべて含まれるページを検索 |
| site: | 特定ドメイン内に限定して検索 |
| filetype: | 指定したファイル拡張子を検索（例: pdf, xls, php） |
| link: | 指定ページにリンクしている外部ページを検索 |
| numrange: | 数値の範囲で検索 |
| daterange: | 指定した日付範囲で検索 |
重要: 上の演算子を組み合わせることで、非常に絞り込んだ検索が可能になります。
シンプルな例と解説
以下はよく使われるDorkの例です。コードブロックで示します。
Operator_name:keyword例: 管理者ページやSQL生成結果の痕跡を探す
inurl:group_concat(username filetype:php intext:admin上のクエリは、PHPファイル名や内容に特定のSQL関数や「admin」というキーワードを含む結果を探します。攻撃者は、こうした結果から既に誰かが実行したSQLインジェクション痕跡や設定ミスを見つけ、侵入に利用することがあります。
メールアドレスを公開スプレッドシートから集める例
intext:@gmail.com filetype:xlsサイト列挙（ホスト名やサブドメインの検出）例
site:xyz.com -site:www.xyz.com -site:xyz.comポート情報検出の例（URLにポート番号が含まれるものを列挙）
inurl:8443 -intext:8443上のクエリはURLに8443を含むページを検索し、本文中の単純な言及は除外するため、実際に8443ポートでホストされているサービスのURLを抽出しやすくなります。
シンプルDorkと複雑Dorkの違い
- シンプルDork: 特定のキーワードやファイルタイプを見つけるための単純な組み合わせ。公開ドキュメントや設定ミスの発見に有効。
- 複雑Dork: 複数の演算子を組み合わせ、正規表現的なロジックで脆弱性や管理インターフェイスを正確に狙う。攻撃側がターゲット選定のために用いることが多い。
攻撃シナリオ（概念モデル）
- ターゲット企業のドメインをsite:で限定
- inurl:, intext:, filetype:などでログインページや設定ファイルを検索
- 得られた情報を手動またはスクリプトで精査し、追加の攻撃（辞書攻撃、脆弱性スキャン）へつなげる
メンタルモデル: Googleは巨大な索引データベースであり、そこに「うっかり公開された情報」が残っている限り、検索演算子で取り出せると考えるとよいです。
いつうまくいかないか（反例）
- 機密情報がインデックスされていない（robots.txtでクロール拒否、noindex メタタグ、認証後のみのページ）
- 情報が非公開ネットワーク（イントラネット）内にあり、パブリック検索エンジンからアクセスできない
- サイト側が機密情報の露出を防ぐために適切なアクセス制御やマスク処理をしている
これらの場合、Google Dorkingは見つけられないか効果が限定的です。
検出と防御（ディフェンス向け手順とチェックリスト）
即時対応（短期）
- robots.txtやnoindexを設定するのは補助であり唯一の対処ではないが、まずは早急に不要な公開を止める。
- インデックス済みの機密ドキュメントはSearch Console（または該当検索エンジンの削除ツール）を使ってURLを削除依頼する。
- 公開済みのファイル（xls, csv, pdf）を確認し、含まれる個人情報や認証情報をサニタイズする。
恒久対応（中長期）
- 機密データは公開リポジトリに置かない。配置する場合は強力な認証と最小権限を徹底する。
- 構成管理とCI/CDパイプラインで機密情報を除外（シークレット管理）する。
- Webアプリは認証前にアクセス可能なファイルを監査し、誤設定を検出する自動テストを導入する。
- 定期的に自社ドメインでのDorking監査を行い、露出をトリアージする。
検出ルール例
- SIEMに「外部から特定のファイルタイプ（xls, xlsx, sql）がindexされた」アラートを作る
- Webログで「アクセスされたが認証を要求されるべきURLへの未認証アクセス」を検出
ロール別チェックリスト
- 開発者: コード内にハードコードされた資格情報がないか、ログ出力にパスワードや鍵が含まれていないかを確認
- インフラ担当: S3バケット、ストレージ、ログ保存先の公開設定をチェック
- セキュリティ担当: ドメインで定期的にDorking調査を実施し、発見物を優先度付けして修正
- 法務/コンプライアンス: 個人データが公開された場合の通知手順と記録保持を整備
SOP（簡易プレイブック）
- 発見: Dorkingで機密情報を発見
- 評価: 含まれる情報の機密性・影響度を判断
- 封じる: 該当URLのアクセス制御を即時適用、またはSearch Consoleで削除依頼
- 根本対処: 誤配置の原因（CI設定、アップロードミス等）を修正
- 報告: 関係者へ通知し、再発防止策を実施
セキュリティ強化の実務的対策
- 機密情報を含むファイルに対してはアクセス認可を強化し、パブリックなストレージやウェブルートに置かない
- バックアップやログにも機密情報が入らないようマスキングを行う
- Webアプリの重要操作はCSRFや認証チェックを確実に実装する
- インデックス除外だけに頼らず、サーバー側での認証とアクセス制御を徹底する
法的・倫理的注意点
- Google Dorking自体は検索エンジンを使った調査行為であるため、公開情報の閲覧自体は多くの司法権で違法ではありません。ただし、得られた情報を使って不正アクセスやデータ窃取を行うことは違法です。
- セキュリティ調査を行う際は、事前に組織のポリシーや法的枠組み、同意（許可）を得ることが重要です。
自動化とツール連携の注意点
Google APIやカスタムスクリプトで検索結果を自動収集することは可能ですが、検索エンジン利用規約やAPI利用制限を遵守する必要があります。また、自動化は大量の検出を生むため、誤検出のフィルタリングと人による確認工程を必ず入れてください。
代替アプローチと補完ツール
- Shodan、Censys: ネットワーク機器や公開サービスの探索に特化。ポートやバナー情報を使ってIoTや管理インターフェイスを見つける
- Burp Suite、Nikto: Webアプリ脆弱性の掘り下げに有効
- 検出系SIEM/EDR: 実際の侵害や悪用の兆候を監視
決定フローチャート（Mermaid）
flowchart TD
A[疑わしいDork結果を発見] --> B{含まれる情報は機密か}
B -- はい --> C[即時ブロックとSearch Consoleで削除依頼]
B -- いいえ --> D[リスク低として記録・監視]
C --> E[根本原因調査と修正]
E --> F[再発防止とレポート作成]
D --> F受けられる誤解と反駁
誤解: 「robots.txtに載せれば安全」 反駁: robots.txtはクローラーへの希望を示すだけで、機密情報を隠す手段ではありません。悪意ある攻撃者はrobots.txtを参照して機密ファイルの場所を特定することもあります。
誤解: 「公開されている情報だから問題ない」 反駁: 公開されているが意図しない機密情報は組織にとって重大リスクです。公開の意図がない情報は速やかに排除・修正すべきです。
短い用語集（1行ずつ）
- Index（インデックス）: 検索エンジンがウェブページ情報を格納したデータベース
- Noindex: 検索結果に表示しないよう指示するメタタグ
- robots.txt: クローラーに対するサイトマップやアクセス指示を記載するテキストファイル
- SIEM: セキュリティ情報・イベント管理システム
まとめ（重要ポイント）
- Google Dorkingは公開インデックスから機密や誤設定を探す強力な手法で、攻撃者と防御者の双方に利用される。
- 単にインデックス除外するだけでなく、アクセス制御・認証・シークレット管理を徹底することが最も有効な防御策である。
- 定期的なDorking監査、検出ルール、開発運用での秘密管理を組み合わせてリスクを低減する。
重要: セキュリティ調査を行う際は、法的枠組みと組織内の許可を必ず確認してください。
