ทดสอบเจาะระบบเว็บแอปพลิเคชัน

เว็บแอปพลิเคชันคือส่วนของธุรกิจที่ผู้โจมตีเข้าถึงได้โดยไม่ต้องแตะ network ของคุณเลย หน้า login, API, session token, ช่องอัปโหลดไฟล์ ไปจนถึงหน้า admin ที่ลืมไปแล้วว่ายังเปิดอยู่ ทั้งหมดนี้เปิดให้ใครก็ตามที่มี browser เข้ามาลองได้ตลอดเวลา scanner ช่วยกวาดพื้นผิวได้ระดับหนึ่ง แต่มันไม่สามารถเชื่อมโยงช่องโหว่ access control หลายจุดเข้าด้วยกันจนนำไปสู่การยึดบัญชีได้ และไม่มีทางรู้ว่า workflow ของธุรกิจคุณควรอนุญาตอะไร ระบบที่ปล่อยให้ลูกค้าคนหนึ่งอนุมัติรายการของลูกค้าอีกคน scanner ก็ให้ผ่านหน้าตาเฉย เราจึงทดสอบเว็บแอปพลิเคชันด้วยมือ ทั้งช่องโหว่เชิงเทคนิคที่ scanner ทำได้แค่ชี้เบาะแส และการใช้ business logic ในทางที่ผิดที่ scanner มองไม่เห็นเลย ทีมของเราเคยเขียนถึงข้อจำกัดของ web application VA scanner ไว้ด้วย อ่านประกอบกันได้

สิ่งที่เราทดสอบ

finding ทุกข้อเทียบเข้ากับ OWASP Top 10 (2025) สิ่งที่เรารายงานจึงพูดภาษาเดียวกับ framework ที่นักพัฒนาและ auditor ของคุณรู้จักอยู่แล้ว ไม่ต้องแปลรายงานอีกชั้นก่อนเอาเข้าแผนแก้ไข หมวดความเสี่ยงสิบอันดับล่าสุดมีดังนี้

• A01:2025 Broken Access Control — ผู้ใช้ทำสิ่งที่เกินสิทธิ์ตัวเอง (รอบนี้รวม SSRF เข้ามาด้วย)
• A02:2025 Security Misconfiguration — ค่า default ที่ไม่ปลอดภัย การตั้งค่าที่เปิดเผยออกไป และการ hardening ที่ขาดหาย
• A03:2025 Software Supply Chain Failures — ความเสี่ยงใน dependency, build system และช่องทางแจกจ่ายซอฟต์แวร์
• A04:2025 Cryptographic Failures — cryptography ที่อ่อนหรือไม่มีเลย จนข้อมูลสำคัญหลุดออกไป
• A05:2025 Injection — input ที่ไม่น่าเชื่อถือถูกแอปพลิเคชันเอาไปสั่งทำงาน (ทั้ง SQL injection, XSS และอื่น ๆ)
• A06:2025 Insecure Design — การควบคุมความปลอดภัยที่ขาดหายหรือไร้ผลตั้งแต่ในดีไซน์
• A07:2025 Authentication Failures — การจัดการตัวตน credential หรือ session ที่อ่อน
• A08:2025 Software or Data Integrity Failures — อัปเดตหรือข้อมูลที่ไม่ได้ตรวจสอบ และ insecure deserialization
• A09:2025 Security Logging & Alerting Failures — ช่องว่างที่ทำให้คุณตรวจจับหรือรับมือการโจมตีไม่ทัน
• A10:2025 Mishandling of Exceptional Conditions — จัดการ error ไม่ดี และระบบ fail open (เพิ่มเข้ามาใหม่ในปี 2025)

ในทางปฏิบัติ การทดสอบของเราลงลึกกว่าสิบหัวข้อของ framework ครอบคลุมมากกว่านั้น ไม่จำกัดเพียงหมวดที่ไล่ตั้งแต่หน้า login ลงไปถึง server ที่แอปพลิเคชันรันอยู่นี้

