อย่าใช้ WAF (ไฟร์วอลล์เว็บแอปพลิเคชัน)

• บทความนี้เขียนขึ้นเพราะมีคนไม่มากนักที่คัดค้านการใช้ WAF และผลการค้นหาเกี่ยวกับ WAF ส่วนใหญ่ก็มักถูกเขียนโดยผู้ให้บริการ WAF
• WAF ถูกสร้างขึ้นในยุคแรกของอินเทอร์เน็ต โดยดักทุกคำขอ HTTP และประเมินนิพจน์ทั่วไปหลายร้อยรายการเพื่อบล็อกคำขอที่คล้ายกับ SQL, เชลล์โค้ด ฯลฯ
• ในช่วงแรกของไซเบอร์ซีเคียวริตี้ WAF ดูเหมือนจะเป็นแนวคิดที่ดี แต่ทุกวันนี้ไม่ใช่อีกต่อไป
• จากปัญหาด้านประสิทธิภาพ ความสามารถในการหลบเลี่ยง ความเสี่ยงในฐานะเวกเตอร์การโจมตี และอัตราการตรวจจับผิดพลาดที่สูง ปัจจุบันจึงมีเทคโนโลยีความปลอดภัยที่ดีกว่าอยู่แล้ว

ประสิทธิภาพของ WAF แย่มาก

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

WAF ถูกหลบเลี่ยงได้ง่าย

• ในการแข่งขันที่ไม่สิ้นสุดระหว่าง WAF กับผู้โจมตี ผู้โจมตีเป็นฝ่ายได้เปรียบ
• สามารถใช้ไวยากรณ์ที่ซับซ้อนและเทคนิคการเข้ารหัสเพื่อหลบเลี่ยงกฎของ WAF ได้
• ตัวอย่างเช่น การโจมตี Log4shell ไม่สามารถบล็อกได้ด้วยการตรวจสอบสตริงอย่างง่าย และผู้โจมตีสามารถใช้เทคนิคหลบเลี่ยงได้หลากหลาย (Log4J Lookup)
• นอกจากนี้ หากเติมอักขระที่ไม่จำเป็นแต่ไม่เป็นอันตรายยาวประมาณ 8KB ลงในสตริงโจมตี WAF ก็จะไม่สามารถบัฟเฟอร์ไว้ใน RAM ต่อไปได้และถูกตัดทิ้ง จึงไร้ประโยชน์

WAF คือเวกเตอร์การโจมตี

• ในปี 2019 CapitalOne เกิดเหตุข้อมูลคำขอสินเชื่อ 100 ล้านรายการรั่วไหลเนื่องจากการตั้งค่า WAF ผิดพลาด
  • มีรายงานว่าผู้โจมตีหลอก WAF ให้ส่งคำขอไปยังบริการเมทาดาทา EC2 และส่งต่อข้อมูลรับรองที่ใช้เปิดอ่านไฟล์สำคัญจาก S3
• กล่าวคือ มีความเป็นไปได้ที่จะเกิดเหตุด้านความปลอดภัยจากการตั้งค่า WAF ผิดพลาด
• WAF ส่วนใหญ่มักซับซ้อนและมักเขียนแบบปิดซอร์ส ทำให้มีพื้นผิวการโจมตีกว้างขึ้น
  • เพราะเป็นผลิตภัณฑ์ "สำหรับองค์กร" ที่มีราคาแพง บริษัทต่าง ๆ จึงยัดฟีเจอร์ที่ไม่จำเป็นเข้าไปเพื่อให้เด่นกว่าคู่แข่ง
• หลักการความปลอดภัยพื้นฐานสำหรับผลิตภัณฑ์ความปลอดภัยเองก็มักถูกมองข้าม

อัตรา false positive ของ WAF สูง

• ตลอด 20 ปีที่ผ่านมา ชุดกฎ WAF แบบโอเพนซอร์สได้ขยายตัวอย่างมากเพื่อให้ตรวจจับการโจมตีรูปแบบใหม่ได้ และ WAF แบบ proprietary ก็น่าจะทำเช่นเดียวกัน
• นั่นหมายความว่ามีสตริงที่สามารถทำให้ WAF บล็อกคำขอได้มากขึ้นเรื่อย ๆ
• ทุกครั้งที่มีกฎใหม่ออกมา การขยายกฎของ WAF ก็ยิ่งเพิ่มอัตรา false positive
• WAF "ยุคถัดไป" อ้างว่าแก้ปัญหานี้ได้ด้วยการตรวจหลายคำขอร่วมกัน หรือใช้ระบบจัดอันดับความน่าเชื่อถือของ IP
  • แม้อาจช่วยปรับปรุงอัตรา false positive ได้บ้าง แต่ไม่สามารถแก้ปัญหาการตรวจจับผิดพลาดได้อย่างสมบูรณ์
