WAF คืออะไร — Web Application Firewall ป้องกันเว็บแอปอย่างไร
เมื่อองค์กรมีเว็บแอปพลิเคชันที่เปิดให้บริการบนอินเทอร์เน็ต การปกป้องจากการโจมตีเป็นสิ่งจำเป็น Web Application Firewall (WAF) คือหนึ่งในเครื่องมือสำคัญที่ช่วยกรองการโจมตีก่อนถึงเว็บแอป แต่ WAF ทำได้ทุกอย่างจริงหรือ? บทความนี้อธิบายอย่างตรงไปตรงมา
WAF คืออะไร
Web Application Firewall (WAF) คือโซลูชันด้านความปลอดภัยที่ออกแบบมาเพื่อ กรอง ตรวจสอบ และบล็อก HTTP/HTTPS Traffic ที่เป็นอันตราย ก่อนที่จะถึง Web Application โดย WAF ทำงานที่ Layer 7 (Application Layer) ของ OSI Model [1]
จากนิยามของ OWASP: “WAF เป็น Application-level Firewall ที่ไม่ได้ขึ้นอยู่กับแอปพลิเคชันเอง แต่ทำหน้าที่บังคับใช้นโยบายความปลอดภัยกับ HTTP/HTTPS Traffic” [1]
WAF vs Firewall vs IDS/IPS — เปรียบเทียบความแตกต่าง
หลายคนสับสนระหว่าง WAF กับ Firewall ทั่วไปและ IDS/IPS ตารางนี้ช่วยให้เข้าใจความแตกต่าง:
| คุณสมบัติ | Traditional Firewall | IDS/IPS | WAF |
|---|---|---|---|
| Layer ที่ทำงาน | Layer 3-4 (Network/Transport) | Layer 3-7 | Layer 7 (Application) |
| สิ่งที่ตรวจสอบ | IP, Port, Protocol | Packet Payload, Signatures | HTTP/HTTPS Request & Response |
| ป้องกันอะไร | Unauthorized Network Access | Known Attack Patterns | Web Application Attacks (SQLi, XSS, etc.) |
| เข้าใจ HTTP | ไม่ | บางส่วน | ใช่ — เข้าใจ Header, Cookie, Body, URL |
| เข้าใจ Session | ไม่ | ไม่ | ใช่ — ติดตาม Session, Cookie |
| SSL/TLS Inspection | ไม่ (ส่วนใหญ่) | ต้องตั้งค่าเพิ่ม | ใช่ — Terminate SSL แล้วตรวจสอบ |
| ตัวอย่าง | Palo Alto NGFW, Fortinet | Snort, Suricata | Cloudflare WAF, AWS WAF, ModSecurity |
สรุป: Firewall ปกป้อง Network, IDS/IPS ตรวจจับ Pattern การโจมตี แต่ WAF เท่านั้นที่เข้าใจ HTTP/HTTPS Protocol และสามารถป้องกันการโจมตีระดับ Application ได้อย่างมีประสิทธิภาพ
ประเภทของ WAF
1. Network-based WAF (ติดตั้งในเครือข่าย)
- ติดตั้งเป็น Hardware Appliance หน้า Web Server
- Latency ต่ำ เพราะอยู่ใกล้เซิร์ฟเวอร์
- ต้นทุนสูง ทั้ง Hardware และ Maintenance
- เหมาะกับ: องค์กรขนาดใหญ่ที่มี Data Center เอง
- ตัวอย่าง: F5 BIG-IP ASM, Imperva WAF Gateway
2. Host-based WAF (ติดตั้งบน Server)
- ทำงานเป็น Software Module บน Web Server
- ยืดหยุ่น ในการ Customize Rules
- กิน Resource ของ Server
- เหมาะกับ: ทีมที่ต้องการ Control สูงสุด
- ตัวอย่าง: ModSecurity (Open Source), NAXSI
3. Cloud-based WAF (บริการบนคลาวด์)
- ให้บริการแบบ SaaS — ไม่ต้องติดตั้ง Hardware
- ตั้งค่าง่าย เพียงเปลี่ยน DNS
- Auto-update Rules โดยผู้ให้บริการ
- Scale ได้ ตามปริมาณ Traffic
- เหมาะกับ: องค์กรทุกขนาด โดยเฉพาะที่ใช้ Cloud
- ตัวอย่าง: Cloudflare WAF, AWS WAF, Azure WAF, Akamai Kona
สิ่งที่ WAF ทำได้
✅ บล็อก SQL Injection (SQLi)
WAF สามารถตรวจจับ Pattern ของ SQL Injection ใน HTTP Parameter เช่น ' OR 1=1 --, UNION SELECT และ Variant ต่าง ๆ แล้วบล็อกก่อนถึง Application
✅ บล็อก Cross-Site Scripting (XSS)
ตรวจจับ JavaScript ที่ถูกแทรกเข้ามาใน Input เช่น <script>alert(1)</script> รวมถึง Obfuscated Variants
✅ ป้องกัน Bot และ Automated Attacks
ใช้ CAPTCHA, Rate Limiting, JavaScript Challenge เพื่อแยก Bot ออกจาก User จริง
✅ บล็อก DDoS Layer 7
ป้องกันการโจมตีแบบ HTTP Flood ที่ส่ง Request จำนวนมากเพื่อทำให้ Application ล่ม
✅ Virtual Patching
เมื่อค้นพบช่องโหว่ใหม่ (เช่น CVE ที่เพิ่งประกาศ) WAF สามารถสร้าง Rule เพื่อ บล็อกการโจมตีชั่วคราว ในขณะที่ทีมพัฒนาแก้ไขโค้ด
✅ ปฏิบัติตาม PCI DSS 4.0
PCI DSS 4.0 Requirement 6.4.2 บังคับให้ต้องมี WAF ตั้งแต่ 31 มีนาคม 2568 (ดูรายละเอียดด้านล่าง)
สิ่งที่ WAF ทำไม่ได้
❌ ป้องกัน Business Logic Flaw
WAF ไม่เข้าใจ “ตรรกะทางธุรกิจ” ของแอปพลิเคชัน เช่น:
- ผู้ใช้แก้ไขราคาสินค้าใน Cart จาก 1,000 เป็น 1 บาท
- ข้ามขั้นตอนการอนุมัติโดยเรียก API โดยตรง
- ใช้ Coupon Code ซ้ำไม่จำกัดครั้ง
❌ ป้องกัน Authorization Bypass
WAF ไม่รู้ว่า User A ควรเข้าถึงข้อมูลของ User B ได้หรือไม่ เช่น:
- IDOR (Insecure Direct Object Reference) — เปลี่ยน
/api/user/123เป็น/api/user/456 - Vertical Privilege Escalation — User ธรรมดาเข้าถึง Admin Function
❌ ป้องกัน Zero-day Attacks
WAF ทำงานตาม Signature/Rule ที่รู้จัก เมื่อเจอ Zero-day Attack ที่ไม่มี Signature รองรับ WAF อาจไม่สามารถตรวจจับได้
❌ ป้องกัน Insider Threats
WAF ตรวจสอบ Traffic ขาเข้า แต่ไม่สามารถป้องกันพนักงานภายในที่ใช้สิทธิ์ที่ถูกต้องในการเข้าถึงข้อมูลโดยมิชอบ
❌ แก้ไขช่องโหว่ในโค้ด
WAF เป็นเพียง หน้ากากป้องกัน ไม่ได้แก้ไขช่องโหว่จริงในโค้ด หากปิด WAF ช่องโหว่ยังอยู่
ทำไม WAF ไม่แทน Pentest — Defense in Depth
หลายองค์กรถามว่า “มี WAF แล้วยังต้องทำ Pentest อีกหรือ?” คำตอบคือ ต้อง ด้วยหลักการ Defense in Depth (การป้องกันหลายชั้น) [2]:
Internet → [WAF] → [Web Server] → [Application Code] → [Database]
↑ ↑ ↑
ชั้นที่ 1 ชั้นที่ 2 ชั้นที่ 3
(กรอง Traffic) (Secure Code) (Access Control)| สถานการณ์ | WAF | Pentest |
|---|---|---|
| SQL Injection ทั่วไป | ✅ บล็อกได้ | ✅ พบและแนะนำแก้โค้ด |
| SQL Injection ที่ Obfuscate | ⚠️ อาจ Bypass ได้ | ✅ ทดสอบ Bypass ด้วย |
| Business Logic Flaw | ❌ ไม่เข้าใจ | ✅ ทดสอบเจอ |
| IDOR | ❌ ไม่ตรวจจับ | ✅ ทดสอบเจอ |
| Zero-day | ❌ ไม่มี Signature | ⚠️ อาจพบจาก Manual Testing |
| WAF Bypass | — | ✅ ทดสอบว่า WAF ถูก Bypass ได้หรือไม่ |
ผลลัพธ์: WAF ป้องกันแบบ Real-time, Pentest ค้นหาสิ่งที่ WAF ป้องกันไม่ได้ ทั้งสองอย่างเสริมกัน ไม่ใช่ทดแทนกัน
PCI DSS 4.0 Requirement 6.4 — WAF บังคับตั้งแต่ 31 มี.ค. 2568
PCI DSS 4.0 ได้เปลี่ยนแปลงข้อกำหนดเรื่อง WAF อย่างมีนัยสำคัญ [3][4]:
ก่อนหน้า (PCI DSS 3.2.1)
ข้อกำหนด 6.6 ให้ เลือกอย่างใดอย่างหนึ่ง:
- Manual Code Review หรือ Automated Code Review หรือ
- Web Application Firewall
ปัจจุบัน (PCI DSS 4.0 — มีผลบังคับ 31 มีนาคม 2568)
Requirement 6.4.2 กำหนดให้ต้อง:
“Deploy an automated technical solution for public-facing web applications that continually detects and prevents web-based attacks.”
ซึ่งหมายความว่า WAF ไม่ใช่ตัวเลือกอีกต่อไป แต่เป็นข้อบังคับ สำหรับทุกองค์กรที่ประมวลผลข้อมูลบัตรเครดิต
สิ่งที่ WAF ต้องทำตาม Req 6.4.2
- ต้อง ตรวจจับและป้องกัน (ไม่ใช่แค่ตรวจจับ)
- ต้องทำงาน อย่างต่อเนื่อง (Continually)
- ต้องอยู่หน้า Public-facing Web Application ทุกตัว
- ต้อง อัปเดต เพื่อรับมือภัยคุกคามใหม่
Requirement 6.4.3 — Client-Side Protection
นอกจาก WAF แล้ว PCI DSS 4.0 ยังกำหนด Req 6.4.3 ที่ต้อง จัดการ Script ทั้งหมดที่โหลดบน Payment Page เพื่อป้องกัน Web Skimming (เช่น Magecart Attack)
วิธีเลือก WAF ที่เหมาะกับองค์กร
สำหรับ SME / Startup
- Cloud-based WAF เช่น Cloudflare (มี Free Plan), AWS WAF
- ตั้งค่าง่าย ใช้เวลาไม่กี่ชั่วโมง
- ต้นทุนต่ำ จ่ายตาม Traffic
สำหรับองค์กรขนาดกลาง-ใหญ่
- Cloud-based WAF ระดับ Enterprise เช่น Cloudflare Enterprise, Akamai
- หรือ Network-based WAF เช่น F5 BIG-IP สำหรับ On-premise
- มี WAF Managed Service เพื่อลดภาระทีม
สำหรับองค์กรที่ต้องการ Control สูงสุด
- Host-based WAF เช่น ModSecurity + OWASP Core Rule Set (CRS)
- Custom Rules ได้ตามต้องการ
- ต้องมีทีม Security ที่มีความเชี่ยวชาญ
Checklist หลังติดตั้ง WAF
| ✅ | รายการตรวจสอบ |
|---|---|
| ☐ | เปิด WAF ใน Detection Mode ก่อน เพื่อดู False Positive |
| ☐ | ทดสอบ อย่างน้อย 2 สัปดาห์ ก่อนเปลี่ยนเป็น Blocking Mode |
| ☐ | กำหนด Whitelist สำหรับ Internal IP, API Partner |
| ☐ | ตั้ง Rate Limiting สำหรับ Login Page, API Endpoint |
| ☐ | เปิด Logging และส่งเข้า SIEM |
| ☐ | ทำ WAF Bypass Testing ด้วย Pentest |
| ☐ | ทบทวน Rules ทุก 3 เดือน |
| ☐ | อัปเดต Rule Set เมื่อมี CVE ใหม่ |
บทสรุป
WAF เป็น ชั้นป้องกันที่สำคัญ สำหรับ Web Application โดยเฉพาะเมื่อ PCI DSS 4.0 Requirement 6.4.2 บังคับให้ต้องมีตั้งแต่ 31 มีนาคม 2568 แต่ WAF ไม่ใช่ “กระสุนเงิน” ที่แก้ปัญหาทุกอย่าง — Business Logic Flaw, Authorization Bypass, และ Zero-day ยังคงต้องอาศัย Penetration Testing เพื่อค้นหาและแก้ไข
ITSL ให้บริการ Web Application Penetration Testing ที่รวมถึง WAF Bypass Testing เพื่อทดสอบว่า WAF ขององค์กรสามารถถูก Bypass ได้หรือไม่ พร้อมบริการ ที่ปรึกษา ISO 27001 ที่ครอบคลุมการเลือกและตั้งค่า WAF ให้เหมาะสม อ่านเพิ่มเติมเกี่ยวกับช่องโหว่เว็บแอปที่ WAF ช่วยป้องกันได้ที่ OWASP Top 10 2025 อธิบาย
แหล่งอ้างอิง
- OWASP, “Web Application Firewall,” OWASP, 2024. https://owasp.org/www-community/Web_Application_Firewall
- NIST, “Defense in Depth,” NIST SP 800-53 Rev. 5, 2020. https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
- PCI Security Standards Council, “PCI DSS v4.0 — Requirement 6.4.2,” PCI SSC, 2022. https://www.pcisecuritystandards.org/document_library/
- Fortra, “PCI DSS 4.0 and Web Application Firewalls: What You Need to Know,” Fortra, 2024.
- Fastly, “Addressing PCI DSS 4.0 and Requirement 6.4.2,” Fastly, 2024. https://www.fastly.com/resources/datasheets/security/addressing-pci-dss-4-0-and-requirement-6-4-2
- SecurityMetrics, “Web Application Firewall Fundamentals: PCI v4.0 Requirement 6.4.2,” SecurityMetrics, 2024. https://www.securitymetrics.com/blog/web-application-firewall-fundamentals