• Authentication — การจัดการ credential ความทนต่อ brute-force นโยบายรหัสผ่าน และขั้นตอนกู้คืนบัญชี
• Session & cookie management — การสร้าง token อายุของ session ช่องโหว่ session fixation และการตั้งค่า cookie
• Access control & authorization — แต่ละ role เข้าถึงได้เฉพาะสิ่งที่ควรเข้าถึงจริงไหม
• Data validation — แอปพลิเคชันรับมือ input ที่ผิดรูปหรือจงใจป้อนมาโจมตีได้แค่ไหน
• Parameter tampering — แก้ราคา จำนวน identifier และ hidden field กลางทาง
• Injection หลายรูปแบบ — SQL, command, LDAP, template และ injection ตระกูลอื่นในทุกช่องรับข้อมูล
• Cross-site scripting (XSS) — ทั้งแบบ reflected, stored และ DOM-based
• Cross-site request forgery (CSRF) — บังคับ browser ของผู้ใช้ที่ login อยู่ให้ทำรายการโดยไม่รู้ตัว
• Insecure direct object reference (IDOR) — เปลี่ยน identifier แล้วเข้าถึงข้อมูลของผู้ใช้คนอื่น
• Use of cryptography — อัลกอริทึมที่อ่อน การจัดการ key ที่หละหลวม และ crypto ที่เขียนขึ้นเอง
• Clear-text transmission & sensitive information exposure — ข้อมูลสำคัญที่ส่งหรือรั่วออกไปแบบไม่เข้ารหัส
• Error & exception handling — stack trace และ error message ที่เผยไส้ในของระบบให้ผู้โจมตีเห็น
• Administration interface & access control — หน้า admin ที่เปิดสู่ภายนอกหรือป้องกันไว้ไม่พอ
• Application business logic — การใช้ workflow ในทางที่ผิด ข้ามขั้นตอน ยิงรายการซ้ำ เลี่ยงกติกาที่แอปพลิเคชันมีไว้บังคับ
• Web/application server security configuration — ตัว server ที่อยู่ใต้โค้ด ทั้ง header, service, ค่า default และสถานะ patch

ขั้นตอนการทดสอบ

ทุกงานมีการทดสอบสองแบบเดินคู่กัน และความต่างของสองแบบนี้สำคัญ Technical testing ล่าช่องโหว่ระดับ implementation อย่าง injection, XSS หรือ session ที่จัดการไม่ดี ช่องโหว่กลุ่มนี้มีอยู่ไม่ว่าแอปพลิเคชันจะทำหน้าที่อะไร ส่วน Business logic testing ล่าช่องโหว่ในกติกาของตัวแอปพลิเคชันเอง จะเกิดอะไรขึ้นถ้ามีคนเดิน workflow สลับลำดับ อนุมัติรายการของตัวเอง ใส่จำนวนติดลบ หรือใช้สิทธิ์ของ role หนึ่งไปเปิดข้อมูลของอีก role ช่องโหว่แบบนี้ scanner มองไม่เห็น เพราะในทางเทคนิคไม่มีอะไรพัง แอปพลิเคชันทำงานตามที่ถูกสร้างมาทุกประการ แค่ทำให้ผิดคน จากประสบการณ์ของเรา finding ที่กระทบธุรกิจหนักที่สุดมักซ่อนอยู่ตรงนี้ เราจึงกำหนดให้เป็นส่วนหนึ่งของระเบียบวิธีทุกงาน ไม่ใช่ของแถม

รอบนอกของงานเดินตามขั้นตอนเดียวกับบริการทดสอบเจาะระบบทุกงานของเรา

