สรุป OWASP Top 10 API Risk 2023

สำหรับงานนี้เป็น On-Site อีกงานที่ทาง OWASP Bangkok Chapter / 2600 Thailand / Microsoft Thailand จัดงานร่วมกันครับ และเป็นงานที่ Dev อย่างผมน่าจะฟังเข้าใจด้วยครับ เลยลองมาดู OWASP Top 10 API Risk ซึ่งแชร์โดย คุณ Krischat Thataristorai จาก Secure D Center Co., Ltd. อ้างอิงจาก OWASP API Security Project 2023RC สำหรับที่ผมลองจดๆมาจะมีดังนี้ครับ

API คือ อะไร ?

• API = Application Programming Interface ปกติจะเป็นพวก Method ต่างๆที่เปิดไว้ ปัจจุบันเป็นพวก Web Service ที่เปิด End Point + Path มาแทน ที่นิยมตอนนี้จะเป็น REST API
• REST API เป็น Protocol ที่ On Top Application Layer อย่างตัว HTTP โดยที่ Keyword สำคัญ
  - Request และบอกรูปแบบการทำงานผ่าน HTTP verbs เช่น get post put head delete options patch delete
  - Response ที่ได้จาก Server จะมีสถานะบอก HTTP status codes สรุปสั้นๆ 5 กลุ่ม
  100 information
  200 success
  300 redirection
  400 client error
  500 server error
• REST API พอเรามาใช้ท่านี้กันเยอะ มันเป็น target สำหรับการโจมตีมากขึ้นด้วย

API vulnerabilities

- API1:2023 Broken Object Level Authorization (BOLA)

IDOR vs BOLA

• IDOR (Insecure Direct Object Reference) - แก้ไข resource id เพื่อเข้าไปดูข้อมูลอื่นๆที่ได้ที่ไม่สามารถเข้าถึงตรงๆได้
• BOLA (Broken Object Level Authorization) - IDOR + lack of authorization mechanism มีการโจมตี 2 แบบ
  - แก้ userid - attacker เปลี่ยน userid ที่ได้จาก API และเข้าไปใช้งานแทนจริงๆ เช่น เคส Social App ที่มีช่องให้ attacker เปลี่ยน userid เป็นคนอื่น แล้วเข้าไปใช้งานแทน user คนนั้นๆ เช่น ปิด comment / ตั้ง Profile Private เป็นต้น
  - แก้ objectid

การป้องกัน

• APP ต้องมีการตรวจสิทธิการใช้ API นั้นๆ ก่อนใช้งาน / พวก ID ใช้เลขที่เดายากๆ อย่าง GUID ที่เป็น Random แทน
• ก่อนDeploy กำหนด RBAC / ACL ให้ชัด
• ตรวจสอบพฤติกรรมผิดปกติของ User ต้องใช้พวก Log / SIEM

- API2:2023 Broken User Authentication

เคสนี้ตัว App มันหลุด Flow / By Pass จากการยืนยันตัวตน (Authentication) ตอนนี้ท่าที่ใช้กันจะเป็นแบบ Token หมดแล้ว เพราะว่ามันเป็น Stateless ทำให้สามารถ Scale ได้ง่าย โดยการโจมตีมี 3 ท่า ได้แก่ Classic Authentication Attack / Forging Token / JWT abuse

ตัวอย่างเคส

• MFA - Bypass OTP เคสนี้ทาง Attacker ได้ user/pass + รู้ Mechanism ว่า Login ตรวจที่ Server-Side แต่ OTP ตรวจที่ Client
  ดังนั้น Attacker ใช้ burp suite ปลอม http response และ Bypass OTP
• JWT none algorithm - ปัญหาที่ 3rd Library ยอมให้ส่ง JWT ไม่ sign อะไรเลย (none algorithm) ใน header เลยทำให้ปลอม data อะไรเข้ามาก็ได้ ทั้งๆที่ใน App กำหนด algorithm ที่ใช้แล้วนะ
• JWT Crack Attack กำหนด well known secret key ที่ง่ายไป อาจจะอยู่ใน word list

การป้องกัน

• พวก JWT บางครั้งพวก vulnerabilities มาจากตัว 3rd Library ดังนั้นตรวจสอบจาก CI/CD ที่มี Tools บางตัวเช่น Sonar มันสามารถแจ้งเตือนได้ว่า 3rd Library มันมีช่องโหว่ ต้องขยับขึ้นมาตามด่วน เป็นต้น
• ตั้ง secret key คาดเดาได้ยากขึ้น + ใช้ asymmetric algo
• ตรวจสอบจาก server-side check เพิ่มเติม เคสของ OTP

