【SSTI編】入力をテンプレートとして実行させない設計｜CTF思考フレームワーク #33
安全に生きたい編集部
安全に生きたい
【Google Dork編】検索演算子で機微情報を引き出す受動偵察｜CTF思考フレームワーク R05
安全に生きたい編集部
こんにちは、アンペンです！偵察ルートR05はGoogle Dork編。標的のサーバを一度も叩かずに、検索エンジンのインデックスだけで露出ファイルや管理画面を見つける『究極の受動偵察』を扱います。R04の総当たりとは真逆で、足跡を残さないのが最大の特徴です。
『検索するだけで秘密ファイルが見つかる』——にわかには信じがたいですが、これは紛れもない事実です。Googleは世界中のサイトを巡回して中身を“目録”にしていますが、その過程で、本来見せるつもりのなかった設定ファイルやバックアップまで、うっかり拾ってしまうことがある。つまりDorkでヒットするということは、『もうとっくに世界に露出していた』という意味なんです。攻撃者はサーバに一切触れず、検索窓だけでそれを掘り当てるわけです。
検索するだけで秘密ファイルが見つかるって本当？
本当なんだ。filetype:envやintitle:"index of"みたいな検索演算子を組み合わせると、誤って公開された設定ファイルやディレクトリ一覧がずらり。Googleが既にインデックス済み＝もう世界に露出しているってことなんだ。
まず結論
Google Dork(Google Hacking)とは、site:inurl:intitle:filetype:などの検索演算子を組み合わせ、標的サーバに直接アクセスせず検索インデックスから露出情報を炙り出す受動偵察。サーバにアクセスしないので検知されずログにも残らないのが最大の強み。逆に言えば、ヒットした情報は既に世界へ露出済みを意味する。既成クエリ集のGHDB(Google Hacking Database)が定番。守る側の鉄則は『機密を公開領域に置かない＋noindex＋自社ドメインをDorkでセルフ監査＋漏れたらキャッシュ削除と認証情報ローテーション』。
この記事で分かること
- 主要な検索演算子(site/inurl/intitle/filetype)の意味
- そのまま効く「定番Dork」と何が漏れるか
- 受動偵察が検知されない理由と、その裏返しのリスク
- GHDB・Shodan・Wayback Machineの位置づけ
- 守る側の露出監視＆漏えい後の正しい対処
📖 はじめてのWebセキュリティR05｜Google Dork編
検索演算子で受動的に隠し情報を拾う、足跡を残さない偵察。 シリーズ一覧を見る →
⚠️ 大事なお約束
検索すること自体は合法ですが、ヒットした他者の非公開情報に実際にアクセス・取得すれば不正アクセスや情報窃取になり得ます。本記事の演算子は自分のドメインのセルフ監査・CTF・許可された対象でのみ使ってください。
Contents
主要な検索演算子
Google Dorkの本体は、ごく少数の演算子の組み合わせです。まず単語の意味を押さえます。
- site:ドメインを限定。
site:example.comで対象内だけに絞る(偵察の起点) - inurl:URLに含む文字列。
inurl:admininurl:loginで管理系を探す - intitle:ページタイトルに含む。
intitle:"index of"はディレクトリ一覧露出の合図 - filetype: / ext:拡張子で絞る。
filetype:envfiletype:sqlfiletype:logfiletype:bakが要注意 - intext:本文に含む語。
intext:"DB_PASSWORD"のように中身で狙い撃つ - 補助:
""完全一致、-除外、OR論理和、*ワイルドカード、cache:キャッシュ表示
演算子は、検索結果を絞り込む“虫眼鏡”のようなものだと思ってください。ふつうに検索すると、関係ないページが何万件も混じります。でも『このドメインの中だけ』『この拡張子だけ』『この単語を含むものだけ』と条件を重ねていくと、砂浜から砂金だけをふるい分けるように、目当ての露出ファイルがスッと残る。1つ1つの演算子は単純でも、重ねた瞬間に“狙い撃ちの道具”に変わるんです。
ここで覚える用語:検索演算子(Search Operator)の組み合わせ
意味:単独の演算子より、複数を重ねて検索結果を機械的に絞り込むのがDorkの本質です。
例:site:example.com filetype:pdf intext:confidential なら「example.com内の、confidentialを含むPDF」だけが残ります。
使いどころ:定石はsite:で標的限定 → filetype:で露出ファイル種別 → intext:でキーワードの3段重ね。intitle:"index of" backupのようにタイトル＋語でディレクトリ露出も一発で見つかります。
そのまま効く「定番Dork」
intitle:"index of" "parent directory"→ ディレクトリリスティングの露出filetype:env "DB_PASSWORD"→ .envの漏えい(認証情報直書き)filetype:sql "INSERT INTO"→ DBダンプの流出inurl:wp-config.php/ext:log/filetype:bak→ 設定・ログ・バックアップintitle:"index of" backup→ バックアップディレクトリ露出"-----BEGIN RSA PRIVATE KEY-----"→ 秘密鍵の流出
こうした定番Dorkを見て、『なんでこんな危ないものがネットに転がってるの？』と思いますよね。答えはほぼ“うっかり”です。バックアップをWebフォルダに置いたまま消し忘れた、.envをうっかりコミットして公開した、ディレクトリ一覧をオフにし忘れた——どれも悪意ではなく、ちょっとした手抜かり。でもGoogleは正直なので、置いてあれば目録に載せてしまう。攻撃者は、その“人間のうっかり”を検索で待ち構えているわけです。
図解:目録から露出ファイルへ
演算子の組み合わせ→検索インデックスの絞り込み→露出ファイルのヒット、という流れ。標的サーバには一切触れずに完結します。
📚 たとえるなら、図書館の目録カード検索
本を一冊ずつ棚から探す(=サーバへ直接アクセス)代わりに、司書が作った目録カード(=検索インデックス)を使えば「○○について書いた本」「△△という単語を含む本」を一瞬で見つけられます。Google Dorkはこの目録の絞り込み検索を極めたもの。やっかいなのは、目録には本来非公開のはずの『裏方のメモ書き(=設定ファイルやバックアップ)』まで、職員のミスで誤って載ってしまうことがある点です。棚(サーバ)に触らずとも、目録を見るだけで秘密が手に入ってしまうわけです。
ここで覚える用語:GHDBと受動偵察の倫理
意味:GHDB(Google Hacking Database)はExploit-DBが運営する既成Dorkのカタログで、「パスワードを含むファイル」「ログイン画面」「脆弱なサーバ」などカテゴリ別に膨大なクエリが載っています。
例:“Files Containing Passwords”カテゴリを開けば、すぐ使えるDorkがずらりと並びます。
使いどころ:攻撃者も使うので、守る側は自社ドメインをGHDBのクエリでセルフ監査するのが効果的。ただし検索でヒットした他者の非公開情報に実際にアクセスするのは不正アクセスで、別問題です。境界線を必ず意識しましょう。
関連ツール:Dorkだけじゃない受動偵察
- Shodan / Censys:Webだけでなく、世界中の公開サービス・IoT・空きポートを検索。バナーやTLS証明書まで見える
- Wayback Machine:過去にインデックスされたページの保存版。消したつもりのページが残っているのを確認できる
- crt.sh(証明書透明性ログ):発行済みTLS証明書からサブドメインを列挙(R01 DNS編と接続)
CTFでやってみよう:自分のドメインを監査
やってみよう / 自分のドメイン・学習のみ
「攻撃者がGoogleで何を見つけられるか」を先回りで点検
自分が管理するドメインに対して、攻撃者と同じ検索を先に実行します。各ステップに「なぜやるか」を添えました。
site:自分のドメインで全インデックスを俯瞰 → なぜ:そもそも何が公開検索に載っているか棚卸しするためsite:ドメイン filetype:pdf OR filetype:xlsx OR filetype:docx→ なぜ:意図せず公開された文書を洗い出すためsite:ドメイン inurl:admin OR inurl:login→ なぜ:管理画面が検索に露出していないか確認するためsite:ドメイン ext:log OR ext:bak OR ext:sql OR ext:env→ なぜ:設定・ログ・DBダンプの漏えいを点検するためsite:ドメイン intitle:"index of"→ なぜ:ディレクトリリスティング露出を確認するため- GHDB(exploit-db.com/google-hacking-database)で自社向けクエリを試す → なぜ:攻撃者の視点をそのまま借りるため
- Wayback Machineで過去に消したページが残っていないか確認 → なぜ:削除＝消滅ではないから
- ヒットした機密は削除＋キャッシュ削除申請＋認証情報ローテーション → なぜ:既に露出済み前提で被害を止めるため
他者ドメインのヒット結果に実際にアクセス・取得しないこと。演算子は自分のドメイン・CTFのみで。
守る側:露出させない・気づく・止める
Google Dork対策チェックリスト
- 機密ファイルを公開領域に置かない:
.env/.sql/.bak/.logはWebルート外へ(R04と同根) - noindex/robots:非公開ページはメタ
noindexで。ただしrobots.txtに秘密パスを直書きしない(地図になる) - ディレクトリ一覧の無効化:
index of露出の根を断つ - Search Consoleで監視:自社インデックスを確認し、不要URLは削除リクエスト
- 漏れたら「削除」で安心しない:キャッシュ削除＋認証情報のローテーションまで
- GHDBでセルフ監査:攻撃者向けクエリを自社ドメインに定期適用
- 秘密鍵・トークンを公開しない:
filetype:検索で即発見される - URL秘匿に依存しない:知られても認証・アクセス制御で守る
消しただけじゃダメで、鍵も変えなきゃいけないんだ…
そう、一度ネットに出た鍵は「漏れた鍵」。削除より無効化が本命だよ。次はR06、Recon統合運用(ASM)。ここまでの偵察を『継続的な資産管理』としてつなげる発想を扱うよ。
まとめ:『叩かずに見つける』受動偵察
今回のポイント
- Dorkはsite/inurl/intitle/filetypeの組み合わせが本体
- サーバを叩かない＝検知されない。だがヒット＝既に露出済み
- GHDB・Shodan・Waybackで受動偵察の幅が広がる
- 検索は合法でも他者の非公開情報へのアクセスは不正アクセス
- 守りは置かない・noindex・セルフ監査・漏れたら鍵を変える
今日の持ち帰りは『一度ネットに出た秘密は、消しても“出た”という事実は消えない』。とくにパスワードや鍵がDorkでヒットしたなら、ファイルを消すだけでは不十分です。誰かがもう保存しているかもしれない前提で、鍵やパスワードそのものを“無効化（ローテーション）”するのが本命の対処。そして何より——攻撃者と同じ検索を、まず自分のドメインで試してみること。これが最強の予防になります。
次はR06、Recon統合運用(ASM)編。点で行ってきた偵察を、継続的な資産管理として束ねます。
