API & Web Service Penetration Test

ทำไม API Penetration Test ถึงสำคัญ

API เป็นหัวใจของ digital ecosystem สมัยใหม่ — ทุก mobile app, single-page application, partner integration และ microservice สื่อสารผ่าน API ปริมาณ API traffic เติบโตอย่างรวดเร็ว แต่ security control มักตามไม่ทัน เพราะ API ถูกออกแบบมาเพื่อเปิดเผยข้อมูลและฟังก์ชันโดยตรง ทำให้เป็นเป้าหมายหลักของผู้โจมตี

จากสถิติในอุตสาหกรรม ช่องโหว่ Broken Object Level Authorization (BOLA) เพียงอย่างเดียวสามารถทำให้ผู้โจมตีเข้าถึงข้อมูลของผู้ใช้รายอื่นได้ทั้งหมด เพียงแค่เปลี่ยนค่า ID ใน request — และเครื่องมือ automated scanner แทบตรวจไม่พบช่องโหว่ประเภทนี้

สำหรับองค์กรที่มี Open Banking API, payment gateway, หรือ API ที่เชื่อมต่อกับคู่ค้า การทดสอบเจาะระบบ API เป็นสิ่งที่ regulator คาดหวังอย่างชัดเจน

ขอบเขตการทดสอบ (Testing Scope)

Authorization & Access Control

• BOLA (Broken Object Level Authorization) — ทดสอบการเข้าถึง resource ข้าม user โดยเปลี่ยน object ID ในทุก endpoint ที่มีการอ้างอิง resource
• BFLA (Broken Function Level Authorization) — ทดสอบการเข้าถึง administrative function ด้วย credential ของ user ทั่วไป รวมถึง HTTP method tampering (GET→PUT/DELETE)
• Mass Assignment / Excessive Data Exposure — ทดสอบการส่ง parameter เกินที่ API คาดหวัง เช่น เพิ่ม role: admin ใน request body และตรวจสอบ response ที่ส่งข้อมูลเกินความจำเป็น

Authentication & Token Security

• JWT Analysis — ตรวจสอบ algorithm confusion (none, HS256→RS256), weak secret, missing expiration, claim manipulation และ JWK injection
• OAuth 2.0 Flow Testing — ทดสอบ authorization code interception, PKCE bypass, scope escalation, token leakage ผ่าน redirect_uri manipulation
• API Key Management — ตรวจสอบ key exposure ใน client-side code, insufficient key rotation, missing key scoping

Input & Logic Testing

• Rate Limiting & Resource Exhaustion — ทดสอบ brute force protection, API abuse through excessive requests, pagination abuse, และ query complexity attack
• Server-Side Request Forgery (SSRF) — ทดสอบ SSRF ผ่าน parameter ที่รับ URL/IP เพื่อเข้าถึง internal service หรือ cloud metadata endpoint
• Injection in API Context — NoSQL injection, GraphQL injection, JSON injection และ parameter pollution เฉพาะ API
• Data Validation — ทดสอบ type confusion, boundary value, enum bypass, และ schema validation bypass

GraphQL-Specific Testing

• Introspection & Schema Disclosure — ตรวจสอบว่า introspection query ถูก disable ใน production หรือไม่ และวิเคราะห์ schema เพื่อหา sensitive field
• Query Depth & Complexity Attack — ทดสอบ nested query ที่อาจทำให้ server ทำงานหนักเกินไป (DoS via query complexity)
• Batching & Alias Abuse — ทดสอบการส่ง multiple query ในครั้งเดียวเพื่อ bypass rate limiting หรือ brute force

Infrastructure & Configuration

• Endpoint Discovery — ค้นหา undocumented endpoint, debug endpoint, deprecated version ที่ยังเปิดอยู่
• CORS & Security Headers — ตรวจสอบ CORS policy ของ API endpoint, missing security headers, verbose error response

แนวทางการทดสอบ

ทีมงานใช้แนวทาง API-first testing ที่ออกแบบมาสำหรับ API โดยเฉพาะ ไม่ใช่การนำ methodology ของ web application มาใช้กับ API โดยตรง

ขั้นตอนเริ่มจากการ API discovery — วิเคราะห์ OpenAPI spec, traffic capture จาก mobile app หรือ web frontend, และ JavaScript source analysis เพื่อสร้าง complete API map จากนั้นจึงทดสอบทุก endpoint ด้วย manual testing เน้นที่ authorization logic ซึ่งเป็นจุดที่พบช่องโหว่บ่อยที่สุดใน API