1. Preparation & scoping — ตกลงกันก่อนว่าทดสอบแอปพลิเคชันไหน environment ไหน และรูปแบบไหน black-box จำลองผู้โจมตีภายนอกที่ไม่รู้อะไรเกี่ยวกับระบบเลย ส่วน gray-box คุณให้ credential ของทุก role กับเรา เพื่อทดสอบตัว business process ได้เต็มรูปแบบ ทั้งการยกระดับสิทธิ์แนวตั้ง จากผู้ใช้ธรรมดาไปถึงฟังก์ชัน admin และแนวนอน จากผู้ใช้คนหนึ่งไปถึงข้อมูลของผู้ใช้อีกคน มุมที่ทดสอบก็เลือกได้ จะยิงจาก Internet หรือทดสอบจาก intranet สำหรับระบบภายในที่ไม่เปิดสู่สาธารณะ คุณจะได้ proposal ที่ระบุไทม์ไลน์ชัดเจนก่อนเริ่มงาน
2. Technical testing — ทดสอบด้วยมือไล่ตามรายการหมวดด้านบนใน scope ที่ตกลงกัน เครื่องมืออัตโนมัติช่วยเรื่องความครอบคลุม แต่ทุกประเด็นที่รายงานผ่านการยืนยันด้วยมือ ไม่มีผลดิบจาก scanner หลุดเข้ารายงานแน่นอน
3. Business logic testing — พอมี credential ของทุก role ในมือ เราเดิน workflow ของแอปพลิเคชันแบบเดียวกับที่มิจฉาชีพหรือคนในที่คิดร้ายจะเดิน ข้ามลำดับขั้นตอน แก้ parameter กลางทาง ข้าม role ไปหยิบข้อมูลของคนอื่น และใช้ฟีเจอร์ที่ตั้งใจให้มีประโยชน์ในทางที่ผิด
4. Reporting & retest — finding ทุกข้อจัดตาม Risk Level (Critical, High, Medium, Low) พร้อม POC และแนวทางแก้ มี executive summary สำหรับผู้บริหาร พอทีมคุณแก้เสร็จ เรา retest แล้วอัปเดตรายงานให้เห็นว่าปิดอะไรไปแล้วบ้าง

สิ่งที่คุณได้รับ

ทุกรายงานมีอย่างน้อยเท่านี้

• Executive summary — สรุปภาพความเสี่ยงในภาษาธุรกิจ ให้ผู้บริหารและ auditor อ่านแล้วตัดสินใจต่อได้
• Finding จัดตาม Risk Level — ทุกช่องโหว่จัดเป็น Critical, High, Medium หรือ Low และเทียบกับ OWASP Top 10 (2025) เรียงลำดับได้เลยว่าต้องแก้อะไรก่อน
• POC ประกอบทุก finding — request, payload และภาพหน้าจอครบ วิศวกรของคุณไม่ต้องเดาว่าเราเข้าไปได้ยังไง
• คำแนะนำการแก้ไข — วิธีแก้ที่เอาไปทำกับระบบของคุณได้จริง ไม่ใช่ boilerplate จาก scanner
• Retest ยืนยันผล — หลังคุณแก้เสร็จ เราตรวจซ้ำแล้วอัปเดตรายงานให้สะท้อนรายการที่ปิดไปแล้ว

เช่นเดียวกับงานทุกสายของบริษัท เราไม่เคยส่งรายงาน pentest เปล่าแม้แต่ฉบับเดียว ทุกงานที่ผ่านมาเจอ finding จริงที่ผ่านการยืนยันแล้วทั้งนั้น

ทีมและใบรับรอง

ทีมภายในของเราลงมือทดสอบเองทุกงาน ถือใบรับรองในวงการอย่าง OSCP, OSCE, CREST CRT, CREST CPSA และ GIAC GREM ที่ต้องผ่านการสอบภาคปฏิบัติอย่างเข้มข้นกว่าจะได้มา ดูใบรับรองทั้งหมดที่ทีมถือ

มาตรฐานที่ใช้

ระเบียบวิธีของเราเดินตาม NIST SP800-115 (Technical Guide to Information Security Testing and Assessment) สอดคล้องกับ Penetration Testing Execution Standard (PTES) และ OSSTMM โดย finding ทุกข้อเทียบเข้ากับ OWASP Top 10 (2025) ถ้าแอปพลิเคชันของคุณอยู่ในระบบที่เกี่ยวกับบัตรชำระเงิน งานทดสอบเว็บชิ้นนี้ต่อเข้ากับ scope ของ PCI DSS ที่กว้างกว่าได้โดยตรง วาง scope และเขียนรายงานในแบบที่ QSA คุ้นเคย ถ้า audit ของคุณต้องการหลักฐานรูปแบบเฉพาะ บอกเราได้เลยตอน scoping ปรับรายงานให้ตรงตั้งแต่ตอนนั้นโดยไม่มีค่าใช้จ่ายเพิ่ม