• false positive อาจทำให้ผู้ใช้และทีมซัพพอร์ตไม่มีขั้นตอนแก้ไขที่ชัดเจน

ทางเลือกแทน WAF

• การแยกส่วน (Isolation): เทคนิคที่ทำให้แม้ระบบส่วนหนึ่งถูกเจาะ ก็ไม่กระทบต่อส่วนอื่น
  • เบราว์เซอร์ทำเช่นนี้โดยรันโค้ดทั้งหมดในโปรเซส sandbox พิเศษที่ไม่มีสิทธิ์เข้าถึงคุกกี้ รหัสผ่านที่บันทึกไว้ หรือแท็บอื่น ๆ ตามอำเภอใจ
  • ไมโครเซอร์วิสถูกออกแบบมาโดยคำนึงถึงการแยกส่วน แต่ก็สามารถทำแบบโมโนลิทได้เช่นกันโดยใช้ไลบรารีและภาษาที่หลากหลาย
• ความไม่เปลี่ยนแปลง (Immutability): กำจัดหมวดหมู่ของการโจมตีด้วยระบบไฟล์แบบอ่านอย่างเดียว ตัวจัดการแพ็กเกจที่ต้องรีบูต และแบ็กอัปแบบเพิ่มได้อย่างเดียว
• การวิเคราะห์แบบสแตติก (Static Analysis): ใช้ prepared statements เพื่อป้องกัน SQL injection และตรวจโค้ดผ่านการวิเคราะห์แบบสแตติกใน CI pipeline
• ความปลอดภัยแบบอิงความสามารถ (Capability-based Security): ไม่ใช่ทุก API endpoint ที่จำเป็นต้องมีสิทธิ์เข้าถึงฐานข้อมูลและระบบไฟล์แบบไม่จำกัด ควรให้เฉพาะสิทธิ์ที่จำเป็นเท่านั้น

[roxie]

:+1:

[devpain]

ถ้าเป็นการใช้ nginx + naxsi ร่วมกัน ก็น่าจะไม่เข้าข่ายบางข้อข้างต้นนะครับ
ควรนำชุดกฎของ WAF ไปใช้ในลักษณะที่ผู้พัฒนาบริการเป็นผู้ดูแล
หากผู้เชี่ยวชาญด้านความปลอดภัยตั้งค่าทั่วไปโดยไม่มีความเข้าใจต่อบริการ ก็จะทำให้เกิดอัตรา false positive สูง และเมื่อค่อย ๆ ลบชุดกฎออกทีละข้อไปตามคำขอ ก็จะทำให้ WAF สูญเสียหน้าที่ดั้งเดิมไป

[nosookja]

ผมเห็นด้วยบางส่วนในประเด็นเรื่องการ bypass หรือ false positive แต่โดยรวมให้ความรู้สึกอย่างมากว่าเอาข้อมูลที่ไม่แน่ชัดมาวางเรียงราวกับเป็นข้อเท็จจริง ถ้ามีเวลาคงต้องไปอ่านต้นฉบับด้วย โดยเฉพาะการยกกรณีของ CapitalOne มาเป็นปัญหาของ WAF นี่ดูเหมือนว่าผู้เขียนต้นฉบับจะมีความเข้าใจเกี่ยวกับ WAF ค่อนข้างน้อย WAF ไม่ใช่โซลูชันที่ช่วย Mitigation ช่องโหว่ได้ถึงต้นตอ ช่องโหว่ที่เกิดจากโค้ดก็ควรแก้ที่โค้ดจึงจะเป็นการแก้ที่ถูกต้อง แต่ในโลกความเป็นจริงมันไม่ได้เป็นแบบนั้น จึงจำเป็นต้องมีบางอย่างที่เหมาะสมสำหรับตรวจสอบอินพุตที่น่าสงสัยหรือมีเจตนาร้ายตั้งแต่ด้านหน้า หากใช้งานและดูแลมันได้ดีก็จะเป็นมีดที่ดีมาก แต่ถ้าดูแลได้ไม่ดีก็จะกลายเป็นมีดที่ทำร้ายตัวเราเองได้ ความเป็นดาบสองคมของเครื่องมือนั้นมีอยู่เสมอ แต่หัวข้อนี้ดูเหมือนจะเน้นแต่ด้านแย่เกินไปครับ

[xguru]

ในความคิดเห็นบน Hacker News มีทั้งความเห็นที่หลากหลายและข้อโต้แย้งเกี่ยวกับเรื่องนี้ ลองอ่านประกอบกันได้ https://news.ycombinator.com/item?id=38255004