การทดสอบเจาะระบบ 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:

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

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

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

สิ่งที่ automated scanner มองไม่เห็น #

ควรพูดให้ชัดว่า automation พลาดอะไร เพราะ gap เหล่านั้นไม่ได้กระจายมั่ว: มันรวมตัวกัน พอดีตรงที่เงินวิ่งอยู่

BOLA ในความจริง scanner ทดสอบ endpoint ที่มันค้นพบ และ parameter ที่มันเข้าใจ ลองนึกถึง invoice API: GET /invoices/8842 คืน invoice ของคนที่เรียกใช้เอง scanner ก็ log ว่าผ่าน แต่ GET /invoices/8843 ที่เป็น invoice ของลูกค้าอีกรายอาจคืนค่าให้เช่นกันอย่างสบาย ๆ และไม่มี scanner ไหน จะลอง เพราะการรู้ว่า 8843 เป็นของคนอื่นต้องเข้าใจว่า ownership แปลว่าอะไรในธุรกิจของคุณ ทุก object identifier ที่ข้ามขอบเขต tenant คือ BOLA ที่มีศักยภาพ และมีแต่ analyst ที่ enumerate object ข้าม account เท่านั้นที่จะเจอมัน

Business logic flaw scanner ทดสอบว่า request สำเร็จหรือ fail แต่ logic flaw อยู่ใน request ที่ สำเร็จเมื่อมันไม่ควรสำเร็จ ตัวอย่างจริงจาก engagement: ใช้ coupon code ซ้ำได้เพราะ check การ redeem เกิดหลัง capture การชำระเงิน, โอน booking ระหว่าง account โดยไม่ re-authorise, หรือยกเลิก order ที่จ่ายแล้วหลังจัดส่งเพราะ cancel endpoint ไม่เคย check สถานะการจัดส่ง ทุกเคสคืน HTTP 200 กลับมา ทุกเคสคือความเสียหายทางการเงินที่ไม่มี error message ให้เห็นเลยสักชิ้น

Trust assumption ระหว่าง service ใน microservices estate service หนึ่งมักเชื่อ header, token หรือ internal endpoint ที่ “caller” ยื่นมาให้ เพราะใน diagram ตอนออกแบบ caller คือ internal service ด้วยกันเองเสมอ แล้ววันหนึ่ง service หนึ่งถูก compromise หรือ internal endpoint หนึ่งกลายเป็น reachable จาก network segment ที่เชื่อถือน้อยกว่า trust assumption ที่สืบทอดกันมาเหล่านั้นกลายเป็น บันไดของ attacker: authenticate ผ่าน edge service ที่อ่อนก่อน แล้วยื่น identity ของมันไปต่อที่ API ที่มีของมีค่าอยู่ การเจอแบบนี้ต้องอ่านสถาปัตยกรรมตามที่ designer ตั้งใจ แล้วทดสอบมันตามที่ attacker จะเดินผ่านมัน

ไม่มีอะไรในข้อสามข้อนี้ปรากฏใน scanner output เลย ทั้งหมดปรากฏในรายงานของ analyst ที่ใช้เวลา ทำความเข้าใจว่า API ของคุณ เอาไปทำอะไร จริง ๆ

ไม่แน่ใจว่าพื้นผิว API ของคุณถูกทดสอบจริงหรือยัง? ติดต่อเพื่อรับการตรวจสอบแบบตรงไปตรงมา คุยได้ทาง LINE (@PureSecurity) หรืออีเมล (hello@puresecurity.com)

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