2025-10-10

Google Dorks Secrets: Discover Hidden Endpoints & Parameters with Google Dorks から学ぶ

Bug Bounty Recon

ソース：

enigma96.medium.com

ジャンル：Google Dorking

内容：

グバウンティハンターとしての主な仕事の一つは、ターゲットの攻撃対象領域をマッピングすることです。これには、隠れたパラメータやエンドポイントの発見も含まれます。これらは、より深刻な脆弱性への扉を開き、パッチが適用されていないAPI呼び出し、保護されていない機能、さらには管理者レベルのアクセスにつながる可能性があります。Google Dorkingは、ターゲットのインフラに直接アクセスすることなく、これらの隠れた脅威を見つけるための非常に効率的な方法です。

Google Dorksを使って、しばしば公開されてしまう隠れたパラメータやエンドポイントを明らかにする方法について詳しく説明します。これらの隠れたアクセスポイントを発見することで、気づかれずに放置されていた可能性のある攻撃ベクトルを発見できるようになります。

1. 隠しパラメータとエンドポイントが重要な理由

エンドポイントとパラメータは、Webアプリケーションの機能の根幹を成す要素です。クライアントとサーバー間のデータの受け渡し方法、そして場合によっては特定の機能（管理アクションなど）の実行方法を規定します。これらの要素が適切に保護または隠蔽されていない場合、以下のような様々な攻撃に悪用される可能性があります。

IDOR (安全でない直接オブジェクト参照)
検証されていない入力
公開されたAPI
認証のバイパス

秘訣はこれらの隠れたアクセスポイントを見つけることですが、Google Dorking はまさにそのための優れたツールです。

2. Google Dorksで露出したエンドポイントを見つける

エンドポイント、特にAPIエンドポイントは、開発者が公開を意図していない場所にドキュメント化されることがよくあります。これらのエンドポイントは、システムの動作方法、処理するデータ、ユーザーが利用できるアクションに関する貴重な情報を明らかにする可能性があります。

Dork Example:

site:target.com filetype:php inurl:"api"

site:target.com検索を対象の Web サイトに制限します。
filetype:php多くの場合、バックエンド機能を提供する PHP ファイルを検索します。
inurl:"api"「api」を含む URL を探します。これは、ファイルが API 呼び出しを処理することを示す一般的な指標です。

なぜ重要か：これらのAPIエンドポイントを見つけることで、標的のバックエンドに直接アクセスできるようになります。多くの場合、APIは適切に認証または制限されていないため、悪用される可能性があります。

3. Google Dorksを使って隠れたパラメータを見つける

パラメータ、特にGETパラメータは、ウェブサイトがリクエストをどのように処理するかに関する重要な情報を提供する可能性があります。非表示パラメータには、管理機能、デバッグオプション、あるいは誤ってアクセス可能になった内部機能などが含まれる場合があります。

Dork Example:

site:target.com inurl:"?id="

説明：

site:target.com検索を対象ドメインに制限します。
inurl:"?id="パラメータを含むURLを検索します idこれは、Web アプリケーションでレコードを ID で取得する一般的なパターンであり、安全でない直接オブジェクト参照 (IDOR) などの脆弱性の影響を受ける可能性があります。

重要である理由 : アプリケーションがこれらのパラメータの入力を適切に検証しない場合、パラメータを操作して不正なデータにアクセスしたり、実行権限のないアクションを実行したりされる可能性があります。

4. デバッグと管理エンドポイントの発見

開発中、開発者はデバッグエンドポイントや管理エンドポイントを公開したままにしておくことがよくあります。これらのエンドポイントは、機密情報を漏洩させたり、管理機能へのアクセスを許可したり、サーバー側のエラーを表示したりする可能性があります。

Dork Example:

site:target.com inurl:"admin" OR inurl:"debug"

説明：

site:target.com特定のドメインをターゲットにします。
inurl:"admin"「admin」という単語を含む URL を検索します。これは管理パネルまたはエンドポイントを示している可能性があります。
OR inurl:"debug"「debug」を含む URL を検索します。これにより、公開されるべきではない内部デバッグ情報が公開される可能性があります。

重要度：管理エンドポイントとデバッグエンドポイントは、通常のユーザーがアクセスすべきではない機能を公開する可能性があります。また、サーバーログ、エラーメッセージ、構成設定などの機密情報が公開される可能性もあります。