- API3:2023 Broken Object Property Level Authorization (BOPLA)

Excessive Data Exposure - Response ส่งข้อมูลมาเกินความจำเป็น ต้องดู domain ของระบบนั้นๆ เช่น view user แต่ระบบดันข้อมูล user ที่ approve หรือ logout ออกไปแล้ว แต่ api ยังมี jwt token มาด้วย

Mass Assignment - API มี parameter ใน request มากไป อย่างเช่น ตอนสร้าง user มันดัน return privilege มาด้วย Attacker อาจจะลอง Create User แต่เพิ่ม Field Privilege เป็น admin เข้าไปใน Request ด้วย จากนั้นลองส่ง Request เข้าไปทดสอบ ถ้าได้จะสร้าง Super User สำเร็จ และโจมตีอื่นๆต่อ

การป้องกัน

• Excessive Data Exposure ให้ Server Return Field เท่าที่จำเป็น ดูจาก Domain + Business
  //ตอนนี้เหมือนจะมีบาง API ที่ผ่านตามมาทั้ง Model + Child ตอนนี้ 555
• Mass Assignment ทำ whitelist ว่า field ไหนควรแก้ได้ ไม่ได้

- API4:2023 Unrestricted Resource Consumption

ระบบไม่ได้กำหนด Limit ของการใช้ API ในมุมต่างๆ เช่น

• การยิง request เช่น
  - otp ใช้ได้ 5 นาที แต่ทว่าระบบจริงดันให้ request ได้รัวๆ
  - API Authentication ยอมให้ยิงได้รัวๆ ทำให้ Attacker จะเอาไป brute force หาข้อมูลบางอย่างได้ จาก Data breach ที่หลุดออกมา
• หรือ file size limit - ไม่ได้ตรวจสอบขนาดไฟล์ + การจัดเก็บไฟล์ Attacker เลยให้วิธี Upload ไฟล์ใหญ่ Dump เข้าไป จน server ประมวลผลไม่ทัน
• พอมันโดนมากๆ จะเกิด Denial of Service

การป้องกัน - กำหนด Limit แต่ละ API เช่น

• Login/Logout Mechanism กำหนด Limit pass ผิดกี่ครั้งให้หน่วง
• Rate Limit / Size Limit หรือ Limit อื่นๆ ตามหน้าที่ของ API นั้นๆ ลองดู คุมจาก Server Side นะ พวก OTP อาจจะดัก per device ด้วย
  เหมือนลองดูเพิ่มพวก Spring / .NET มีพวก Rate Limit ในตัวด้วย ตอนแรกคิดว่าต้องทำจาก API Gateway อย่างเดียว
  - Spring https://www.baeldung.com/spring-bucket4j
  - .Net Rate limiting middleware in ASP.NET Core | Microsoft Learn

- API5:2023 Broken Function Level Authorization (BFLA)

BOLA vs BFLA

• BOLA - ใช้สิทธิ user คนอื่นๆที่ level ด้วยกัน ในการโจมตี
• BFLA - user ใช้สิทธินอกเหนือจากที่ได้สิทธิรับมาก เช่น user 》 admin ได้ หรือ
  - หน้าจอไม่มีปุ่ม delete แต่ลองส่ง request delete ข้อมูล ได้ซะงั้น
  - Attacker ลองให้ delete ข้อมูล แต่ระบบแต้งว่าต้องเป็น admin ทาง Attacker ลองแก้ API จาก /user มาเป็น /admin ถ้า API ไม่มีการตรวจสอบที่ดีตัว Attacker ใช้สิทธิ Admin ทำอย่างอื่นได้

การป้องกัน - เหมือนกับ API1:2023 Broken Object Level Authorization (BOLA)

- API6:2023 Server-Side Request Forgery

Attacker ใช้ parameter เพื่อเข้าถึง resource ของ server ได้ เช่นลอง list path ของ server นั้นๆ เพื่อมาใช้วางแผนโจมตีต่อไป เช่นทำ remote code execution เป็นต้น

การป้องกัน

• APP นอกจาก Validate ที่ Client แล้ว ให้ทำที่ Server ด้วย การตรวจสอบ User Input หรือทำ sanitize ก่อนนำไปใช้ต่อ
• disable http redirection

- API7:2023 Security Misconfiguration

