REGEX For Hackers by Ben Sadeghipour and Adam Langley | Bug Bounty Village, DEF CON 33
三句話摘要
使用正則表達式（Regex）發現網絡安全漏洞，以及如何在 Bug Bounty 和 OSINT 中應用 Regex 進行資產探索和漏洞挖掘。 掌握正則表達式既能幫助開發者寫出更安全的驗證邏輯，也能幫助安全研究者通過 GitHub 系統化地發現漏洞，相比傳統掃描工具效率和精準度均有質的提升。 Regex 基礎決定安全性 — 字符集、量詞、錨點、分組等每個元素的實現都影響驗證邏輯。開發者常試圖用 Regex 驗證域名或 URL，但由於對語法理解不足，導致規則可被簡單的技巧繞過，如添加子域或使用未轉義的句號。
重點整理
重點- 1
Regex 基礎決定安全性 — 字符集、量詞、錨點、分組等每個元素的實現都影響驗證邏輯。開發者常試圖用 Regex 驗證域名或 URL，但由於對語法理解不足，導致規則可被簡單的技巧繞過，如添加子域或使用未轉義的句號。
- 2
三類常見 Regex 安全漏洞 — 缺少末尾錨點 $（允許在驗證後追加內容）、句號未轉義為 \.（被當作通配符匹配任意字符）、過度寬鬆的通配符如 .*（匹配過多內容）。這些漏洞特別容易出現在 PostMessage 安全檢查、CORS origin 驗證、SSRF 防護中。
- 3
GitHub 是系統化漏洞探索的金礦 — 許多開發者無意中在開源代碼中洩露內部 API 路由、子域配置、環境變數、密鑰等。通過精心設計的 Regex 搜尋，可以發現傳統子域名工具（如 subfinder）無法找到的隱藏資產，提高目標的針對性。
- 4
從防禦視角反向應用於代碼審查 — 相同的 Regex 技術可用於審查自有代碼，搜尋潛在的 XSS（echo 加未驗證輸入）、RCE（system 調用接收用戶輸入）、敏感資訊洩露等，並可針對開源框架代碼進行預先審查。
實用技巧與重點
乾貨- Regex 基礎語法
- 字符集：[A-Z]、[0-9]、[a-zA-Z0-9_]；反向 [^abc]
- 量詞：+ (1+)、* (0+)、? (0-1)、{16} (確切)、{16,19} (範圍)
- 錨點：^ (開始)、$ (結束)、\b (字邊界)
- 捷徑：\d (數字)、\w (字母/數字/下劃線)、\s (空白)；大寫為反向
- 轉義：\. 表示字面句號；\/ 表示字面斜杠
- 分組：(...)、| (或)
- 常見漏洞規則與修復
- PostMessage 驗證不當：www.trusted.com → 應改為 ^https:\/\/www\.trusted\.com$
- 開放重定向：缺 ^ 和 $ → 應為 ^https:\/\/trusted\.com\/.*
- CORS Origin 檢查：trusted\.com → 應為 ^https:\/\/([a-z0-9-]+\.)?trusted\.com$
- SSRF 防護：linkedin\.com → 應為 ^https:\/\/linkedin\.com\/[a-zA-Z0-9_\/]*$
- GitHub 搜尋 Regex 模式
- 子域發現：domain_name (搜尋證書或洩露的配置文件)
- API 路由：api、\/api\/v1、app-api-
- JWT 令牌：EYJ[A-Za-z0-9_-]+=
- AWS 密鑰：AKIA[0-9A-Z]{16}
- Base64 編碼：[A-Za-z0-9+/]+=*
- Actuator 堆轉儲：環境變數、HTTP 請求、認證資訊
- 代碼漏洞：echo.\$_(GET|POST)、system.\$_(GET|POST)
- 實際工具與應用
- Creatures of Habit：自動爬取 GitHub 上所有框架路由（Flask、Django、Laravel、Rails、Spring Boot 等）
- 參數字典生成：提取開發者常用的參數名、HTTP 頭、方法名
- Actuator 堆轉儲解析：strings + grep，搜尋 password、jwt、cookie、bearer token、equals 符號結尾的環境變數
結論
結論“掌握正則表達式既能幫助開發者寫出更安全的驗證邏輯，也能幫助安全研究者通過 GitHub 系統化地發現漏洞，相比傳統掃描工具效率和精準度均有質的提升。”
完整解析
詳細這場 DefCon 工作坊由 Ben Sadegapur（Hacker One 安全教育前負責人，1.8 百萬美元 Bounty 獵手）和 Adam Langley（20 年 Web 開發經驗，CTF 和教育實驗室創建者）共同講述。兩人共同創辦了 Hacking Hub，致力於培訓下一代安全研究者。
講座分為兩大部分。第一部分是 Regex 基礎教學。講者從傳統字符串匹配函數的局限性入手，說明為什麼需要 Regex。例如，驗證 IP 地址範圍、郵件域名後綴、信用卡號格式（數字、連字符、空格的各種組合）等場景，用 if-else 語句會非常繁瑣，而 Regex 能用一條簡潔規則解決。
接著介紹了 Regex 的核心概念，包括字符集（允許指定一組字符，支持範圍和反向）、量詞（控制匹配次數，如 + 表示 1 或以上，* 表示 0 或以上，? 表示可選，{n,m} 表示精確範圍）、錨點（^ 和 $ 分別指定字符串開始和結束）、分組與提取（用括號實現，可用於重複模式和數據提取）、捷徑（如 \d 代表數字，\w 代表字母/數字/下劃線，\s 代表空白，大寫版本為反向）。講者強調了一個容易被忽視但極其重要的細節：句號 . 是通配符，匹配除換行外的任意字符，如果要匹配字面句號必須轉義為 \.
講座的核心是揭示開發者在使用 Regex 進行安全驗證時的常見錯誤。最典型的三類漏洞是：缺少末尾錨點 $，導致攻擊者能在通過驗證的字符串後追加內容；句號未轉義，被當作通配符允許任意字符；過度寬鬆的通配符如 .* 或 .+。這些錯誤在 PostMessage 安全檢查中尤為常見，開發者試圖驗證消息來源是否為信任域名 www.trusted.com，但沒有末尾 $，攻擊者可註冊 www.trusted.com.attacker.com；沒有轉義句號，wwxtrusted.com 也能通過。類似漏洞還出現在開放重定向（/redirect?url= 參數檢查）、CORS Origin 驗證、SSRF 防護等場景，都因為 Regex 實現不當導致可被繞過。
第二部分介紹如何利用 Regex 在 GitHub 上進行系統化的漏洞探索。這是講者的核心創新，他已逐漸放棄傳統的子域名掃描工具，轉而用 Regex 直接在 GitHub 上搜尋。原因是：其他人都在用傳統工具，結果重複；GitHub 上存在大量開發者無意洩露的敏感資訊。具體應用包括：用 Regex 搜尋子域名（例如，從 cert.sh 洩露的通配符證書推導子域，再在 GitHub 上搜尋），尋找 API 路由（搜尋特定公司域名加 /api，或搜尋 app-api、app_api 等常見命名模式），發現隱藏的 JWT 令牌和 AWS 密鑰（通過特定格式的 Regex），甚至解析 Spring Boot Actuator 的堆轉儲提取環境變數和認證。
講者分享了具體案例。在一個 6 年以上歷史的 Hacker One 公開項目上，他通過 Regex 搜尋發現了一個公司內部的 Artifactory 實例，該實例既不在官方子域名列表中，也不在任何公開的資產掃描工具中，但通過推導可能的子域並在 GitHub 上搜尋，最終被找到。訪問該實例導致獲得公司源代碼，報酬為 5000-6000 美元。另一個案例是 API 路由通常遵循特定的五段式命名模式（地區-應用名稱-環境-國家等），雖然難以逐個爆破，但一旦在 GitHub 上找到任何一個實例洩露，就能推導出所有相似的路由，其中許多暴露了 Spring Boot Actuator 的 /actuator/heapdump 端點，允許下載內存轉儲並通過 Regex 提取密鑰、環境變數、HTTP 請求等敏感數據。他還開發了工具如 Creatures of Habit 來自動爬取 GitHub 上所有主流框架（Flask、Django、Laravel、Rails、Express、Spring Boot 等）的路由定義，以及參數字典生成工具來收集開發者實際使用的參數名和 HTTP 頭。
此外，講者強調了 Regex 在代碼審查中的應用。可以搜尋自有代碼中的潛在漏洞，如 echo 後跟未驗證的 $_GET/$_POST（XSS）、system 調用接收用戶輸入（RCE）、甚至搜尋代碼中定義的 Regex 本身進行逐個審查。由於許多大企業會開放內部框架的源代碼或在 GitHub 上發布開源版本，通過分析這些代碼可以了解他們內部使用的模式和工具，進而應用到漏洞挖掘中。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