ผลลัพธ์ทุกรายการมาพร้อม HTTP request/response pair ที่ reproduce ได้ทันที ทำให้ทีม development สามารถเข้าใจและแก้ไขได้โดยไม่ต้องตีความ

วิธีการทดสอบ

• OWASP API Security Top 10:2023 — ครอบคลุมช่องโหว่เฉพาะของ API ทั้ง 10 หมวดหมู่
• OWASP REST Security Cheat Sheet — แนวทางทดสอบสำหรับ RESTful API โดยเฉพาะ
• Manual business logic testing — ทดสอบ authorization flow ข้าม resource และ tenant
• Automated fuzzing & schema analysis — ใช้ OpenAPI/Swagger spec เป็น baseline สำหรับ endpoint discovery
• Authentication & token analysis — วิเคราะห์ JWT, OAuth 2.0 flow, API key management อย่างเจาะลึก

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

• Executive Summary — สรุปความเสี่ยงภาพรวมของ API ecosystem สำหรับผู้บริหาร
• Technical Report — รายละเอียดช่องโหว่ทุกรายการพร้อม HTTP request/response ที่ reproduce ได้
• API Attack Surface Map — แผนภาพ endpoint ทั้งหมดพร้อมระบุจุดที่มีความเสี่ยง
• Remediation Guideline — คำแนะนำการแก้ไขเฉพาะ framework (Spring Boot, Express, FastAPI, Laravel ฯลฯ)
• OWASP API Top 10 Coverage Matrix — แสดงผลการทดสอบตาม checklist มาตรฐาน
• Postman/cURL Collection — ชุดคำสั่งสำหรับ development team ใช้ verify การแก้ไข

ระยะเวลา

5–15 วันทำการ

ราคาโดยประมาณ

เริ่มต้นที่ระดับ 5 manday — ขึ้นอยู่กับจำนวน endpoint, authentication scheme และรูปแบบ API — คำนวณงบเอง

คำถามที่พบบ่อย

การทดสอบ REST API กับ GraphQL API แตกต่างกันอย่างไร?

REST API ทดสอบเป็นรายตัวตาม endpoint และ HTTP method (GET/POST/PUT/DELETE) เน้นที่ BOLA, BFLA และ parameter manipulation ส่วน GraphQL มีจุดเข้าถึงเดียว (/graphql) แต่มีความซับซ้อนในระดับ query — ต้องทดสอบ introspection disclosure, query depth/complexity abuse, batching attack, field-level authorization และ nested object traversal ที่อาจข้าม access control ได้ ทีมงานมีเครื่องมือและ methodology เฉพาะสำหรับทั้งสองรูปแบบ

ต้องเตรียม API documentation ให้ก่อนทดสอบหรือไม่?

การมี OpenAPI/Swagger specification หรือ Postman collection จะช่วยให้ทีมงานครอบคลุม endpoint ได้ครบถ้วนและรวดเร็วขึ้น แต่ไม่ใช่ข้อบังคับ — ทีมงานสามารถทำ API discovery จาก traffic analysis, mobile app reverse engineering หรือ JavaScript source analysis ได้ อย่างไรก็ตาม การให้ documentation จะช่วยลดเวลาในส่วน reconnaissance และเพิ่มเวลาสำหรับ deep testing มากขึ้น

API versioning มีผลต่อการทดสอบอย่างไร?

เป็นประเด็นสำคัญครับ หลายองค์กรมี API หลายเวอร์ชัน (v1, v2, v3) ทำงานอยู่พร้อมกัน โดยเวอร์ชันเก่ามักมี security control ที่อ่อนแอกว่า ทีมงานจะทดสอบทุกเวอร์ชันที่ยังเปิดใช้งานอยู่ รวมถึงตรวจหา deprecated endpoint ที่ยังเข้าถึงได้ ซึ่งเป็นช่องโหว่ที่พบบ่อยมากในองค์กรขนาดใหญ่

API ที่ใช้ภายในองค์กร (internal API) จำเป็นต้องทดสอบด้วยหรือไม่?

จำเป็นอย่างยิ่งครับ Internal API มักถูกออกแบบโดยสมมติว่าอยู่ใน trusted network จึงมักขาด authentication หรือมี authorization ที่หละหลวม หากผู้โจมตีเข้าถึง internal network ได้ (ผ่าน VPN compromise, phishing หรือ SSRF) internal API มักเป็นเป้าหมายแรกที่ถูกโจมตี