Shadow API คืออะไร? เมื่อ Undocumented Route กลายเป็น Data Breach

ในบทความนี้จะพาไปทำความเข้าใจว่า Shadow API คืออะไร ทำไมถึงอันตราย แล้วเหล่า Pentester อย่างพวกเราค้นหาเจอได้อย่างไรบ้าง มักพบช่องโหว่แบบไหน

บทนำ

สวัสดีครับผู้อ่านทุกท่าน วันนี้เราจะมาทำความรู้จักกับช่องทางโจมตีที่ Pentester อย่างพวกเราชอบมองหากันครับ นั่นคือ “ช่องทางที่ถูกละเลยการดูแล หรือถูกสร้างขึ้นแล้วลืมบันทึก Document ไว้ จนไม่มีใครในองค์กรจำได้ว่ามันมีอยู่หรือไม่”

Shadow API คืออะไร?

API ที่ทำงานอยู่จริงบนระบบ Production แต่ไม่ได้ถูกบันทึกไว้ในเอกสาร (Undocumented) เช่น ไม่มีอยู่ในไฟล์ OpenAPI หรือ Swagger ครับ เหล่านี้เราเรียกว่า “Shadow API” ครับ อาจเกิดจากทีม Dev ที่ต้องแก้ Bug ด่วนหรือสร้าง Endpoint ไว้ทดสอบหรือดึงข้อมูลชั่วคราวแล้วเกิดการลืมถอดออก ตัวอย่างเช่น

/api/v1/internal/admin-export" หรือ "/api/staging/debug-user

ทำไม API เหล่านี้ถึงอันตรายในสายตา Pentester

Shadow API ในมุมมองของ Pentester มักเป็นเป้าหมายอันดับต้นๆ ครับ เพราะมีแนวโน้มสูงที่ Endpoint จะไม่มีการยืนยันตัวตน (Unauthenticated), ไม่มีการจำกัดอัตราเรียกใช้ (No Rate Limit) และไม่มีการเก็บ Log ทำให้ผู้โจมตียิงคำขอเข้ามาได้เรื่อย ๆ โดยที่ระบบไม่ส่งสัญญาณเตือนอะไรเลย และที่น่าคิดคือ การเจาะช่องโหว่เหล่านี้แทบไม่ต้องใช้เทคนิคการโจมตีที่ซับซ้อนอย่างการหา Zero-day เพียงแค่เรียก Endpoint ที่ถูกลืมทิ้งไว้ตรง ๆ ก็เข้าถึงข้อมูลได้แล้ว

OWASP ได้จัดหมวดหมู่ปัญหานี้ไว้อย่างชัดเจนใน API9:2023 - Improper Inventory Management ซึ่งชี้ให้เห็นแนวคิดสำคัญว่า เราไม่สามารถปกป้องสิ่งที่เรามองไม่เห็นได้ ถ้าองค์กรไม่รู้ด้วยซ้ำว่ามี API ตัวไหนทำงานอยู่บ้าง แล้วจะตั้ง Rate Limit, ตรวจสอบสิทธิ์ (Authorization) หรือแพตช์ (Patch) ช่องโหว่ได้อย่างไร

Pentester ค้นหา Shadow API ได้อย่างไร

ทีนี้มาถึงส่วนของเทคนิคการค้นหาขุมทรัพย์เหล่านี้กันนะครับ

technique /01 : Frontend Analysis

Web Application ยุคใหม่ถูกเขียนด้วย React, Vue หรือ Next.js มักจะ Compile Code ที่ฝั่ง Client รวมกันไว้ในไฟล์ JavaScript ทำให้บางทีทีม Dev อาจลืมลบ Hardcoded URL ทำให้เราเจอ Route ลับ ๆ ได้อย่างง่ายดายเพียงวิเคราะห์ไฟล์ JavaScript

ยกตัวอย่าง :

เราค้นพบเว็บไซต์นึงชื่อว่า “CorpShop” และค้นพบข้อมูลต่าง ๆ เช่น Product รวมถึง API Documentation ที่เป็น Public Endpoints จำนวน 2 Endpoints แล้วเราจะหา Endpoints ที่ถูกซ่อนไว้ได้อย่างไรบ้าง

Old School Way: ทำการดู Source Code ของหน้านั้น (1)

ซึ่งเราพบว่าในส่วนของ Endpoints ที่เราเจอผ่านหน้าเว็บจะเป็นในส่วนของ (1) และเราพบว่ามี Shadow Endpoints (2) เพียงอ่าน Page Source