กำหนด Config ฝั่ง Server ที่ไม่ดีพอ ทำให้ตอน Error + Stack Trace ทำให้เห็น Tech Stack ที่ใช้งาน เช่น รู้ว่าใช้ MySQL Database Version อะไร หรือบอก Internal Path ของ Server จน Attacker นำข้อมูลนั้นไปวางแผนโจมตีต่อได้ ตัวอย่าง

• Laravel ที่ดันแสดง user pass ของ db-server ที่กำหนดไว้
• Attacker สามารถทำ CORS แล้วเอาข้อมูลไปส่งให้ Domain ใดก็ได้

การป้องกัน

• CORS Policy บอก Whitelist ที่ server นั้นๆ ต่อได้
• APP
  - กำหนด http verb ที่ใช้ได้
  - กรณีที่ Error ให้ API Response ข้อมูลเท่าที่จำเป็น ไม่ต้องเอา Exception + Stack Trace ออกมาหมด
• ใช้ Protocol ที่ Encrypt และปลอดภัย (TLS) ทั้ง Server + APP

- API8:2023 Lack of Protection from automated threats

อันนี้คล้ายกับเคส rate limit โดย Attacker เจอ API ที่สามารถมาใช้ประโยชน์ได้ + ทำ Automate เร็วกว่า Business ปกติได้
ตัวอย่าง Attacker เอา API จองซื้อของช่วง Flash Sale มาใช้ประโยชน์ เช่น ของ PS5 โดยยิง API นั้นตรงๆเลย ทำให้เกิดความเสียหาย และก่อความไม่พอใช้กับลูกค้าคนอื่นๆ

การป้องกัน

• implement captcha ตรวจฝั่ง server-side
• กำหนดหน่วงระยะเวลา หรือ Quata ของ API นั้นๆ (อาจจะต้องคุยกับ Business ให้ Clear ด้วย)

- API9:2023 Improper Assets Management

• Outdated API ที่ยังใช้งานได้อยู่ และไม่ได้ patch security มีความเสี่ยงในเรื่องนี้ โดย Attacker จะไปหาตัว Outdated API ดูจาก documentation ของระบบนั้นเอง
  ตัวอย่าง API v1/v2 ตัว v2 แก้ Security แล้ว แต่ยังเปิด v1 ที่มีช่องโหว่ให้ใช้งานอยู่ ทำให้ Attacker เอามาใช้โจมตีได้
• หรือ API ของ Dev ที่ยังทำไม่เสร็จ / API ตัว management, tools
  ตัวอย่างเคส เช่น GraphQL ที่มีตัว Explorer ให้ Dev เข้ามาลอง Query ข้อมูล ดู Data Model ได้ หรือเข้ามาแก้ไขได้ และ Attacker เข้ามาได้ด้วยเหมือนกัน
  //อ้าว h2 ของ spring บางระบบเหมือนจะเห็นเปิด แยยเดียวกับเคส GraphQL เลย 555

การป้องกัน

• ปิด API เก่า
• ทำ ACL
• ปรับ documentation ให้ล่าสุด

- API10:2023 Unsafe Consumption of APIs

ไม่ได้ตรวจสอบ Request มาจาก API ด้วยกันเอง ทำให้เกิดปัญหาอื่นๆได้ เช่น SQL Injection / API6:2023 Server-Side Request Forgery เป็นต้น

การป้องกัน

• ตรวจสอบ Input ที่มาจาก API อื่นๆ เหมือนที่ได้จาก User เช่น การ Validate / Sanitize ก่อนนำไปใช้ต่อ
• สื่อสารบน Protocol ที่ปลอดภัย TLS

งานรัฐเริ่มมีการให้ตรวจ OWASP Top10 ใน TOR แล้ว และได้เจอคุณซาร่าจาก Thai Cy Sec ด้วยครับ แต่งานนี้ผมรีบชิ่งกลับก่อน เลยไม่ได้คุยกับหลายคนเลย รีบกลับไปให้ข้าวแมวครับ อิอิ

Blog ของท่านอื่นๆ

• สรุปงาน OWASP x 2600 Thailand x Microsoft Security Community Thailand แบบเด็กน้อยหลังห้องหัวไม่ค่อยไวเท่าไรค่ะ by Thai Cy Sec

Reference

• OWASP Bangkok Chapter และ 2600Thailand Monthly Meeting หัวข้อ: OWASP Top 10 API Risk
• OWASP API Security Project 2023RC | OWASP Foundation
• OWASP API Security Project | OWASP Foundation
• OWASP API Security Top 10