5. APIドキュメントファイルの探索

多くの企業は、内部APIドキュメントをうっかり公開してしまいます。そこには、利用可能なすべてのエンドポイントとその操作方法に関する詳細な情報が含まれている可能性があります。これらのドキュメントには、パラメータ、ペイロード、認証方法などが記載されている可能性があり、これらはすべてバグハンターにとって重要な情報です。

Dork Example:

site:target.com filetype:json inurl:"swagger"

説明：

site:target.com検索を対象ドメインに制限します。
filetype:jsonAPI ドキュメントの一般的な形式である JSON ファイルを検索します。
inurl:"swagger"API ドキュメントを自動生成するための一般的なツールである Swagger ドキュメントを検索します。

重要な理由：Swaggerドキュメントは、利用可能なすべてのAPIエンドポイント（適切に保護されていない可能性のあるエンドポイントも含む）を明らかにすることができます。これは、対象のAPIセキュリティをテストするための強力な出発点となります。

6. Google Dorksを組み合わせてパラメータとエンドポイントを見つける

他のハッキング手法と同様に、複数のドーキング演算子を組み合わせることで、より正確で効果的な検索が可能になります。隠れたパラメータやエンドポイントを発見するのに役立つ、高度な組み合わせをいくつか見てみましょう。

例1：

site:target.com inurl:"?action=" OR inurl:"?cmd="

説明：

site:target.com検索をターゲットドメインに制限します。
inurl:"?action=" OR inurl:"?cmd="次のような一般的なパラメータ名を含むURLを検索します。 action または cmdは、コマンドを渡したりアクションを指定したりするためによく使用されます。

動作の理由：これらのパラメータは、管理機能やサーバー側コマンドの実行に使用される可能性があります。適切に保護されていない場合、コマンドインジェクションや不正なアクションなどの脆弱性につながる可能性があります。

例2:

site:target.com filetype:js inurl:"api" intext:"endpoint"

説明：

site:target.com特定のドメインをターゲットにします。
filetype:js検索を JavaScript ファイルに制限します。
inurl:"api"API を参照する JS ファイルを探します。
intext:"endpoint"ファイル内で「エンドポイント」という用語を検索します。これは、利用可能なエンドポイントのリストを示している可能性があります。

機能する理由 : JavaScript ファイルには、バックエンド API への参照が含まれることが多く、文書化されていない、または通常のサイトナビゲーションでは表示されない非表示のエンドポイントが明らかになる可能性があります。

7. 管理者権限を明らかにするクエリパラメータの検出

クエリパラメータは、サイト内のアクセスレベルを制御する場合があります。開発者が誤って、ユーザーロールの切り替え、機密データの編集、内部ダッシュボードへのアクセスといった管理機能へのアクセスを許可するパラメータを公開してしまう可能性があります。

Dork Example:

site:target.com inurl:"?role=admin" OR inurl:"?privilege=admin"

説明：

site:target.comターゲットのドメインに焦点を当てます。
inurl:"?role=admin" OR inurl:"?privilege=admin"ロールまたは権限パラメータが管理者レベルのアクセスを示す可能性がある URL を検索します。

重要度：これらのパラメータは、アプリケーション内のユーザーロールを制御するために使用される可能性があります。このようなパラメータを含む公開されたURLを発見した場合、それを操作して権限を昇格される可能性があります。

結論：

「Google Dorksをマスターすることは、機密機能を露出させる可能性のある隠れたパラメータやエンドポイントを発見するために不可欠です。クエリを慎重に作成することで、悪用される可能性のあるウェブアプリケーションの重要な部分を明らかにできます。」

パート2では、シンプルながらも強力なDorksを使って、これらの隠されたエンドポイントとパラメータを発見する方法を紹介しました。パート3では、高度なGoogle Dorking技術を用いて、公開されている管理パネルやログインポータルを発見する方法について詳しく説明します。

2025-07-08

I Hacked GraphQL to Steal Data Without Admin Access から学ぶ

ソース：

medium.com

脆弱性：GraphQL

要約：

REST APIとは異なり、GraphQLでは必要なものを正確に要求できます 。
問題は、 多くのアプリが権限を適切に適用していないことです。

これが危険な理由です:

