เจาะกำแพงป้องกัน: เทคนิคการหลบหลีก WAF เพื่อทดสอบความปลอดภัย

ในโลกไซเบอร์ที่เต็มไปด้วยภัยคุกคาม การปกป้องเว็บแอปพลิเคชันจึงเป็นเรื่องสำคัญอย่างยิ่ง Web Application Firewall (WAF) ถือเป็นด่านหน้าในการคัดกรองทราฟฟิกขาเข้า ป้องกันการโจมตีหลายรูปแบบ ก่อนที่ภัยคุกคามเหล่านั้นจะเข้าถึงเซิร์ฟเวอร์โดยตรง

แต่สำหรับนักทดสอบความปลอดภัย หรือผู้ที่ต้องการเข้าใจกลไกการทำงานของระบบเหล่านี้ การมองหาช่องโหว่เพื่อ Bypass WAF จึงเป็นความท้าทายที่น่าสนใจ และมักจะเผยให้เห็นจุดอ่อนที่ซ่อนอยู่ในการป้องกัน

WAF ทำงานอย่างไร และทำไมถึงเป็นอุปสรรค?

โดยพื้นฐานแล้ว WAF ทำหน้าที่คล้ายยามเฝ้าประตู มันจะคอยตรวจสอบข้อมูลที่ส่งเข้ามายังเว็บแอปพลิเคชัน เพื่อค้นหา แพทเทิร์นที่อันตราย หรือ คีย์เวิร์ดที่เข้าข่ายการโจมตี ที่ถูกกำหนดไว้ในกฎ (Ruleset)

ยกตัวอย่างเช่น หากมีคนพยายามส่งคำสั่ง SQL Injection ที่มีคีย์เวิร์ดอย่าง UNION SELECT หรือ ORDER BY เข้ามา ระบบ WAF ที่มีการตั้งค่าที่ดีก็จะตรวจจับได้และบล็อกคำสั่งนั้นทันที ทำให้นักโจมตีไม่สามารถส่ง payload ที่เป็นอันตรายไปถึงฐานข้อมูลได้

นี่คือจุดที่ความท้าทายเริ่มต้นขึ้น การจะพิสูจน์ว่า WAF มีช่องโหว่หรือไม่ จำเป็นต้องมีกลยุทธ์ในการส่ง payload ให้รอดพ้นการตรวจจับ

เปิดโปงกลเม็ด: ใช้คอมเมนต์ SQL หลอก WAF

เทคนิคหนึ่งที่นักทดสอบนิยมใช้และมักจะได้ผลคือ การใช้ คอมเมนต์ SQL เพื่อแบ่งคำสั่งอันตรายให้แยกออกจากกัน ตัวอย่างเช่น หากต้องการส่งคำสั่ง UNION SELECT ที่เป็นหัวใจของการโจมตี SQL Injection แต่ WAF ตรวจจับคำนี้ได้

แทนที่จะส่ง UNION SELECT แบบตรง ๆ ก็ลองเปลี่ยนมาใช้รูปแบบนี้:
UNI/**/ON/**/SEL/**/ECT

จะเห็นว่าคำสั่งถูกแบ่งออกเป็นส่วน ๆ ด้วย /**/ ซึ่งเป็น คอมเมนต์ในภาษา SQL สำหรับฐานข้อมูล MySQL และระบบฐานข้อมูลอื่น ๆ ก็มีรูปแบบคอมเมนต์ที่คล้ายกัน

หลักการคือ WAF ส่วนใหญ่จะถูกตั้งค่าให้ตรวจจับแพทเทิร์นของคำสั่งที่เป็นอันตรายที่ต่อเนื่องกัน แต่เมื่อเจอ /**/ แทรกเข้ามา ก็อาจทำให้ WAF ตีความว่านี่ไม่ใช่แพทเทิร์นที่อันตรายอีกต่อไป

