บริการ API Penetration Testing
บริการ API Penetration Testing ที่ได้รับการรับรองจาก CREST ครอบคลุม REST, GraphQL, gRPC และ SOAP โดยสอดคล้องกับ OWASP API Security Top 10 และคำแนะนำของ NIST
API คือชั้นปฏิบัติการหลักขององค์กรยุคใหม่ ซึ่งเชื่อมแอปพลิเคชันกับ Backend ผสาน SaaS, Mobile, และ Cloud และมักรองรับ Business Logic ที่มีมูลค่าสูงที่สุดขององค์กร ในขณะเดียวกัน API ยังรวมความเสี่ยงไว้ในรูปแบบที่ UI รอบข้างมักมองไม่เห็น จึงเป็นเหตุผลที่การทดสอบเฉพาะ API มักพบประเด็นผลกระทบสูงได้มากกว่าการทดสอบเว็บเพียงอย่างเดียว
โครงการทดสอบ API ของ Vantage Point ใช้ Threat Model จากสัญญาหรือเอกสาร API ที่มีอยู่ร่วมกับ Manual Exploitation เชิงลึกบนบริการที่ทำงานจริง เราทดสอบการยืนยันตัวตนและการกำหนดสิทธิ์ (Authentication & Authorisation) การเปิดเผยข้อมูล และช่องโหว่ Business Logic ครอบคลุมในระบบ REST, GraphQL, gRPC และ SOAP โดยเชื่อมโยงช่องโหว่ที่พบกับ OWASP API Security Top 10 และ Test Case เฉพาะในคลัง API ของ Velocity
ในกรณีที่ API หันหน้าสู่แอปพลิเคชันมือถือหรือเบราว์เซอร์ การทดสอบมักจะรวมเข้ากับบริการทดสอบเว็บหรือมือถือที่สอดคล้องกัน เพื่อให้สามารถทดสอบการอนุญาตการเข้าถึงได้ครบตั้งแต่ต้นจนจบตั้งแต่ฝั่งไคลเอนต์จนถึง Backend
ความเสี่ยงที่ต้องพิจารณา
API เป็นจุดรวมของความเสี่ยงด้านการอนุญาตการเข้าถึง
Web UI อาจมีหนึ่ง URL ต่อหนึ่งหน้า แต่ API อาจมี Endpoint หลายร้อยรายการ ซึ่งแต่ละรายการมีระบบการกำหนดสิทธิ์ของตนเอง การขาดการตรวจสอบเพียงจุดเดียวก็อาจนำไปสู่เหตุการณ์ละเมิดความปลอดภัยที่มีผลกระทบสูงได้
เอกสาร API มักไม่ตรงกับระบบที่ทำงานจริง
API Spec มักเปลี่ยนไม่ทันบริการจริง มีการเพิ่ม Endpoint ในช่วงเร่งด่วน ความหมายของ Parameter เปลี่ยนไปจากเดิม องค์ประกอบต่าง ๆ ที่ไม่อยู่ในเอกสารอาจค้างอยู่ในระบบเป็นปี ๆ การทดสอบกับบริการที่ทำงานจริงช่วยค้นพบสิ่งที่การทบทวนเอกสารไม่สามารถเห็นได้
Mobile และ Partner Integration ทำให้การเปิดเผยเพิ่มขึ้น
API มักสร้างขึ้นสำหรับ "แอปมือถือ" หรือ "พาร์ทเนอร์ที่เชื่อถือได้" แต่เมื่อเผยแพร่แล้ว ทุกคนสามารถเข้าถึงได้ รวมถึง Hacker ที่ Reverse Engineer โค้ดฝั่ง Client เพื่อค้นหา API เหล่านั้น
สิ่งที่เราทดสอบ
การยืนยันตัวตนและการกำหนดสิทธิ์
จุดเริ่มต้นของการรั่วไหลของ API ส่วนใหญ่ โดยครอบคลุม OWASP API Top 10 #1, #3 และ #5
- Broken Object-Level Authorisation (BOLA / IDOR) หรือช่องโหว่การกำหนดสิทธิ์ในระดับ Object
- Broken Authentication (การยืนยันตัวตนที่ไม่ปลอดภัย)
- Broken Function-Level Authorisation หรือช่องโหว่การกำหนดสิทธิ์ในระดับ Function
- JWT Signature Confusion และ Algorithm Abuse
- ช่องโหว่ใน OAuth Flow และ Consent Abuse
Data, Infrastructure และ Abuse
กลุ่มช่องโหว่ที่ขยายตัวตามขนาดของ API Surface และเป็นพื้นที่ที่ Test Case ที่สม่ำเสมอสามารถจับช่องโหว่ที่การทดสอบแบบไม่มีโครงสร้างมักพลาด
- Excessive Data Exposure
- Mass Assignment
- Unrestricted Resource Consumption
- API Injection (SQL, NoSQL, Command, XML, JSON)
- Security Misconfiguration (การตั้งค่าที่ไม่ปลอดภัย) และ Management Endpoints
- การบันทึก Log และการตรวจสอบ (Logging & Monitoring) ที่ไม่เพียงพอ
ช่องโหว่ที่เรามักพบจากการทดสอบในลักษณะนี้
ข้อมูลที่นำเสนอเป็นกลุ่มช่องโหว่ที่ที่ปรึกษาของเรามักพบจากการทดสอบในลักษณะเดียวกัน ความรุนแรงและความถี่จะแตกต่างกันตามสภาพแวดล้อมและระดับความพร้อมของแต่ละองค์กร
BOLA / IDOR
endpoint ที่ส่งคืนข้อมูลโดยกำหนดขอบเขตจากตัวระบุที่ผู้ใช้ให้มาเท่านั้น การเพิ่มค่า ID แบบตัวเลขเพื่อระบุผู้ใช้งานรายอื่น และการอ่านข้อมูลข้ามสิทธิผู้ใช้งานผ่านฟิลด์อ้างอิงภายใน
Broken Function-Level Authorisation หรือช่องโหว่การกำหนดสิทธิ์ระดับ Function
Admin Endpoint ที่ผู้ใช้ที่ผ่านการยืนยันตัวตนแล้วทุกคนเข้าถึงได้ การตรวจสอบ Role ที่มีอยู่ใน UI แต่ไม่มีใน API และการ Bypass ผ่าน HTTP Verb (POST แทน PUT) บน Endpoint ที่ป้องกัน
ช่องโหว่ใน JWT / Token
Token ถูกยอมรับด้วย Algorithm "none", RS-to-HS Confusion, ขาดการตรวจสอบ Audience Claim และ Refresh Token ที่มีอายุยาวเกินความจำเป็นด้านความปลอดภัย
Excessive Data Exposure
Endpoint ที่คืนค่า User Object โดยเต็มทั้งที่ระบบต้องการเพียงชื่อและ Avatar, การเปิดเผย Internal ID, Computed Flag หรือ Backend System Field ไปยัง Client
Mass Assignment
POST/PUT Body ที่ยอมรับฟิลด์ที่ UI ไม่เคยส่ง (เช่น role, is_admin, balance) แล้วแอบอัปเดต Attribute ที่ละเอียดอ่อนเหล่านั้น
Rate Limiting และการใช้งานในทางที่ผิด
Login Endpoint ที่ไม่มี Rate Limiting, OTP Endpoint ที่ใช้ซ้ำได้, และ Query Endpoint ที่ใช้ทรัพยากรสูงโดยไม่มี Quota เปิดให้เกิด DoS ผ่านการดัดแปลง Request
แนวทางการทำงานที่มีโครงสร้างชัดเจน ขับเคลื่อนด้วยข้อมูลเชิงลึกในทุกการทดสอบ
ทุกโครงการดำเนินตามแนวทางที่มีระเบียบวินัยเดียวกันผ่านแพลตฟอร์ม Velocity เพื่อให้คุณภาพ การติดตามตรวจสอบ และการรายงานมีมาตรฐานเดียวกันในทุกทีม
การกำหนดขอบเขต
กำหนดสินทรัพย์ สภาพแวดล้อม ข้อกำหนดในการทดสอบ และเกณฑ์การยอมรับร่วมกับผู้เกี่ยวข้องด้านเทคนิคและความปลอดภัย
การดำเนินการ
การทดสอบแบบ Manual และด้วยเครื่องมือโดยที่ปรึกษาที่ได้รับการรับรอง CREST พร้อมเก็บหลักฐานในทุกขั้นตอน
การตรวจสอบความถูกต้อง
ทุกการค้นพบจะถูกทำซ้ำ ประเมินระดับความเสี่ยงด้วย CVSS และยืนยันโดยที่ปรึกษาท่านที่สองก่อนรายงานผล
การรายงาน
รายงานที่ลงนามด้วยรหัส พร้อมการอ้างอิง Test Case การจัดระดับความรุนแรง ขั้นตอนการทำซ้ำ และแนวทางแก้ไข
สรุปผลและการทดสอบซ้ำ
การประชุมสรุปผลกับผู้เกี่ยวข้อง การช่วยจัดลำดับความสำคัญ และการทดสอบซ้ำหลังการแก้ไข
อ้างอิงมาตรฐานสากลที่ได้รับการยอมรับ
คำถามจากผู้สนใจใช้บริการ
ทดสอบได้หรือไม่ หากเรามีเพียง OpenAPI / Swagger / GraphQL Schema? +
ได้ เอกสารคือจุดเริ่มต้นที่ดี เราจะ Enumerate ระบบที่ทำงานอยู่จริง รวมถึง Endpoint ที่ไม่ได้บันทึกใน Spec ก่อนการทดสอบ ช่องโหว่ในโลกจริงส่วนใหญ่มาจากขั้นตอน Enumeration นี้
จัดการการทดสอบที่ต้องยืนยันตัวตนอย่างไร? +
ทางทีมเจ้าของระบบต้องจัดเตรียม Token หรือ Credentials สำหรับแต่ละ Role ที่ต้องการทดสอบ เรามักทดสอบด้วย Role ที่แตกต่างกันอย่างน้อยสองชุด เพื่อประเมินการกำหนดสิทธิ์ได้อย่างถูกต้อง โดยทั่วไปคือ Standard User, Administrator และ Role ที่จำกัดต่อ Tenant
ทดสอบ API ของบุคคลที่สามที่เราใช้งานหรือไม่? +
การทดสอบ API ของบุคคลที่สามโดยปกติจะห้ามไว้ตาม Terms of Service ของผู้ให้บริการ เรามุ่งทดสอบบริการขององค์กรคุณเอง รวมถึงชั้น Integration ที่เชื่อมต่อกับ API ภายนอก (ซึ่งหากมีช่องโหว่ ก็ยังเป็นความรับผิดชอบขององค์กรคุณ)
การทดสอบ GraphQL และ REST แตกต่างกันอย่างไร? +
GraphQL มีรูปแบบการโจมตีเฉพาะตัว เช่น Introspection, Depth and Complexity, Batching Abuse และ Broken Object-Level Authorisation บน Type Relationship เราทดสอบด้วยเครื่องมือและวิธีการทดสอบที่ออกแบบมาเฉพาะสำหรับ GraphQL
ทดสอบการป้องกันของท่านกับผู้เชี่ยวชาญด้านการรักษาความปลอดภัยเชิงรุก
ปรึกษาที่ปรึกษาที่ได้รับการรับรอง CREST เกี่ยวกับการทดสอบ Penetration Testing ครั้งถัดไปของท่าน