イントロスペクションはデフォルトで有効になっています 。
攻撃者は スキーマ全体をダンプし 、すべてのクエリ、変更、およびデータ型を確認できます。
フィールドレベルのセキュリティはまれです 。
API にアクセスするためにログインが必要な場合でも、バックエンドがロールを検証しないと管理者専用のデータを取得してしまう可能性があります。
レート制限なし。
GraphQLクエリは連鎖またはバッチ処理、ハッカーはアラームをトリガーせずにデータをブルートフォース攻撃できます。

GraphQL がアプリを壊すのでなく、誤った設定が壊す。

ゼロから管理者になる4つのステップ

フェーズ1: GraphQLエンドポイントの検索

ほとんどのアプリはGraphQLエンドポイントを隠しています /graphql または /api。
しかし、時には次のような場合に露出することがあります。

JavaScriptファイル（ main.js、 app.js）
開発者ツール（ネットワークタブ）
APIドキュメント（存在する場合）

私は それを見つけるために簡単なツール を使用しました:

subfinder -d target.com | httpx -path /graphql -status-code

Golden Nugget：
「エンドポイントは裸の状態でした。JWTもCSRFもありませんでした。まるで警備員のいないVIPルームのようです。」

フェーズ2: イントロスペクションによるスキーマのダンプ

GraphQL の イントロスペクション と尋ねることができます。 機能を使用すると、「API、ここで何ができるのか？」

簡単なクエリですべてが公開されます。


    query {
  __schema {
    types {
      name
      fields {
        name
      }
    }
  }
}

私は GraphQL Voyager を使用してスキーマを視覚化し、 管理者の変更、ユーザーデータ、機密クエリを即座に確認しました。

フェーズ3: クエリによるデータの窃盗

このアプリには getUserクエリがあって。
通常は自分のデータのみが表示されます。

しかし、アクセス制御が壊れているため、 誰の情報でもID を変更することでも取得できます。

query {
  getUser(id: 1) {  # Changed from my ID to admin’s ID
    email
    passwordHash
    isAdmin
  }
}

管理者のプロフィール全体が漏洩した。

フェーズ4: ミューテーションによる権限の昇格

本当のジャックポット？ GraphQL の変異。

私は見つけた updateUserRole変異—そして何だと思いますか？

権限チェックはありません。


mutation {
  updateUserRole(id: 1337, role: "admin") {
    success
  }
}

自分を管理者にしました。

盗むことができたもの（でも盗まなかったもの）

このレベルのアクセス権があれば、次のことが可能です。

✔ すべてのユーザーの個人情報 （メールアドレス、住所、ハッシュ化されたパスワード）が公開された

✔ アクセスされた支払いデータ （Stripeトークン、取引履歴）

✔ データベースレコードを削除または変更した

しかし、ここに意外な点があります。

「大きな力には、大きなバグ報奨金が伴います。」

私は責任を持ってそれを報告し、 5,000ドルを獲得しました。 調査結果に対して

倫理的なハッカーのための5つのプロのヒント

GraphQL のバグを探している場合は、以下を試してください。

常にテストする __schemaクエリ – ドキュメントにイントロスペクションが無効になっていると記載されていても、試してみてください。
ブルートフォース変異 - テスト resetPassword、 createAdminUser、または deleteAccount。
IDORをGraphQLで連鎖させる — 変更 idパラメータを自由に設定できます。多くのアプリは所有権を検証しません。
ファジングには GraphQLmap を使用します — イントロスペクションがオフの場合、このツールはクエリの推測に役立ちます。
バッチクエリ攻撃をチェックします 。レート制限を回避するには、1 つのリクエストで 100 件のクエリを送信します。

アプリでこれを修正する方法

開発者向け:

本番環境ではイントロスペクションを無効にします (ほとんどのアプリでは必要ありません)。
ロールベースのリゾルバを実装する（Apolloの @authディレクティブが役立ちます。
すべてのクエリ/ミューテーションを検証する - ユーザーが そのデータにアクセスする必要がある かどうかを確認します。

セキュリティは魔法ではありません。適切なコーディングだけです。

ほなほな。

2025-07-07

From Image Upload to Account Takeover — Chaining Upload, Storage, and CORS Issues in a Real Pentest から学ぶ

ソース：

medium.com

脆弱性：XSS、FileUpload、CORS

訳：

偵察：アップロード機能の検討

アプリケーションをレビューしているときに、プロフィール画像のアップロード機能があることに気付きました。.
svgや.htmlといった他のファイル形式も受け付けられるかテストしてみたところ、驚いたことにSVGのアップロードも受け付けられ、そのままレンダリングされました。

