你升版了嗎？談談 Ruby 3 的 ReDoS 防禦設計 | Have You Upgraded Yet? Diving into Ruby 3’s ReDoS Defense Design

「每次提起升版就被已讀。」
WebConf 2025 Huli 的演講重燃大家對 ReDoS 的關注，那 Ruby 圈是如何應對此安全性議題呢？
2022 年底，Ruby 3.2 大幅改善了 Regexp 的安全性與效能；隨著 Ruby 4 發佈、Ruby 3.2 即將進入 EOL，來談談 #17837 與 #19104 的設計與權衡，以及為何在 2026 更應重視 ReDoS 議題。

• RubyJam 2026.03 活動頁面: https://rubytaiwan.kktix.cc/events/rubyjam2603
• Ruby Taiwan 更多社群資訊 : https://linktr.ee/rubytaiwan2008

"Left on read... every time I suggest a version upgrade."

The talk by Huli at WebConf 2025 reignited the community's focus on ReDoS (Regular Expression Denial of Service). But how exactly is the Ruby world tackling this security challenge?

In late 2022, Ruby 3.2 introduced significant improvements to Regexp security and performance. With Ruby 4 recently released and Ruby 3.2 approaching its EOL, let’s discuss the design and trade-offs behind Feature #17837 and #19104, and why we should pay attention to ReDoS more than ever in 2026.

• RubyJam 2026.03 Event Page: https://rubytaiwan.kktix.cc/events/rubyjam2603
• RubyTaiwan All links: https://linktr.ee/rubytaiwan2008

Transcript

