検索エンジンはコンテンツをインデックス化するために構築されました。しかし、攻撃者はそれを利用してあなたの間違いをインデックス化します。クエリ allintext：login ファイルタイプ:ログ 一見無害に見えるかもしれないが、実際には、認証フロー、認証情報、トークン、内部インフラストラクチャデータを含む公開ログファイルを発見する最も簡単な方法の一つである。
Googleがこれらのログを閲覧できるのであれば、攻撃者も閲覧できる。一度インデックス化されると、情報漏洩は避けられない。さらに、認証情報が公開可能なファイルに掲載された場合、情報漏洩は既に始まっている。
1. allintextを選ぶ理由：login ファイルタイプ:ログは見た目以上に危険です
Googleドークとは、高度な演算子を使用して、検索エンジンにインデックス登録されている機密情報や設定ミスのあるコンテンツを探し出す検索クエリのことです。Googleを悪用するものではなく、あなたの情報漏洩リスクを悪用するものです。
このクエリは2つの演算子を組み合わせています。
- allintext： 本文中にすべての用語が含まれるページを返します
- ファイルタイプ:ログ 結果を制限します
.logファイル
したがって：
手段： "単語を含むログファイルを表示してください login
一見すると些細なことのように思える。しかし実際には、次のような結果を招くことが多い。
- 公開されたウェブサーバーログ
- CI/CD ログは成果物としてアップロードされます
- デバッグログが誤って commitリポジトリにted
- 平文の認証情報を含むアプリケーションログ
これは検索エンジンのバグではありません。 データ漏洩の脆弱性 設定ミスが原因です。Googleは公開されている情報のみをインデックス化しました。
2. 攻撃者が公開されたログファイルから実際に何を見つけるか
攻撃者が走るとき allintext：login ファイルタイプ:ログ彼らは無作為に閲覧しているわけではない。認証痕跡を探しているのだ。
2.1 平文認証情報
ログには、次のようなエントリが頻繁に含まれています。
or
あるいはSMTP認証情報も：
認証ペイロードをログに記録することは、本番環境の認証情報を漏洩させる最も速い方法の一つです。そのため、たった1つのログファイルが漏洩するだけで、アクセス制御モデル全体が無効になってしまう可能性があります。
2.2 セッショントークンとJWT
パスワードがログに記録されない場合でも、トークンはしばしば記録される。
具体的な例を挙げますと、以下の通りです。
If CI/CD 人工物は公開されるものであり、秘密も公開される。Googleのドークは単に発見を加速させるだけだ。
2.4 クラウドおよびインフラストラクチャデータ
公開されたログには、次のような情報が含まれていることが多い。
- AWS アクセスキー
- Azureストレージ接続文字列
- 内部サービスURL
- データベース資格情報
- Redisエンドポイント
たとえ後で認証情報がローテーションされたとしても、攻撃者は以下の情報を入手している。
- インフラマッピング
- 命名規則
- 将来の攻撃のための標的情報
したがって、公開されたログは、アクセスと偵察の両方を可能にする。
3．そもそもこれらのログはどのようにして公開されるのか
ログは魔法のようにGoogleに表示されるわけではありません。公開されている情報に基づいてインデックス化されるのです。
3.1 設定ミスのあるWebサーバー
一般的なパターンは次のとおりです。
/logs/認証なしでアクセス可能なディレクトリ- ディレクトリ一覧表示が有効になっています
- NginxまたはApacheが生データを配信
.logファイル
HTTP経由でアクセス可能なログは、インデックス化可能です。
3.2 CI/CD 人工物の露出
典型的な間違い:
- パブリックアーティファクトが有効になっています GitHubアクション
- ログはオープンS3バケットにアップロードされました
- Pipeline 認証なしでアクセス可能なトレース
A pipeline ログを公開バケットに保存することは、事実上その秘密を公開することになります。
3.3 本番環境におけるデバッグモード
フレームワークのデフォルト設定は危険な場合がある。
さらに、過剰なリクエストログには以下が出力される可能性があります。
- ヘッダ
- トークン
- 完全なリクエストボディ
本番環境でデバッグログを有効にすると、アプリケーションが認証情報エクスポートツールになってしまいます。
3.4 Dockerとコンテナログ
コンテナ化された環境は、新たなリスクへの曝露経路をもたらす。
- ログは共有ボリュームにマウントされています
- サイドカーがログをセキュリティ保護されていないエンドポイントにエクスポートする
- 歳入録 dashboard一般公開されている
コンテナログがHTTPまたはオープンストレージ経由で公開されている場合、それらは検索可能になります。最終的にはインデックス化されます。
4. 現実的な攻撃の流れ：ドジから突破まで
典型的な攻撃チェーンは次のようになります。
攻撃者は以下を実行します。
- 発見物が明らかに
.logfile - エキス：
- JWTトークン
- 基本認証ヘッダー
- データベース接続文字列
認証を試みる対象:
- APIエンドポイント
- 管理パネル
- 内部サービス
認証が成功した場合、攻撃者は以下のことが可能です。
- 権限の昇格
- 横方向に移動する
- アクセス CI/CD
- サプライチェーンを危険にさらす
検索クエリから始まったものが、次のようになる。
- セッションハイジャック
- 内部認証情報スタッフィング
- Pipeline 乗っ取り
- 人工物による中毒
すべて公開されているログファイルからの情報です。
5. ログ記録が「多すぎる」ことがアプリケーションセキュリティ上の問題となる理由
ログ記録は中立ではありません。むしろ、 セカンダリデータストア.
機密データをログに記録すると、事実上、秘密情報の第二のコピーを作成することになります。
しかし、ログは脅威モデリングから除外されることが多い。STRIDEでは、これは明らかに以下に対応する。
開示情報
したがって、セキュア SDLC 実務ではログを以下のように扱うべきである。
- セキュリティ関連の成果物
- 機密資産
- 保護が必要なインフラ構成要素
脅威モデルがログを無視している場合、それは不完全です。
6. ログファイルにおける認証情報漏洩を防ぐ方法
6.1 シークレットのログ記録を停止する
絶対にログを取らない:
- パスワード
- トークン
- APIキー
- セッションID
- 認証ヘッダー
デバッグモードでも同様です。
可能な限り、自動編集機能を実装してください。
6.2 構造化された安全なログ記録
マスキングとフィルタリング機能を備えた構造化ログ記録を使用する。
例（Node.js）：
例 (Python):
重要な原則は単純だ。機密情報は決してログに記録されてはならない。
6.3 ログストレージのロックダウン
セキュリティ対策には以下が含まれるべきである。
- ディレクトリ一覧表示を無効にする
- 守ります
/logs/認証付きパス - バケットへのアクセスを制限する
- 保持ポリシーを適用する
- 保存時のログを暗号化する
ログはHTTP経由で一般にアクセス可能な状態にしてはならない。
6.4 CI/CD Guardrails
手動によるレビューでは不十分です。代わりに、自動化された管理体制を導入してください。
- アーティファクト公開前のログの秘密スキャン
- トークンが検出された場合はビルドを失敗させる
- 認証情報を含む成果物のアップロードを防止する
- 成果物のハッシュ検証
CI/CD インデックス作成が行われる前に、露出をブロックする必要があります。
7. Xygeni が allintext を防ぐ方法:login ファイルタイプ:ログ インシデント
問題はGoogleのドークではない。問題は露出度だ。したがって、インデックス登録前に予防策を講じる必要がある。
7.1 ログとアーティファクトにおける秘密情報の検出
Xygeniスキャン：
- アプリケーションログ
- CI/CD ジョブトレース
- 成果物を構築する
- ドッカーレイヤー
- シリアル化された出力
認証情報、トークン、または機密値が表示される場合 .log ファイルがあると、Xygeniはすぐにフラグを立てます。
7.2 CI/CD Guardrails そのブロック露出
手動レビューに頼る代わりに、 Xygeniはセキュリティを強化し、 pipeline レベル：
これ：
- ログにシークレットが表示されるとビルドが失敗する
- ブロック成果物の公開
- 偶発的な公衆への露出を防ぐ
- メインに到達する前に安全でないマージを停止します
CI ジョブがトークンを出力する場合、 pipeline 失敗します。
インデックス作成は行いません。
暴露なし。
事件は発生していません。
7.3 Googleが検知する前に左シフトを防ぐ
タイミングは重要です。
反応する代わりに：
Xygeniはこの問題を解決します：
- At commit 時間
- 間に pull request
- 間に pipeline 実行
- 成果物の公開前
ログが公開されない限り、Googleはそれをインデックス化しません。
最終的な結論：Googleがインデックスできるものは、攻撃者も既にインデックスしている。
ログは無害ではありません。実際、一時的なものであることはほとんどありません。デフォルトでは、ログは非公開ではありません。したがって、すべてのログファイルは、単なるデバッグ出力としてではなく、セキュリティに関連する資産として扱うべきです。
機密データが .log ファイルが作成され、一般に公開されます。 それはたちまち攻撃対象となってしまう。 さらに、検索エンジンに一度インデックス登録されると、その露出度は制御不能なほどに拡大してしまう。
解決策はログ記録を停止することではなく、責任あるログ記録を行い、保存と配布に関して厳格な管理体制を構築することです。つまり、セキュリティはアプリケーション自体だけでなく、可観測性レイヤーにも及ぶ必要があるのです。
代わりに：
- 秘密情報の記録を停止する
- ログ保管庫を閉鎖する
- 施行 pipeline guardrails
- 検出とポリシー適用を自動化する
最終的に, 予防はタイミングが重要だ。なぜなら一度 allintext：login ファイルタイプ:ログ ドメインが返された場合、既に事件が発生しています。