หากเราเข้าไปดูข้างในของ Endpoints เหล่านั้น ยกตัวอย่าง “/api/internal/debug/config” จะพบข้อมูล Credential (1) ไม่ว่าจะเป็น aws_key และ Database “root:S3cretDB!2024” ซึ่งเข้าข่าย Security Misconfiguration (API8:2023) ทำให้เราสามารถนำข้อมูลชุดนี้เข้าถึง Service อื่น ๆ ต่อไปได้อย่างง่ายดาย

Modern Way: เราใช้ Tools ครับ ไม่ว่าจะเป็นประเภท Endpoints Extractor, JS Miner ใน Burp Suite Extension รวมไปถึงการใช้ AI ในการวิเคราะห์ไฟล์ JavaScript ครับ

technique /02 : Fuzzing

หากการวิเคราะห์ JavaScript ไม่เพียงพอแล้ว เราจะใช้เครื่องมืออย่าง ffuf , kiterunner หรือ fuzzing tool ตามที่ถนัด ร่วมกับ Wordlist ต่าง ๆ เช่น Seclists, AssetNote เป็นต้นครับ

ยกตัวอย่าง :

เราใช้เครื่องมืออย่าง dirsearch รวมกับ Wordlist ของ AssetNote ที่รวบรวมข้อมูลเกี่ยวกับ API และพบว่ามี /api/v2/users (1)

เราเข้ามาดูที่ “/api/v2/users” เราจะพบข้อมูลของ users จำนวน 3 เช่น email, id, role และ ssn ครับ ซึ่ง Endpoints นี้สามารถเข้าถึงโดย Anonymous User ได้เลย ไม่มีการ Authentication แต่อย่างใด

ช่องโหว่ที่มักเจอ อ้างอิงตาม OWASP API Security Top 10 - 2023

จากที่เราค้นพบ Endpoint ที่ซ่อนอยู่ในสองเทคนิคก่อนหน้า ทีนี้มาดูกันครับว่าเกิดช่องโหว่อะไรบ้าง โดยเราอ้างอิงตาม OWASP API Security Top 10 - 2023

1. Broken Authentication - API2: 2023
   ถือเป็นช่องโหว่ที่ Endpoint ส่วนใหญ่เรียกใช้งานได้เลยโดยไม่ต้องยืนยันตัวตน (Unauthenticated) ทำให้ข้อมูลที่ควรจะเห็นได้เฉพาะคนที่ล็อกอินแล้ว กลับถูกเปิดให้ Anonymous User เข้าถึงได้ทั้งหมดครับ ยกตัวอย่างที่ชัดเจนที่สุดคือ /api/v2/users เมื่อเราเรียกดูโดยไม่ต้องล็อกอิน ก็เห็นข้อมูลผู้ใช้งานทั้งหมดทั้ง email, id, role และ ssn
2. Broken Object Level Authorization (BOLA) - API1: 2023
   ความแตกต่างระหว่าง Broken Authentication (API2: 2023) กับ Broken Object Level Authorization (API1:2023) อาจมีหน้าตาคล้ายกันแต่คนละปัญหา และวิธีแก้ปัญหาก็แตกต่างกันครับ โดยเหล่า Pentester จะมีเส้นแบ่งช่องโหว่นี้คร่าว ๆ คือ ตรวจสอบว่า Session มีการทำงานถูกต้องตามการทำงานหรือไม่ครับ
   2.1 BOLA (API1:2023) คือกรณีที่เรา ล็อกอินเข้าระบบมาอย่างถูกต้องแล้ว (มี Session ใช้งานเว็บได้ปกติ) แต่ระบบดันยอมให้เราเข้าถึง Object ของผู้ใช้คนอื่นได้ เช่น ล็อกอินเป็น User A แล้วเปลี่ยน Id ไปดูข้อมูลของ User B ได้ คือระบบตรวจแค่ว่า “เราคือใคร” แต่ลืมตรวจว่า “Object ชิ้นนี้เป็นของเราจริง ๆ ไหม”
   2.2 Broken Authentication (API2:2023) คือกรณีที่เราไม่ได้ล็อกอินเลย แต่กลับเข้าถึงข้อมูลได้โดยที่ไม่ต้องล็อกอินก่อนครับ ปัญหานี้อยู่ที่ Authentication ไม่ใช่ Authorization
