1. 從“搜不到”到“信息過載”一次實戰視角的轉變作為一名在安全研究和開源項目領域摸爬滾打了十多年的老手我見過太多人把“信息收集”想得太復雜或者太簡單。復雜的人上來就想用各種自動化工具狂轟濫炸結果被海量無效數據淹沒簡單的人只會用搜索引擎搜個標題然后抱怨“網上啥也找不到”。其實真正的效率往往藏在那些被我們忽略的、最基礎的“高級搜索”技巧里。今天我們不談那些復雜的爬蟲框架和商業情報系統就聊聊如何把Google Hacking和GitHub這兩個幾乎人人可用的免費工具組合成一套威力驚人的信息收集“瑞士軍刀”。你可能覺得Google不就是搜網頁嗎GitHub不就是看代碼嗎但我要告訴你在熟練的從業者手里它們能挖出的東西遠超你的想象從無意間泄露的服務器配置文件、數據庫連接字符串到企業內部的技術文檔、員工通訊錄再到未授權訪問的API接口、甚至是完整的源代碼倉庫備份。這些信息對于安全評估、競爭對手分析、技術調研或是開源項目貢獻都有著不可估量的價值。這篇文章就是為你拆解這套組合拳的核心心法、實戰語法和那些“教科書上不會寫”的避坑經驗。無論你是安全工程師、開發者、技術調研員還是好奇的學習者都能從中找到直接“抄作業”的路徑。2. Google Hacking超越關鍵詞搜索的“語法藝術”很多人用Google還停留在“關鍵詞1 關鍵詞2”的階段。這就像拿著一把萬能鑰匙卻只在擰最普通的鎖。Google Hacking本質上是一套利用Google搜索引擎高級語法進行精準過濾和深度挖掘的技術。它的核心不是“黑”進Google而是“理解”Google如何索引和呈現信息并用精確的指令與之對話。2.1 核心語法庫你必須掌握的“搜索運算符”這些運算符是你的基本武器庫。單獨使用威力有限但組合起來就能構建出極其精準的搜索指令。site:這是最基礎也最強大的運算符之一。它限定搜索范圍到特定的域名或網站。例如site:github.com就只在GitHub官網內搜索。但它的威力在于子域名和路徑限定比如site:docs.internal.company.com可以專門搜索某個公司內部文檔子站。filetype:按文件擴展名搜索。這是尋找特定類型文檔如配置文件、數據文件、辦公文檔的利器。例如filetype:pdf搜索PDFfiletype:xls或filetype:xlsx搜索Excel表格filetype:sql搜索SQL文件filetype:env或filetype:ini或filetype:conf搜索各類配置文件。inurl:與intext:和intitle:inurl:用于搜索URL中包含特定關鍵詞的頁面比如inurl:admin找后臺登錄頁面。intext:在網頁正文中搜索intitle:在網頁標題中搜索。通常intitle的匹配精準度更高。“精確短語”使用雙引號將關鍵詞括起來表示完全匹配這個短語忽略分詞和同義詞。例如搜索“database_password”和database_password結果天差地別。-(減號)排除包含某個關鍵詞的結果。這在過濾噪音時極其有用。比如你想找關于“Python Flask”的教程但不想看視頻可以搜Python Flask tutorial -video。*(通配符)代表一個未知的單詞或詞組。常用于補全短語或尋找特定模式。例如“index of” * .sql可以用來尋找可能開放目錄索引的、包含SQL文件的網站。related:尋找與指定網站相似的網站。用于發現競爭對手或同類平臺related:github.com可能會返回GitLab、Bitbucket等。cache:查看Google對某個URL的緩存版本。有時當前頁面無法訪問或已修改緩存頁可能保留著關鍵的歷史信息。2.2 實戰組合拳從場景到搜索指令理解了語法我們來看如何組合。以下是一些經典且高價值的搜索模式你可以直接套用或舉一反三。場景一尋找暴露的配置文件或敏感文件配置文件里常有數據庫密碼、API密鑰、服務器路徑等。搜索指令示例filetype:env DB_PASSWORD site:target.com filetype:yml password intitle:“index of” .git “API_KEY” site:github.com第一行尋找包含“DB_PASSWORD”這個字符串的.env文件。第二行在target.com域名下尋找包含“password”的YAML配置文件。第三行尋找標題為“index of”且包含.git目錄的頁面可能暴露Git倉庫。第四行在GitHub上搜索包含“API_KEY”的代碼或文檔。場景二發現特定的管理后臺或登錄界面inurl:/admin/login intitle:“login” “admin” site:target.com inurl:wp-admin site:target.com這些指令可以幫助你發現目標站點的后臺管理入口用于安全評估中的入口點識別。場景三尋找公開的文檔與數據filetype:pdf “內部培訓” site:company.com filetype:xls “員工名單” OR “通訊錄” site:docs.google.com/spreadsheets/d/ “confidential”第一行尋找公司域名下的內部培訓PDF。第二行尋找包含“員工名單”或“通訊錄”的Excel文件。第三行嘗試尋找公開分享的Google Sheets文檔中可能包含的“confidential”機密信息。請注意搜索和訪問他人未明確公開的敏感數據可能涉及法律和道德問題務必在授權范圍內進行。場景四探索子域名和目錄結構site:*.target.com site:target.com inurl:backup site:target.com -www第一行搜索target.com的所有子域名*是通配符。第二行在目標網站中尋找包含“backup”的URL路徑。第三行搜索target.com但排除www.target.com有助于發現非WWW的其他子域或根目錄內容。注意Google的搜索語法和索引策略并非一成不變會隨時間調整。某些過于寬泛或可能被濫用的語法如早期一些用于查找敏感信息的特定組合可能被限制或返回結果不同。實踐是檢驗真理的唯一標準。2.3 高級技巧與避坑指南使用“搜索工具”進行時間和地區過濾在Google搜索結果頁點擊“工具”可以限定時間范圍如過去一年、過去一個月這對于尋找最新泄露的信息或技術文檔非常有用。也可以限定地區有時不同地區的Google索引結果會有差異。結合其他搜索引擎Bing、DuckDuckGo等搜索引擎也支持類似的高級語法可能略有不同交叉使用有時能發現Google未索引到的結果。警惕“蜜罐”與法律風險網絡上存在一些故意放置的、包含虛假敏感信息的“蜜罐”文件用于追蹤和識別掃描行為。此外未經授權訪問、下載或利用通過搜索發現的、本不應公開的敏感信息如個人數據、商業機密是違法行為。所有技術操作都應在合法合規的授權測試或個人學習研究范圍內進行。結果驗證與上下文判斷搜到的結果不一定就是“寶藏”。一個config.php.bak文件可能只是本地開發環境的無用備份一個包含“password”的文檔可能只是在講密碼學原理。務必點開查看上下文結合其他信息綜合判斷其價值。3. GitHub不止是代碼倉庫的“情報金礦”如果說Google是廣撒網的漁夫那么GitHub就是需要精準垂釣的深海漁場。作為全球最大的開源代碼托管平臺GitHub上除了項目代碼還充斥著大量的提交歷史、問題討論、Wiki文檔、Gist代碼片段以及……無意中提交的敏感信息。3.1 GitHub搜索比你想的更強大GitHub自身的搜索功能非常強大支持代碼、倉庫、用戶、議題等多種維度的搜索并且有豐富的過濾條件。代碼搜索 (https://github.com/search?q...typecode)這是核心中的核心。你可以直接搜索代碼片段中的字符串。語法支持類似Google的“短語”、-排除、language:編程語言、repo:所有者/倉庫名、path:文件路徑等過濾器。示例“aws_access_key_id” language:yml password extension:json “prod” “BEGIN RSA PRIVATE KEY” -language:markdown第一行在YAML文件中搜索AWS訪問密鑰ID。第二行在JSON文件中搜索包含“password”和“prod”可能表示生產環境的內容。第三行搜索可能包含RSA私鑰的代碼塊但排除Markdown文件因為Markdown中可能只是示例文本。倉庫搜索 (https://github.com/search?q...typerepositories)用于尋找特定主題、技術棧或公司的項目。語法stars:、forks:、pushed:最后推送時間、topic:主題、in:name,description,readme在名稱、描述或README中搜索。示例in:name,description kubernetes dashboard company:target-org pushed:2024-01-01 language:go第一行在名為“target-org”的公司賬戶下尋找名稱或描述中包含“kubernetes dashboard”的倉庫。第二行尋找2024年1月1日之后有更新的Go語言項目。3.2 挖掘提交歷史與分支被遺忘的“秘密”代碼的當前版本可能是干凈的但歷史提交Commit History里可能藏著“黑歷史”。開發者可能不小心把密鑰寫進代碼然后提交之后又用新的提交刪除了它但那個包含密鑰的提交記錄依然存在于歷史中。查看提交歷史在倉庫頁面點擊“commits”即可。你可以瀏覽所有歷史提交的差異diff。搜索提交信息在倉庫內可以使用GitHub的搜索框選擇“In this repository”然后輸入關鍵詞它也會搜索提交信息。關注分支除了默認的main或master分支dev、test、staging等分支可能包含未合并到主分支的、更不穩定的代碼有時也更容易發現調試信息或臨時配置。工具化輔助手動翻找歷史效率低。可以使用像git log命令配合-p顯示差異和-S查找引入或移除特定字符串的提交選項在本地克隆的倉庫中進行深度搜索。例如git clone https://github.com/username/repo.git cd repo git log -p -S “API_KEY” --all這條命令會搜索整個倉庫所有分支的歷史顯示所有包含“API_KEY”字符串變化的提交詳情。3.3 關注Issues、Wiki和GistIssues問題用戶反饋、錯誤報告、功能討論中可能會粘貼錯誤日志、配置文件片段、甚至臨時生成的訪問令牌。這些信息通常不會被仔細審查。Wiki項目的Wiki頁面可能包含部署指南、環境配置說明里面有時會寫下示例配置而示例配置中的密碼可能被不小心用于生產環境。GistGitHub的代碼片段粘貼服務。很多人用它來分享配置、日志或臨時代碼。通過搜索https://gist.github.com/search?qyour_keyword可能會發現一些公開的敏感片段。3.4 GitHub信息收集的實戰心得與風險控制善用“通知”功能在GitHub上關注Watch你感興趣的公司或技術領域的頂級倉庫可以及時了解其代碼動態和安全更新。自動化工具謹慎使用有諸如gitrob、truffleHog等工具可以自動化掃描GitHub倉庫歷史中的敏感信息。但在大規模、無差別地對他人倉庫進行掃描前務必三思。這可能會觸發GitHub的速率限制甚至被視為濫用行為。最好在擁有明確目標如對自己公司的倉庫進行安全審計時使用。道德與法律是高壓線這是最重要的一點。通過GitHub搜索發現的、明確屬于他人且非故意公開的敏感信息如數據庫密碼、個人令牌正確的做法是通過Security Advisory安全通告功能或直接聯系倉庫所有者進行負責任的披露而不是自行利用或傳播。許多公司都有針對白帽黑客的漏洞獎勵計劃。信息關聯分析一個GitHub賬號可能關聯一個郵箱這個郵箱可能在其他論壇、社交平臺使用。結合Google搜索可以構建更完整的個人或組織畫像。但這同樣需要嚴格在合法合規的范圍內進行。4. GH與Google的聯動112的偵查網絡單獨使用Google或GitHub已經很強但將它們聯動起來才能發揮最大效能。思路是用一方發現線索用另一方進行深度驗證和擴展。聯動策略一從GitHub到Google場景你在GitHub上發現某公司company-x的一個舊倉庫里面有一個config.example.yaml文件提到了一個內部服務域名internal-service.company-x.net。操作立刻將這個內部域名拿去Google搜索site:internal-service.company-x.net。也許這個子域名本身沒有在GitHub的其他地方出現但可能被其他外部文檔、博客文章甚至錯誤頁面引用從而暴露了更多信息。進階搜索“internal-service.company-x.net” filetype:pdf也許能找到流出的內部架構圖或設計文檔。聯動策略二從Google到GitHub場景你用Google搜索某開源技術棧的部署問題發現一篇個人博客提到了一個具體的錯誤并附上了他的docker-compose.yml片段里面包含了一個自定義的鏡像路徑。操作將這個鏡像路徑中的用戶名或項目名拿到GitHub上搜索user:博客中的用戶名或repo:博客中的項目名。很可能找到他個人的配置倉庫里面可能有更完整的、甚至包含測試環境敏感信息的配置文件。進階用Google搜索“不小心提交了密碼” site:github.com可能會找到一些開發者自曝的、用于警示他人的案例倉庫這些是絕佳的學習材料。聯動策略三交叉驗證與去偽存真場景你通過某種渠道獲得了一個疑似某公司的API密鑰片段如sk_live_51...。操作在GitHub上搜索這個片段“sk_live_51”看是否有任何公開代碼庫中包含它。在Google上搜索這個片段“sk_live_51”看是否有任何論壇、帖子或文檔中提及。如果兩邊都找不到任何匹配那么這個密鑰要么是假的要么是極其私密且未被泄露的。如果只在某個不起眼的個人Gist中找到那么泄露范圍可能較小風險相對可控對密鑰所有者而言。5. 構建系統化的信息收集流程與思維掌握了工具和技巧還需要系統化的流程和思維才能從隨機的“發現”變成有目的的“收集”。5.1 定義目標與范圍這是第一步也是最重要的一步。沒有目標的信息收集就是網絡沖浪。你是為了什么安全滲透測試需授權競爭對手產品技術棧分析尋找某個開源軟件的特定使用案例追蹤某個技術專家的最新項目你的目標是什么一個公司target.com一個開源項目project-x一類技術“real-time dashboard”你的范圍是什么只限公開信息包括可能無意公開的敏感信息需謹慎時間范圍最近一年5.2 關鍵詞字典與搜索迭代不要指望一次搜索就能成功。信息收集是一個迭代的過程。建立初始關鍵詞列表基于你的目標列出核心關鍵詞、相關技術術語、可能的命名規范如prod_config,staging,backup_2024、常見的敏感文件名稱.env,config.php,id_rsa、常見的敏感字符串模式password,api_key,secret。執行首輪搜索使用Google和GitHub的語法組合進行初步搜索。保存有價值的發現。從結果中提取新關鍵詞在你發現的文檔、代碼、文件名、路徑、用戶名、郵箱、內部術語中提取新的關鍵詞加入你的字典。例如發現了一個內部服務器名svc-payment-internal立刻將其作為新關鍵詞。迭代搜索用擴充后的關鍵詞字典進行新一輪搜索。如此循環像滾雪球一樣擴大信息面。5.3 信息整理、驗證與報告收集到的信息是原始礦石需要提煉。整理使用筆記軟件如Obsidian、Notion、電子表格或專用工具如Maltego的社區版可用于可視化關聯但需注意合規性對信息進行分類整理。例如域名/子域名、員工信息來自LinkedIn或GitHub、技術棧框架、數據庫、云服務、API端點、潛在漏洞點暴露的管理后臺、配置文件。驗證并非所有信息都是準確或最新的。需要交叉驗證時效性檢查文件的最后修改日期、GitHub倉庫的最后提交時間、Google搜索結果的時間戳。真實性這個config.ini文件是真實的生產配置還是開發環境下的示例這個API密鑰是有效的還是已經被撤銷的可能需要通過一些無害的、非侵入性的方式驗證如訪問一個公開的API狀態端點而不是嘗試登錄。關聯性這條信息確實屬于你的目標嗎還是只是同名或巧合報告根據你的目的生成輸出。如果是安全評估需要清晰列出發現的風險項、證據截圖、風險等級和建議修復方案。如果是技術調研則需要總結技術選型、架構特點、活躍度等。5.4 自動化輔助與效率工具完全手動效率太低但全自動又容易失控。推薦人機結合瀏覽器書簽與搜索模板將常用的Google搜索語法如site:target.com filetype:pdf和GitHub搜索URL保存為書簽一鍵調用。簡易腳本對于重復性的工作比如用不同的關鍵詞組合批量搜索GitHub代碼可以寫簡單的Python腳本調用GitHub API注意遵守速率限制。例如使用requests庫和PyGithub庫。# 示例使用PyGithub搜索代碼 (需安裝PyGithub庫并配置GitHub Token) from github import Github import time g Github(“your_github_token_here”) # 在GitHub設置中生成Personal Access Token queries [‘“aws_access_key” language:yaml’, ‘“database_password” filetype:env’] for query in queries: try: results g.search_code(query) print(f” 搜索結果: {query} ”) for result in results[:5]: # 取前5個結果 print(f”Repo: {result.repository.full_name}”) print(f”File: {result.path}”) print(f”URL: {result.html_url}”) print(“---”) time.sleep(2) # 禮貌性延遲避免觸發速率限制 except Exception as e: print(f”搜索 {query} 時出錯: {e}”)重要提醒使用API必須遵守 GitHub服務條款 和 可接受使用政策 嚴禁用于抓取大量數據、干擾服務或侵犯隱私。專用OSINT工具如theHarvester用于收集郵箱、子域名、Amass子域名枚舉、Sherlock跨平臺用戶名搜索等可以與Google/GitHub收集的信息進行互補。但這些工具的使用同樣需要合規。6. 法律、道德與個人隱私的邊界這是整個信息收集活動中不可逾越的底線。技術是中立的但使用技術的人必須負責。授權是前提任何針對非自己所屬或未明確授權目標的、帶有安全測試性質的信息收集行為都必須獲得書面授權。未經授權的測試即使只是搜索在某些司法管轄區可能構成違法。區分“公開”與“可訪問”一個文件因為服務器配置錯誤而能被互聯網訪問可訪問并不意味著它意圖被公開公開。例如一個位于https://target.com/backup/config.bak的文件如果公司本意是內部使用但錯誤地將其置于可公開訪問的目錄這屬于安全漏洞。發現此類信息應通過負責任的披露渠道告知所有者而非自行利用。尊重個人隱私通過信息收集拼湊出的個人身份信息PII如員工郵箱、姓名、社交賬號等嚴禁用于騷擾、社工攻擊或任何非法用途。遵守平臺政策嚴格遵守Google和GitHub的使用條款。不要使用自動化工具進行暴力搜索或抓取以免IP被封鎖。善意與建設性將你的技能用于建設性的目的幫助開源項目發現并修復安全問題提高自己所在組織的安全水位進行合法的技術研究。網絡環境的健康需要每個從業者共同維護。在我多年的實踐中最大的體會是最強大的工具不是某個軟件而是好奇心加上嚴謹的方法論再套上法律與道德的緊箍咒。Google Hacking和GitHub搜索就像給你的好奇心裝上了望遠鏡和顯微鏡讓你能看到互聯網表面之下的豐富層次。但記住看得越清責任越大。每一次搜索的背后都應有明確的目的、邊界的意識和善意的初衷。希望這篇長文能為你打開一扇窗看到更廣闊的信息世界同時也幫你樹立起那面不可或缺的“邊界墻”。