搜尋引擎最初是為了索引內容而建構的。然而，攻擊者卻利用它們來索引你的錯誤。查詢 allintext：login 文件類型：日誌 看起來似乎無害。但實際上，這是發現包含身份驗證流程、憑證、令牌和內部基礎架構資料的暴露日誌檔案的最簡單方法之一。
如果谷歌能看到這些日誌，攻擊者也能看到。一旦被索引，洩漏就不可避免。此外，當憑證出現在可公開存取的文件中時，安全漏洞就已經存在了。
1. 為什麼選擇 allintext：login 文件類型：日誌比看起來更危險
Google dork 是一種使用進階運算符的搜尋查詢，用於尋找搜尋引擎索引的敏感或配置錯誤的內容。它並非利用 Google 的漏洞，而是利用你的資訊外洩風險。
此查詢結合了兩個運算子：
- allintext： 傳回的頁面正文中所有術語均已出現。
- 文件類型：日誌 將結果限制為
.log檔
因此：
方法： ”請顯示包含該字的日誌文件 login“
乍一看，這似乎微不足道。然而，在實踐中，它往往會帶來以下後果：
- 公開的網頁伺服器日誌
- CI/CD 日誌已作為工件上傳
- 偵錯日誌意外遺失 committed 到儲存庫
- 包含明文憑的應用程式日誌
這不是搜尋引擎的漏洞。相反，這是… 資料外洩漏洞 這是配置錯誤導致的。谷歌只是簡單地索引了公開可訪問的內容。
2. 攻擊者在暴露的日誌檔案中實際發現了什麼
當攻擊者運行 allintext：login 文件類型：日誌他們並非隨意瀏覽，而是在尋找身分驗證痕跡。
2.1 明文憑證
日誌中經常包含以下條目：
or
甚至是 SMTP 憑證：
記錄身份驗證有效負載是洩漏生產環境憑證最快的方法之一。因此，一個暴露的日誌檔案就可能使整個存取控制模型失效。
2.2 會話令牌和 JWT
即使密碼不被記錄，令牌通常也會被記錄。
例如：
If CI/CD 既然文物是公開的，那麼秘密也就公開了。谷歌搜尋技巧只是加速了發現過程。
2.4 雲端和基礎設施數據
公開的日誌通常會揭示：
- AWS 訪問密鑰
- Azure 儲存體連接字串
- 內部服務網址
- 資料庫憑證
- 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 和容器日誌
容器化環境引入了新的暴露途徑：
- 日誌已掛載到共用磁碟區。
- Sidecar 將日誌匯出到不安全的端點
- 日誌 dashboard具有公共存取權限
如果容器日誌透過 HTTP 或開放儲存公開，則可以對其進行搜尋。最終，它們會被建立索引。
4. 真實的攻擊流程：從技術分析到突破
典型的攻擊鏈如下圖所示：
攻擊者運作：
- 發現暴露
.log文件 - 提取物：
- 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 作業追蹤
- 建構工件
- Docker 層
- 序列輸出
如果憑證、令牌或敏感值出現在 .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 文件類型：日誌 返回您的域名，事件已經開始。
