Regex ReDoS Checker: ตรวจหา Catastrophic Backtracking ก่อนขึ้น Production
เรียนรู้วิธีใช้ Regex ReDoS Checker เพื่อตรวจหา nested quantifier, unsafe alternation และความเสี่ยงจาก catastrophic backtracking พร้อม safety score แบบทันที โดยประมวลผลทั้งหมดใน browser ของคุณ
Table of Contents
Regular expression หรือ regex ช่วยให้เรา validate และค้นหาข้อมูลได้อย่างกระชับมาก แต่ความยืดหยุ่นของ regex engine บางประเภทก็มาพร้อมความเสี่ยง หาก pattern ทำให้ engine ต้องลองเส้นทางการ match จำนวนมากเกินไป request เดียวอาจใช้ CPU และเวลานานผิดปกติ จนกลายเป็นช่องโหว่ที่เรียกว่า Regular Expression Denial of Service หรือ ReDoS
Regex ReDoS Checker ช่วยทำ security review เบื้องต้นให้ regex ของคุณได้อย่างรวดเร็ว เพียงวาง pattern แล้วดู issue ที่ตรวจพบ, safety score และระดับ safe, caution หรือ danger ได้ทันที การวิเคราะห์ทำงาน 100% ใน browser จึงไม่ต้อง upload pattern หรือ test string ไปยัง server
เครื่องมือนี้เหมาะสำหรับใช้ตอนเขียน validation, review pull request, ตรวจสอบ search filter และแก้ไข pattern ก่อน deploy อย่างไรก็ตาม ผลลัพธ์เป็น static heuristic สำหรับ first-pass review ไม่ใช่ formal proof ว่า regex จะปลอดภัยในทุก engine และทุก input ควรใช้ร่วมกับ input limit, timeout และ performance test เสมอ
Why Use Regex ReDoS Checker?
- ค้นหา pattern ที่เสี่ยงต่อ ReDoS: ตรวจจับโครงสร้างอย่าง (a+)+, (a*)+ และ quantified group ที่อาจทำให้เกิด backtracking จำนวนมาก
- ช่วย review ก่อนขึ้น production: ตรวจสอบ regex ในช่วง development หรือ code review ได้ทันที ไม่ต้องรอให้เกิด CPU spike จาก input ที่ malicious
- อธิบายสาเหตุของความเสี่ยง: แต่ละ issue มีคำอธิบายว่าโครงสร้างนั้นอาจทำให้ engine ทำงานซ้ำอย่างไร ทำให้แก้ไขได้ตรงจุด
- เช็ก syntax ไปพร้อมกัน: เครื่องมือจะลอง compile regex และแจ้ง invalid JavaScript regular-expression syntax ก่อนนำไป test
- ทดลอง match กับ sample string: ใส่ input ตัวอย่างเพื่อดูว่า regex match ตามที่ตั้งใจหรือไม่ พร้อมทบทวน risk ของ pattern ไปพร้อมกัน
- รักษาความเป็นส่วนตัว: การวิเคราะห์เกิดขึ้นในเครื่องของคุณ pattern และ test string จึงไม่ถูกส่งไปเรียก API ภายนอก
Key Features
| Feature | ตรวจสอบอะไร | ประโยชน์ |
|---|---|---|
| Syntax validation | ทดลอง compile regex ที่ป้อนเข้ามา | พบ pattern ที่จะ throw error ตอน runtime |
| Risk pattern scan | nested quantifier, quantified group, overlapping class และ alternation | ชี้จุดที่อาจเกิด backtracking รุนแรง |
| Lookbehind review | ตรวจหา lookbehind และ quantified lookbehind | ช่วยเช็ก browser compatibility และ risk เพิ่มเติม |
| Safety score | สรุปคะแนนพร้อม severity เป็น safe, caution หรือ danger | ทำให้ scan ผล review ได้เร็ว |
| Sample matcher | ทดลอง regex กับ string ใน browser | ตรวจสอบ matching behavior ได้ทันที |
| Client-side processing | ประมวลผลใน browser โดยไม่ upload ข้อมูล | ลดความเสี่ยงต่อการเปิดเผย pattern และ test data |
รายละเอียดที่ควรใส่ใจมีดังนี้
- Pattern ที่มี .* หรือ .+ หลายตำแหน่งอาจแย่งกัน consume ตัวอักษรชุดเดียวกัน เมื่อ match ไม่สำเร็จ engine อาจต้องย้อนกลับไปลองการแบ่ง input หลายรูปแบบ
- Quantified character class ที่อยู่ติดกันและรับตัวอักษรกลุ่มเดียวกันได้ เช่น [a-z]+[a-z]+ ควรได้รับการ review เพราะอาจทำให้เกิด polynomial backtracking ตามบริบทของ expression และ input
- Lookbehind อาจ compile ได้ใน runtime หนึ่งแต่ไม่รองรับใน browser รุ่นเก่า การตรวจ syntax จึงควรทำควบคู่กับการตรวจ compatibility ของ environment จริง
How to Use
- เปิดเครื่องมือ: เข้าไปที่ Regex ReDoS Checker ด้วย browser รุ่นปัจจุบัน
- วาง regex pattern: ใส่ expression ที่ใช้จริงใน application อย่าสรุปว่าปลอดภัยเพียงเพราะ match กับตัวอย่างสั้น ๆ ได้สำเร็จ
- อ่าน validation result: ถ้า compile ไม่ผ่าน ให้แก้ syntax ก่อน ถ้า compile ผ่าน ให้ดู safety score และรายละเอียดของ issue ทุกข้อ
- ทดสอบ input หลายแบบ: ใส่ทั้ง string ที่ควร match และ string ที่ควรไม่ match โดยเฉพาะ input ยาวที่เกือบจะ match เพราะเป็นกรณีที่เปิดเผย backtracking ได้ดี
- แก้ไขแล้วตรวจซ้ำ: simplify expression, ลด overlap หรือเปลี่ยน matching strategy จากนั้นนำ pattern ใหม่กลับมาตรวจอีกครั้งก่อน deploy
แม้เครื่องมือจะประมวลผลแบบ client-side ก็ควรหลีกเลี่ยงการวาง secret, internal identifier หรือ business rule ที่เป็นความลับในเครื่องมือออนไลน์ทุกชนิด ใช้ข้อมูลตัวอย่างที่ไม่ sensitive เมื่อทำได้
Understanding ReDoS และ Catastrophic Backtracking
Regex engine แบบ backtracking จะลองทางเลือกหนึ่งก่อน หาก match ต่อไม่ได้ก็ย้อนกลับไปยังจุดที่เคยตัดสินใจ แล้วลองทางเลือกอื่น กลไกนี้ทำให้ regex รองรับความสามารถที่ expressive เช่น alternation และ quantifier แต่จำนวนเส้นทางที่ต้องลองอาจเพิ่มขึ้นอย่างรวดเร็วเมื่อ pattern มีความกำกวม
ลองดู pattern (a+)+$ ด้านในมี a+ ที่กินตัวอักษร a ได้หลายจำนวน และ group ด้านนอกก็ repeat ได้อีก เมื่อ input เป็น a ยาว ๆ แล้วลงท้ายด้วยตัวอักษรที่ไม่ใช่ a engine อาจต้องลองแบ่งกลุ่ม a ได้หลายแบบ ก่อนจะยอมรับว่า $ ไม่สามารถ match ได้ ยิ่ง input ยาว ค่าใช้จ่ายของการปฏิเสธก็ยิ่งสูง
ความเสี่ยงอีกแบบเกิดจาก alternation ที่ทับซ้อนกัน เช่น (a|a)* ซึ่งทั้งสอง branch รับตัวอักษรเดียวกันได้ หรือ (a|aa)+ ที่มีหลายวิธีในการแบ่ง input ให้เป็น branch ต่าง ๆ เมื่ออยู่ภายใต้ quantifier engine จะต้องพิจารณาความเป็นไปได้จำนวนมาก Pattern ไม่จำเป็นต้องเหมือนตัวอย่าง “evil regex” ที่มีชื่อเสียงทุกประการจึงจะต้องระวัง ประเด็นสำคัญคือมีหลายเส้นทางที่ consume input เดียวกันหรือไม่
Safety score ของ Regex ReDoS Checker เป็นสัญญาณสำหรับช่วย triage ไม่ใช่ใบรับรองความปลอดภัย ถ้าได้ danger หมายความว่า pattern เข้าข่ายโครงสร้างที่ควรตรวจสอบและแก้ไขทันที ถ้าได้ safe หมายถึงไม่พบ red flag ที่เครื่องมือนี้รองรับ แต่ไม่ได้พิสูจน์ว่า regex ปลอดภัยในทุก engine, flag, input size หรือบริบทของ application
สำหรับ service ที่รับ traffic จากภายนอก ควรทำ adversarial performance test เพิ่มด้วย หากไม่จำเป็นต้องใช้ backreference หรือ feature ที่ต้องอาศัย backtracking ให้พิจารณา RE2-style หรือ linear-time regex engine นอกจากนี้ควรกำหนดความยาว input สูงสุด, มี timeout ตามความเหมาะสม และแยกการประมวลผล user-supplied regex ออกจาก worker สำคัญของระบบ
Practical Use Cases
ตรวจสอบ validation ของ form และ API
Endpoint สำหรับ signup หรือ API มักมี regex ตรวจ username, identifier, email-like value หรือ URL ให้ทดสอบทั้งค่าปกติและ malformed input ที่ยาวมาก เพราะ pattern ที่ดูปลอดภัยกับ string 20 ตัวอักษรอาจใช้เวลานานเมื่อมีคนส่ง input ที่เกือบ match หลายพันตัวอักษรเข้ามา
Review pull request
เมื่อมีการเพิ่ม regex ที่ซับซ้อนใน pull request ให้ใช้ checker เป็น manual security step แล้วบันทึกผลไว้ใน review discussion วิธีนี้เป็น complement ที่ดีของ unit test และ SAST โดยเฉพาะ regex ที่ซ่อนอยู่ใน config หรือ validation helper
Search และ filtering ที่ให้ผู้ใช้ป้อน pattern
Search box, log filter หรือ admin dashboard บางระบบอนุญาตให้ user ใช้ regex เอง กรณีนี้ต้องมองเป็นคนละ threat model กับ fixed regex ที่ developer เขียนไว้ ควรจำกัด syntax, จำกัดขนาด input และเลือก engine ที่ไม่ใช้ backtracking หากเป็นไปได้
ย้าย regex ระหว่าง runtime
Regex ที่ย้ายจาก backend language ไป JavaScript หรือจาก service หนึ่งไปอีก service หนึ่งอาจมี syntax และ behavior ต่างกัน ใช้ checker เพื่อตรวจ lookbehind และทดลองกับ representative input แล้วต้อง verify ซ้ำใน runtime จริง เพราะ browser-side analysis ไม่สามารถจำลอง engine ทุกชนิดได้
Best Practices
- เขียน pattern ให้เรียบง่าย: sequence ของ character class ที่อ่านง่ายตรวจสอบได้ดีกว่า group ที่ซ้อนกันหลายชั้น
- ลดความกำกวม: หลีกเลี่ยง broad quantified token ที่วางติดกันและสามารถ consume ตัวอักษรชุดเดียวกัน
- ใช้ anchor อย่างเข้าใจ: ^ และ $ ช่วยลดพื้นที่ค้นหาในบางกรณี แต่ไม่ได้ทำให้ nested หรือ ambiguous regex ปลอดภัยโดยอัตโนมัติ
- จำกัดความยาว input: ตั้ง maximum length ก่อนรัน regex โดยเฉพาะ endpoint ที่เปิดให้ public เรียกใช้
- เลือก engine ที่ปลอดภัย: ใช้ linear-time หรือ RE2-compatible engine เมื่อ feature ที่ต้องใช้ไม่เกินขีดความสามารถของ engine นั้น
- ทดสอบ failure path: เพิ่ม test ด้วย string ยาวที่เกือบ match เพราะ ReDoS มักแสดงอาการตอน reject ไม่ใช่ตอน match สำเร็จ
ตรวจ Regex ก่อน Ship
การตรวจ regex ใช้เวลาไม่กี่วินาที แต่การไล่หาสาเหตุของ CPU สูงจาก input เดียวอาจใช้เวลาหลายชั่วโมง เริ่มจาก Regex ReDoS Checker อ่านสาเหตุของ issue แล้วแก้ pattern ให้เหมาะกับ runtime จริง จากนั้นใช้ input limit, timeout และ performance test เป็น defense-in-depth ก่อนนำขึ้น production
Related Tools You Might Like:
- Regex Tester — ตรวจ matching behavior กับ sample string ได้รวดเร็ว
- Regex Generator — สร้าง pattern จาก requirement ที่เป็นโครงสร้าง
- Regex Cheatsheet — เปิดดู syntax และ common construct ที่ใช้บ่อย
ขอให้ทุก regex ปลอดภัย และ review ได้อย่างมั่นใจ!