การทดสอบเจาะระบบ API อย่างมีประสิทธิภาพในประเทศไทย

แอปพลิเคชันส่วนใหญ่เลิกเป็น “เว็บไซต์” มาหลายปีแล้ว ตอนนี้มันคือ API: microservices เรียกหากันเอง มี mobile client อยู่ปลายหนึ่ง และ payment rail อยู่อีกปลายหนึ่ง แต่บทสนทนาเรื่องความมั่นคงปลอดภัยยังตามไม่ทัน ทีมงานยังคงซื้อ “การทดสอบเจาะระบบเว็บแอปพลิเคชัน” ที่ทุ่มแรง 80% ไปที่ front end ในขณะที่ API ด้านหลัง ซึ่งเป็นจุดที่เงินและข้อมูลไหลผ่านจริง กลับถูกทดสอบน้อยเกินไป

ทำไม API ถึงทำให้เครื่องสแกนใช้งานไม่ได้ #

เครื่องสแกนเว็บอัตโนมัติถูกสร้างบนโมเดลแบบเพจ: ไล่เก็บลิงก์ หาฟอร์ม แล้วยิง payload แต่ API ไม่ได้นำเสนอเป็นเพจ มันนำเสนอเป็น route, method และ schema และพฤติกรรมที่น่าสนใจอยู่ใน business logic ที่อยู่ระหว่างสิ่งเหล่านั้น

ลองนึกถึงช่องโหว่การเข้าถึงระดับ object: ผู้ใช้เปลี่ยนค่า user_id=1024 เป็น user_id=1025 ใน request แล้วอ่านข้อมูลของคนอื่น ไม่มี signature ใดถูกเรียก ไม่มี payload ใดเป็นอันตราย เครื่องสแกนเห็น request ปกติจึงปล่อยผ่านไป นี่คือ Broken Object Level Authorisation (BOLA) ซึ่งเป็นอันดับหนึ่งใน OWASP API Security Top 10 และแทบมองไม่เห็น ด้วยเครื่องมืออัตโนมัติเกือบทุกตัว

นี่คือเหตุผลหลักที่ต้องทดสอบ API ด้วยมนุษย์: ช่องโหว่ที่ร้ายแรงที่สุดคือช่องโหว่ เชิงการออกแบบ และช่องโหว่เชิงการออกแบบต้องอาศัยนักวิเคราะห์ที่เข้าใจบริบททางธุรกิจจึงจะหาเจอ

การทดสอบ API ที่มีประสิทธิภาพต้องครอบคลุมอะไรบ้าง #

การประเมิน API ที่มีความหมายต้องไปไกลกว่าแค่เอาเครื่องสแกนไปยิง OpenAPI spec:

• Authentication และ authorisation: การจัดการ token การตรวจสอบ scope และการเข้าถึง ระดับ object ในทุกขอบเขตของบทบาท
• Business logic: ผู้ใช้สามารถสั่งซื้อด้วยราคาติดลบได้ไหม เล่นซ้ำ payment callback ได้ไหม หรือข้ามขั้นตอน workflow ด้วยการเรียก endpoint ถัดไปตรง ๆ ได้ไหม
• Data exposure: endpoint ไหนคืน field เกินจำเป็น และ endpoint ไหนรับ field ที่ client ไม่ควรส่งเลย
• Rate limiting และการละเมิด: การไล่เดา การยัด credential และเส้นทางการยึดบัญชี ที่อาศัยช่องโหว่ของ throttling ที่อ่อนแอ
• Integration boundaries: webhook, callback จากบุคคลที่สาม และ message queue ที่มักถูกสันนิษฐานว่าเชื่อถือได้โดยไม่เคยถูกตรวจสอบ

นี่คือเหตุผลที่การทำงานที่ดีที่สุดคือจับคู่การโจมตีเชิงปฏิบัติด้วยมือ เข้ากับ การสำรวจและ fuzzing ที่มี AI ช่วย: ระบบอัตโนมัติขยายความครอบคลุม มนุษย์ตัดสินความรุนแรงและบริบท

ต่อเนื่อง ไม่ใช่ปีละครั้ง #

การทดสอบ API ปีละครั้งคือภาพถ่าย ณ จุดเวลาเดียวของระบบที่ deploy ทุกสัปดาห์ กว่าจะเขียนรายงานเสร็จ endpoints ก็เปลี่ยนไปแล้ว แนวทางสมัยใหม่คือการพับการตรวจสอบ ความมั่นคงปลอดภัยของ API เข้าไปใน delivery pipeline:

1. Shift-left ด้วย static analysis และ schema validation ใน CI
2. ทดสอบทุก release: การทบทวนแบบเจาะจงเมื่อพื้นผิว API เปลี่ยนไป
3. เจาะลึกประจำปี: การประเมินเต็มรูปแบบโดยมนุษย์ เพื่อ audit trail และ business logic ที่ pipeline ไม่สามารถตัดสินได้

PCI DSS Requirement 6 และ Requirement 11.4 ต่างผลักดันไปในทิศทางนี้สำหรับองค์กรที่สัมผัสข้อมูลบัตร และแนวปฏิบัติช่องทางดิจิทัล ของธนาคารแห่งประเทศไทยก็ยกระดับมาตรฐานให้เข้มขึ้นอีกสำหรับระบบการเงิน

บริการ การตรวจสอบความมั่นคงปลอดภัยของ API และแอปพลิเคชัน ของเราผสานการทบทวนซอร์สโค้ดเข้ากับการโจมตีด้วยมือ และ การทดสอบเจาะระบบ ครอบคลุมขอบเขตภายนอก และการแบ่งส่วนเครือข่ายรอบ ๆ หากต้องการกำหนดขอบเขตการทดสอบให้ตรงกับสถาปัตยกรรมจริงของคุณ นัดหมายพูดคุยขอบเขตงาน