ในขณะเดียวกัน เมื่อคำสั่งนี้ไปถึงฐานข้อมูล ฐานข้อมูลจะมองข้ามส่วนที่เป็น คอมเมนต์ ไป และนำส่วนที่เหลือมาประกอบกันเป็นคำสั่ง UNION SELECT ที่สมบูรณ์แบบ ทำให้คำสั่งทำงานได้ตามปกติอย่างไม่น่าเชื่อ

เบื้องหลังความสำเร็จ: ทำไมเทคนิคนี้ถึงได้ผล?

ความสำเร็จของเทคนิคนี้อยู่ที่การใช้ประโยชน์จากความแตกต่างในการตีความระหว่าง WAF กับ Database Server

WAF มักจะใช้การตรวจจับแบบ Signature-based หรือ Pattern Matching หมายความว่ามันจะมองหาชุดตัวอักษรหรือรูปแบบที่ตรงกับที่ถูกกำหนดว่าเป็นภัยคุกคาม เมื่อมี คอมเมนต์ SQL แทรกเข้ามา แพทเทิร์นที่ WAF คุ้นเคยก็ถูกทำลาย ทำให้ WAF “มองไม่เห็น” คำสั่งอันตรายนั้น

ในทางกลับกัน Database Server เช่น MySQL จะถูกออกแบบมาให้ประมวลผลคำสั่ง SQL ได้อย่างถูกต้อง และรู้จักที่จะละเลย คอมเมนต์ ที่อยู่ภายในคำสั่ง ทำให้แม้คำสั่งจะถูกแบ่งย่อย แต่ก็ยังคงความหมายและทำงานได้อย่างไม่มีปัญหา

นี่คือช่องโหว่ที่เกิดขึ้นเมื่อระบบป้องกันไม่สามารถ “เข้าใจ” ความหมายของ payload ได้ลึกซึ้งเท่ากับระบบที่ถูกโจมตี

บทเรียนสำคัญสำหรับผู้พัฒนาและผู้ดูแลระบบ

การหลบเลี่ยง WAF ด้วยเทคนิคนี้ ชี้ให้เห็นว่าการพึ่งพาเพียง WAF อย่างเดียวอาจไม่เพียงพอในการป้องกันภัยคุกคามที่ซับซ้อน

สิ่งที่ควรพิจารณาและนำไปปรับใช้คือ:

อย่าเชื่อใจเพียง WAF: WAF เป็นส่วนสำคัญของการป้องกัน แต่ไม่ใช่โซลูชันที่สมบูรณ์แบบ ควรเสริมด้วยการป้องกันในระดับแอปพลิเคชัน
ใช้ Prepared Statements หรือ Parameterized Queries: นี่คือวิธีการป้องกัน SQL Injection ที่มีประสิทธิภาพสูงสุด มันแยกคำสั่ง SQL ออกจากข้อมูลที่ผู้ใช้ป้อน ทำให้ไม่ว่าผู้ใช้จะป้อนอะไรเข้ามา ข้อมูลนั้นก็จะไม่ถูกตีความว่าเป็นส่วนหนึ่งของคำสั่ง SQL
ใช้ Positive Security Model: แทนที่จะพยายามบล็อกทุกสิ่งที่ดูเหมือนอันตราย ให้กำหนดอย่างชัดเจนว่าข้อมูลประเภทใดเท่านั้นที่ได้รับอนุญาตให้ผ่านได้ วิธีนี้มักจะแข็งแกร่งกว่าการพยายามบล็อกสิ่งที่ผิด
อัปเดตกฎ WAF อย่างสม่ำเสมอ: เทคนิคการโจมตีใหม่ ๆ เกิดขึ้นตลอดเวลา การอัปเดตและปรับแต่งกฎของ WAF ให้ทันสมัยอยู่เสมอเป็นสิ่งจำเป็น รวมถึงการทดสอบ WAF ของตัวเองด้วยเทคนิคการ Bypass ต่าง ๆ

การเข้าใจว่าผู้โจมตีหรือนักทดสอบพยายามหลีกเลี่ยงการป้องกันอย่างไร จะช่วยให้เราสร้างระบบที่แข็งแกร่งและปลอดภัยยิ่งขึ้นได้เสมอ