3. Broken Object Property Level Authorization (BOPLA) - API3: 2023
   ถือเป็นช่องโหว่ที่รวมสองช่องโหว่เข้าด้วยกัน คือ Excessive Data Exposure และ Mass Assignment ครับ
   3.1 Excessive Data Exposure คือการที่ API ส่งข้อมูลกลับมาเกินความจำเป็น เช่น เลขบัตรประชาชน หรือ รหัสผ่านที่ Hash ไว้ ใน Lab ของเราก็เข้าข่ายช่องโหว่นี้ด้วย เพราะตอนเรียก /api/v2/users ระบบคืนค่า “ssn” ของผู้ใช้กลับมาทั้งที่ไม่มีความจำเป็นต้องเปิดเผยออกมาเลยครับ
   3.2 Mass Assignment คือการที่ API ยอมให้ผู้ใช้งานแก้ไขค่าของ Property (ฟิลด์) ที่ไม่ควรแก้ไขได้โดยการแนบฟิลด์นั้นเข้าไปใน Request ตรง ๆ ยกตัวอย่าง เช่น การส่ง “is_admin”: true เข้าไปตอนแก้ไขข้อมูลโปรไฟล์ หากระบบรับค่านี้ไปตั้งให้จริง ทำให้ผู้ใช้งานทั่วไปสามารถยกระดับสิทธิ์ (Privilege Escalation) ขึ้นไปเป็น Admin ได้ทันที

แนวทางการแก้ไข Shadow API

1. จัดทำ API Inventory ให้ครบและเป็นปัจจุบัน เพราะถือเป็นการแก้ปัญหาที่ต้นเหตุตามหมวด API9:2023 เมื่อเรารู้ว่าเรามี API อะไรทำงานอยู่บ้าง เราถึงจะดูแล ตั้งค่าความปลอดภัย และควบคุมสิทธิ์การเข้าถึงได้ ในทางปฏิบัติควรทำแบบอัตโนมัติและต่อเนื่อง เช่น ดึงรายการ Route ที่ลงทะเบียนจาก Framework ตอน Build เพื่อจับ Endpoint ที่ Code Review อาจมองข้ามครับ
2. บังคับ Authentication และ Authorization ทุก Endpoint ด้วยหลัก Default-Deny ถือเป็นมาตรการที่แก้ปัญหาของ Lab นี้ได้ตรงจุด เพราะ Endpoint แทบทั้งหมดที่เราเรียกใช้งานได้โดยไม่มีการตรวจสอบตัวตนเลย
   วิธีที่ได้ผลคือ การวาง Middleware ไว้ที่ API Gateway ให้ปฏิเสธทุกคำขอบน /api/* เป็นค่าเริ่มต้นก่อน แล้วจึงเปิดสิทธิ์ (Opt-out) เฉพาะ Endpoint ที่จำเป็นจริง ๆ เท่านั้น ข้อดีของแนวทางนี้คือ ต่อให้มี Shadow Endpoint หลุดขึ้น Production ไป ก็จะถูก Block โดยอัตโนมัติครับ เพราะไม่ได้อยู่ใน Allow List ครับ
3. จัดการ Source Map และ Comment ที่หลุดไปกับ Production Build
   จากเทคนิคแรกของเราค้นเจอ Endpoint ลับได้จากการอ่านไฟล์ JavaScript ซึ่งต้องเข้าใจก่อนว่า Endpoint ที่ Frontend เรียกใช้งานจริงนั้นจำเป็นต้องอยู่ในโค้ดฝั่ง Client อยู่แล้ว เราไม่สามารถซ่อนมันได้ทั้งหมด และการพยายามซ่อนก็ไม่ได้เป็นการแก้ที่ต้นเหตุ สิ่งที่ควรโฟกัสจริง ๆ คือการไม่ปล่อยให้ข้อมูลที่ไม่จำเป็นหลุดไปกับ Production Build เช่น ไม่ Deploy ไฟล์ Source Map (.js.map) เพราะเป็นการเปิดให้ผู้โจมตีอ่านโครงสร้างโค้ดต้นฉบับได้ง่ายขึ้น รวมถึงตั้งค่า Build Process ให้ตัด Comment, Debug Code และ TODO Note ออกจากไฟล์ที่ส่งขึ้นระบบจริงครับ

บทส่งท้าย

สำหรับปัญหา Shadow API ไม่ใช่เรื่องของเทคนิคการโจมตีที่ซับซ้อน แต่เป็นผลลัพธ์ของความล้มเหลวในการบริหารจัดการและดูแลโดยตรงครับ

หวังว่าบทความนี้จะเป็นประโยชน์กับผู้อ่านทุกท่านนะครับ แล้วพบกันใหม่ในบทความหน้าครับ

อ้างอิง

OWASP API Security Top 10