1. $ time ruby -e '/^😈*升?😈*$/.match?(' \ -e '"😈" * 20263 + "談談 Ruby 3 的 ReDoS 防禦設計")' Speaker.find_by(name: 'Kasa') Date.new(2026, 3, 17) 1
2. $ time ruby -e '/^😈*升?😈*$/.match?(' \ -e '"😈" * 20263 + "談談 Ruby 3 的 ReDoS 防禦設計")' 2 🐢 🐇
3. $ time ruby -e '/^(\w+|😈+)*$/.match?(' \ -e '"😈" * 20263 + "談談 Ruby 3 的 ReDoS 防禦設計")' 3 😨 🐇
4. 👋 self.inspect ☂ Kasa @k_hno3 💼 NTU COOL 💎 ['Ruby Taiwan Organizer'].push('RubyKaigi 2026 Helper') 🗣 [ :中文, :EN, :日本語 ] 🤖 [ :Ruby, :TypeScript, :Python ] 🫶 [ 'Anime', 'English Parliamentary Debate', 'Onsen Ryokan!' ] 4
5. 👋 self.inspect ☂ Kasa @k_hno3 💼 NTU COOL 💎 ['Ruby Taiwan Organizer'].push('RubyKaigi 2026 Helper') 🗣 [ :中文, :EN, :日本語 ] 🤖 [ :Ruby, :TypeScript, :Python ] 🫶 [ 'Anime', 'English Parliamentary Debate', 'Onsen Ryokan!' ] 5 # …偶爾也寫一點 ReactJS # …偶爾也弄一點 DevOps # …偶爾也碰一點 GPU 跑跑 self-host LLM & ASR 模型 # 看得出來專長就是...雜耍 + 纏鬥 🤡 …還 沒有點到資安 今天就是個 好奇寶寶，拋磚引玉， 帶大家 吃瓜 Ruby 語言安全性發展啦！ 請多多交流補充 󰚥
6. 🎯 不是...而是... 󰢄 學到怎麼改善效能低落的 Regex 本人 󰢄 學到快速心算 (?) 判別 Regex 風險的方法 󰢄 學到 NFA 和 DFA 的引擎原理差異 󰢄 看好多歷史災難 CVE 案例 󰢏 知道 Ruby 近年針對 ReDoS 議題發布了什麼版本更新 󰢏 知道社群在做相關語言/套件設計時，貢獻維護者們的想法（吃瓜） 󰢏 知道可以用什麼小工具檢查 󰢏 知道為什麼 2026 我想再度注意這題 6
7. topics.each 🛡 那天，又被 SonarQube 掃了顆 ReDoS 😈 小惡魔的啓示：Backtracking 🍿 那 Ruby 怎麼應對呢？吃瓜！ ⏰ #17837 Add support for Regexp timeouts ⚡ #19104 Introduce the cache-based optimization for Regexp matching 󰝊 Ruby 3.2 之後... 🔍 我想小心預防，但人腦轉不過來啦，有沒有好用工具？ 🤔 為什麼想在 2026 重提 ReDoS 議題 📢 Organizer 中場小公告 7
8. 🛡 那天，又被 SonarQube 掃了顆 ReDoS 8
9. 🛡 那天，又被 SonarQube 掃了顆 ReDoS 9
10. 🛡 那天，又被 SonarQube 掃了顆 ReDoS 然後意識到...滿常在路邊看到： 10 https://about.gitlab.com/releases/2026/02/25/patch-release-gitlab-18-9-1- released/ https://github.com/advisories/GHSA-8r9q-7v3j-jr4g
11. 🛡 那天，又被 SonarQube 掃了顆 ReDoS 被掃的是 TypeScript 專案，於是開始好奇 Ruby 的情況如何... 11 2024-11-05 2025-12-15
12. 🛡 那天，又被 SonarQube 掃了顆 ReDoS 2023~2025 很棒的演講，留友看 12 https://rubykaigi.org/2023/presentations/maken owjust.html https://rubykaigi.org/2023/presentations/lmt_swall ow.html https://webconf.tw/agenda/17
13. 😈 小惡魔的啓示：Regex Backtracking 13
14. 😈 小惡魔的啓示：Regex Backtracking 🔗 regex101.com /^😈*升?😈*$/.match?("😈😈😈已讀") 14
15. 🍿 那 Ruby 怎麼應對呢？吃瓜！ 15
16. 🍿 那 Ruby 怎麼應對呢？吃瓜！ ⏰ #17837 Add support for Regexp timeouts - 提案 16 🙋 ReDoS 是多年常見 的風險，我認為應該在 語言本身做一些防護設 計。 有一些手法可以透過安 裝外部工具實踐，但不 是所有的 Ruby runtime 都能簡單處理。
17. 🍿 那 Ruby 怎麼應對呢？吃瓜！ ⏰ #17837 Add support for Regexp timeouts - 發布功能 17 全域設定 針對特定 Regex 設定
18. 🍿 那 Ruby 怎麼應對呢？吃瓜！ ⏰ #17837 Add support for Regexp timeouts - 有趣的討論 [ 回溯次數派 Backtrack Limit ] 同一個 Ruby 版本(引擎實作) 的「回溯次數」是確定的，「時長」會受到許多因 素影響（eg. CPU 種類、CPU 當下負載） [ 超時派 Timeout ] 引擎的實作仍會有變，而使用者多是做 APP，對於自己服務「時長」的需求 會是更固定、直觀、好決定的。 → 核心：都希望讓使用者更容易訂出設定值、而且不用一直改 → 最後選 [超時派] 。 18
19. 🍿 那 Ruby 怎麼應對呢？吃瓜！ ⏰ #17837 Add support for Regexp timeouts - 社群的反應 Rails 8 預設 Regexp.timeout 為 1 秒 19 https://rubyonrails.org/2024/11/1/this-week-in-rails
20. 🍿 那 Ruby 怎麼應對呢？吃瓜！ ⚡ #19104 Introduce the cache-based optimization for Regexp matching - 提案 20 https://bugs.ruby-lang.org/issues/19104 🙋 設定適當的 Timeout 值很 不容易。 太短可能會讓系統功能壞掉 ，太長又難以有效預防 ReDoS。 來用 Memoization 改善 Regexp#match 的速度吧！
21. 🍿 那 Ruby 怎麼應對呢？吃瓜！ ⚡ #19104 Introduce the cache-based optimization for Regexp matching - 發布功能 /^😈*升?😈*$/.match?("😈😈😈已讀") 21
22. 🍿 那 Ruby 怎麼應對呢？吃瓜！ ⚡ #19104 Introduce the cache-based optimization for Regexp matching - 發布功能 Ruby 3.2.0 Released (25 Dec 2022) 22
23. 🍿 那 Ruby 怎麼應對呢？吃瓜！ ⚡ #19104 Introduce the cache-based optimization for Regexp matching - 有趣的討論 23 https://bugs.ruby-lang.org/issues/19104 Matz 第一個按了喜歡(? 他唯一擔心是記憶體用量。 也不容易繼續瞎猜更多假設 性 case，決定發布 3.1-preview 來得到更多實 測。 回想起 Symbol 沒 GC 時代的 DoS 陰影...
24. 🍿 那 Ruby 怎麼應對呢？吃瓜！ ⚡ #19104 Introduce the cache-based optimization for Regexp matching - 有趣的討論 • 是以 位元陣列(bit-array) 記憶，1 bit 存 1 狀態，8 個狀態才占用 1 byte。 • 即使 字串很長，分支指令數量 通常不多 (上限約 80)，相乘可接受。 • 回溯（Backtracks）次數超過特定閾值時，才會啟動此機制去花記憶體。 24
25. 🍿 那 Ruby 怎麼應對呢？吃瓜！ ⚡ #19104 Introduce the cache-based optimization for Regexp matching - 有趣的討論 → 教育與提醒義務 vs. 使用者體驗與相容性 25 https://bugs.ruby-lang.org/issues/19104 Mame 和 Eregon 針對「如何 讓用戶得知某 regex 可不可 最佳化」 • Warning？ Error？是否搭配 opt-in flag？ • 確認用的 API？
26. 🍿 那 Ruby 怎麼應對呢？吃瓜！ ⚡ #19104 Introduce the cache-based optimization for Regexp matching - 有趣的討論 26 https://bugs.ruby-lang.org/issues/19194 最後決定是，提供 user 確認用的 API （後面我會介紹） Mame 也正式提名 make_now_just 為 committer 👏
27. 🍿 那 Ruby 怎麼應對呢？吃瓜！ 󰝊 Ruby 3.2 之後... 27
28. 🍿 那 Ruby 怎麼應對呢？吃瓜！ 󰝊 Ruby 3.2 之後... 持續推進支援語法！ 28
29. 󰟲 我也想小心，但人腦轉不過來啦，有沒有好用工具？ 29
30. 󰟲 我也想小心，但人腦轉不過來啦，有沒有好用工具？ Regexp#linear_time? 30
31. 󰟲 我也想小心，但人腦轉不過來啦，有沒有好用工具？ Regexp#linear_time? 31
32. 󰟲 我也想小心，但人腦轉不過來啦，有沒有好用工具？ Regexp#linear_time? …想到 Linter 就 想到 RuboCop！ 32 …扎實的許願 ?!
33. 󰟲 我也想小心，但人腦轉不過來啦，有沒有好用工具？ Regexp#linear_time? … 想到 Linter 就想到 RuboCop? 33 哈哈，我在 RubyKaigi 後也馬上做了PoC！這 是我的 KaigiEffect！ 我想，被標示出來後， fix 不太容易實做，可 能也不是每個用戶都有能力馬上去改進這 些 Regex 🤔 另外，你點出 引擎依賴特定 Ruby 版本 確實 是個問題。例如用 Ruby 3.3 跑 TargetRubyVersion: 3.2 的靜態分 析時 CI 和 Prod 預期的結果可能不一致。 或是，可能實作在 rubocop core 以外的第三 方 gem？
34. 󰟲 我也想小心，但人腦轉不過來啦，有沒有好用工具？ makenowjust-labs.github.io/recheck/docs/usage/as-eslint-plugin/ 34
35. 🤔 為什麼想在 2026 重提 ReDoS 議題 35
36. 🤔 為什麼想在 2026 重提 ReDoS 議題 「每次提起升版就被已讀。」 36 https://www.ruby-lang.org/en/downloads/branches/
37. 🤔 為什麼想在 2026 重提 ReDoS 議題 「輸入 的 不確定性」 37 Huli (2025). 從冷知識到漏洞，你不懂的Web，駭客懂. WebConf Taiwan 2025.
38. 🤔 為什麼想在 2026 重提 ReDoS 議題 「 LLM 輸入的不確定性」 [ 類型一：生成字串內容 ] 即使努力的約束，LLM 產生的內容與長度，還是會 有隨機性。 無論是由使用者還是系統內部生成，生成有一定 長度、多變的內容，變得更容易了。 [ 類型二：生成好像正確的 Regex ] 開發時生成：LLM 寫出的 Regex 雖然能對應需求， 但通常不會預設幫考慮效能最佳化。 作為功能的輸入：例如開發工具或 DevOps 平台， 需要更加小心...無心的使用者 、有心的攻擊方。 38
39. 🤔 為什麼想在 2026 重提 ReDoS 議題 「供應鏈安全」 現今我們越來越依賴外部套件。 即便努力把自己的 codebase 寫得很 安全，依賴套件還是可能有漏洞。 到了 2026 年，同樣類型的漏洞，仍持 續以各種樣貌出現。 意識到，需要多補充這類知識、留意 關鍵字。 期待在社群一起討論！ 39
40. 🎯 不是...而是... 󰢄 學到怎麼改善效能低落的 Regex 本人 󰢄 學到快速心算 (?) 判別 Regex 風險的方法 󰢄 學到 NFA 和 DFA 的引擎原理差異 󰢄 看好多歷史災難 CVE 案例 󰢏 知道 Ruby 近年針對 ReDoS 議題發布了什麼版本更新 󰢏 知道社群在做相關語言/套件設計時，貢獻維護者們的想法（吃瓜） 󰢏 知道可以用什麼小工具檢查 󰢏 知道為什麼 2026 我想再度注意這題 40
41. 🤔 為什麼想在 2026 重提 ReDoS 議題 最後，用 RubyKaigi 2023 講者的勵志結尾與 大家共勉 💪 今天聊了好多人的參與和考量： • Ruby 核心團隊 • 週邊套件貢獻者的反應 (Rails, Rubocop) • 研討會講者的關注 雖然還是怕得要死 🥬 🐣 我覺得整個社群正陪我一起努力！ 41 https://youtu.be/CEvSx1D3dFQ
42. 42 📢 Organizer 中場小公告
43. 💦 當你看到 Kasa 出來演講，就知道... 43 https://x.com/mishmashtan/status/1857659145899618423
44. 💪 今年可能在 Ruby Taiwan 社群登台的機會 RubyJam 8 ~ 12 RubyJam 5 & 7 COSCUP 2026 8/8~8/9 RubyJam 4/14 預計 3 月底~5月初 CFP ! 熱烈徵稿 ! 還有位子！ 手刀投稿！ 44
45. 💪 今年可能在 Ruby Taiwan 社群登台的機會 RubyJam 8 ~ 12 RubyJam 5 & 7 COSCUP 2026 8/8~8/9 RubyJam 4/14 45 linktr.ee/rubytaiwan2008
46. 🫶 Special Thanks! 46
47. > slides.last == 'Thank You!' => true > # Stay connected on all platforms! linktr.ee/rubytaiwan2008 Speaker.find_by(name: 'Kasa') Date.new(2026, 3, 17) 47