アップロードしたファイルをブラウザで開くと、なんとポップアップが表示されました!

セッションはどこですか?

XSS を発見したときは常に、次のことを考えるべきです。

「セッションを盗んでアカウント乗っ取りを証明できますか？」

そこですぐにDevToolsを開いて確認しました document.cookie— しかし、アプリケーションは JWTベースのヘッダー認証 を使用していたため、セッションCookieは存在しませんでした。
これは防御の観点からは良いことですが、攻撃者にとっては、さらに深く掘り下げる必要があることを意味します。

次: localStorage。

しかし…驚いたことに、トークンは localStorageアップロードされた XSS ファイルを直接表示する場合。

XSS ページを表示すると、localStorage に JWT が見つかりません

最初の落とし穴：トークンは訪問後にのみ設定されます `/profile`

探索中に、ログインして /profileエンドポイントでは、フロントエンドのJavaScriptが動的にユーザーデータを取得し、その後JWTを localStorage。

JWTは/profileにアクセスした後にのみlocalStorageに表示されます

問題は次の通りです:

XSSページにはJWTがありません。 ブラウザに強制的にアクセスさせる必要があります。 /profileまず、JWT が保存されるのを待ってから、それを抽出します。

ペイロードの作成

このチェーンを自動化するために、次のような HTML ペイロードを作成しました。

負荷 /profile 静かにバックグラウンドで
少し待つ
JWTを抽出します /localStorageローカルストレージ
Burp Collaboratorサーバーに送信します

2つ目のキャッチ：CORSが再びヒット

ブラウザはトークンを送信しようとしたときにCORSエラーをスローしました。 fetch()。

心配しないでください。私は、 <img>代わりにタグ fetch()ブラウザは画像の読み込みをブロックしないため、クロスオリジンであっても CORS をバイパスします。

もう一度テストしてみると… コンソールにエラーは表示されませんでした 。

ゲームオーバー: トークンが盗まれ、セッションがハイジャックされました

Collaborator サーバーは JWT を正常に受信しました。

アカウントの乗っ取りを確認するために、ブラウザコンソールで次のコマンドを使用しました。

```
localStorage.setItem ' ( , 'token' PASTE_STOLEN_TOKEN_HERE ' ); ```

その後、ページを更新すると…私は被害者としてログインしていました。

最後に

この脆弱性は XSS だけに関するものではなく、 複数のレイヤーを連鎖させる ことに関するものでした。

ファイルアップロードの不適切な設定 - SVG/XSS を通過させる
トークンの保存場所 localStorageクッキーの代わりに
JWTは訪問後にのみ設定されます /profile
情報漏洩時のCORS制限
独創的なトリックを使ってCORSを回避する（例えば <img>タグ）

XSSを発見したら、 alert(1)— さらに深く ：

クッキーがない場合は、 localStorage そして sessionStorage。
トークンに直接アクセスできない場合は、どのページがトークンをトリガーするかを確認してください。
ブラウザロジックを自身に対して使用します (ナビゲーションの強制、待機、抽出、送信)。
CORSがフェッチをブロックした場合は、 <img>、 <script>、あるいは <form>！

ほなほな。

1. 隠しパラメータとエンドポイントが重要な理由

2. Google Dorksで露出したエンドポイントを見つける

Dork Example:

3. Google Dorksを使って隠れたパラメータを見つける

Dork Example:

4. デバッグと管理エンドポイントの発見

Dork Example:

5. APIドキュメントファイルの探索

Dork Example:

6. Google Dorksを組み合わせてパラメータとエンドポイントを見つける

例1：

例2:

7. 管理者権限を明らかにするクエリパラメータの検出

Dork Example:

結論：

ゼロから管理者になる4つのステップ

盗むことができたもの（でも盗まなかったもの）

倫理的なハッカーのための5つのプロのヒント

アプリでこれを修正する方法

偵察：アップロード機能の検討

セッションはどこですか?

最初の落とし穴：トークンは訪問後にのみ設定されます /profile

ペイロードの作成

2つ目のキャッチ：CORSが再びヒット

ゲームオーバー: トークンが盗まれ、セッションがハイジャックされました

最後に

最初の落とし穴：トークンは訪問後にのみ設定されます `/profile`