OWASP API Security Top 10 2023

หลังจาก Publish เอกสารออกมาล่าสุดเราก็ได้เห็นภาพรวมของความเสี่ยงต่างๆที่เกิดขึ้นเฉพาะในฝั่งของ API ซึ่งจะแบ่งออกเป็น 10 หัวข้อดังนี้

API-01 Broken Object Level Authorization(BOLA)

Broken Object Level Authorization(BOLA) เป็นปัญหาของการส่ง input ที่สามารถ

• Predictable คาดเดาได้ เช่น เลขที่เป็น running number(auto increment ใน database)
• Discoverable ค้นหาได้ เข่น เบอร์โทรศัพท์ หรือ e-mail address

ดังนั้นปัญหานี้จะต้องแก้ 2 ส่วนด้วยกัน คือ

1. หลีกเลี่ยงการใช้ input ที่สามารถคาดเดาได้และค้นหาได้
2. ต้องเช็คสิทธิ(Permission) ก่อนเข้าใช้งาน service นั้นๆเสมอ โดยเฉพาะ สิทธิของ owner ที่เฉพาะเจ้าของเท่านั้นที่ทำได้ เช่น เราจะลบ post ได้ก็ต่อเมื่อเราเป็นเจ้าของ post

API-02 Broken Authentication

Authentication ถือว่าเป็นประตูทางเข้าสู่ระบบของเราดังนั้นถ้าเรามีประตูที่แข็งแรง ระบบของเราก็จะแข็งแรงตามไปด้วย และจุดที่มีความสำคัญมากๆของ Authentication คือการยืนยันตัวตน(Identity) สุดท้ายเมื่อคุณ Authentication ผ่านแล้วต้องสามารถยืนยันตัวตนของผู้ใช้งานได้

ในปัจจุบันการทำ Authentication ถือว่าเป็น 1 รูปแบบของ E-signature(ลายเซ็นอิเลคทรอนิกส์) เช่นถ้าเรา Login ผ่าน line ถือว่าเราได้ลงลายเซ็นต์ไว้ในทุกๆ message ที่เราพิมพิ์ ไม่ว่าเราจะทำการยืมเงินใคร ก็จะเปรียบเสมือนเราลงลายเซ็นในสัญญาการกู้ยืมเงินทันที นั่นคือสาเหตุว่าทำไม Authentication นั้นจึงเป็นส่วนที่สำคัญมากๆใน Web application

API-03 Broken Object Property Level Authorization

ปัญหานี้ประกอบไปด้วย 2 ปัญหาใน OWASP API Security Top 10 2019 คือ

1. Excessive Data Exposure คือปัญหาของ API ที่ return Response ออกไปเกินกว่าที่จะเอาไปใช้งาน(ไม่ได้นำทุก field ไปแสดงผล) และ field ที่ไม่ได้นำไปแสดงผลนั้นดันเป็น sensitive data เช่น password hashing, access token หรือ role ของ user

   ปัญหานี้เกิดบน REST API เยอะมากเพราะเป็นธรรมชาติของ REST

2. Mass Assignment ปัญหาของ Mass assignment คือการส่ง request เข้ามาโดยที่เราไม่ได้ตั้งใจ เช่นหน้า register จากหน้าบ้าน เราจะกำหนดให้ user ที่สมัครเข้ามาเป็น guest ที่มีสิทธิต่ำสุด(ค่า default) แต่ attacker อาจดัก request แล้วแก้ไข request โดยเพิ่ม role เป็น admin เข้ามา เค้าจะสามารถสมัครสมาชิกเข้ามาโดยที่มีสิทธิเป็น admin ได้จากหน้าบ้าน

OWASP เปลี่ยนชื่อเป็น Broken Object Property Level Authorization เพราะทั้ง 2 ปัญหานี้เกิดจากการ read และ write JSON เหมือนกัน

• Excessive data exposure เป็นการ read data จาก response ที่ return ออกมาเยอะเกิน
• Mass assignment ก็เป็นปัญหาที่เกิดจากการเพิ่ม(write) field ที่เราต้องการเข้าไปใน request

API-04 Unrestricted Resource and Consumption

ปัญหานี้เป็นการเปลี่ยนชื่อจาก Lack of Resource and Rate Limiting ซึ่งอยู่อันดับที่ 4 ในปี 2019 ซึ่งยังคงไว้ซึ่งเนื้อหาเดิมแต่ขยายความให้กว้างขึ้นดังนี้

Lack of Resource and Rate Limiting คือปัญหาของการไม่ได้จำกัดการใช้งาน resource(CPU และ memory) ซึ่งในยุดของ container นั้นง่ายมากๆ ทุกครั้งที่เรา run container ขึ้นมาเราสามารถกำหนด limit ของ cpu และ memory ที่จะใช้งานได้เลย และอีกส่วนหนึ่งคือ Rate Limiting ปริมาณของ request ที่เข้ามาใน 1 ช่วงเวลา เช่น 10 requests ใน 1 นาที หรือ 3 requests ภายใน 1 วินาที เป็นต้น

ซึ่งถ้าเราดุจากชื่อเดิมแล้วจะเห็นว่าจริงๆแล้วจากการกำหนด limit ของ resource และการกำหนด rate limiting แล้วยังมีอีกหลายเรื่องที่คุณต้องกำหนดเพิ่ม เช่น request size(ขนาดของ request ที่ใหญ่ที่าสุดที่สามารถส่งเข้าได้) หรือการควบคุม input ที่ส่งเข้ามาเช่นหน้าที่ส่ง limit เข้ามา ซึ่งตัวแปรนี้เราสามารถแก้ไขค่าเป็นเท่าไหร่ก็ได้ ดังนั้นต้องกำหนดค่าสูงสุดไว้ เช่น ถ้าส่ง limit มาเกิน 100 ให้ set ค่า limit กลับมาเป็น 100 ดังนั้นเราจะเห็นว่าพอเปลี่ยนชื่อเป็น Unrestricted Resource and Consumption ก็จะทำให้ครอบคลุมปัญหาที่กว้างขึ้นทันที

API-05 Broken Function Level Authorization

ปัญหา Broken Function Level Authorization(BFLA) เป็นอีกหนึ่งปัญหาที่เกี่ยวข้องกับการทำ Access Control เหมือนกับ Broken Object Level Authorization(BOLA) ในอันดับที่ 1 แต่ BFLA จะเป็นคนละมิติกับ BOLA โดยที่ BOLA จะเปลี่ยน input เพื่อเข้าถึงสิทธิของคนอื่น แต่ BFLA จะเป็นการเปลี่ยน request หรือ URL เพื่อเข้าถึง service ที่เค้าไม่มีสิทธิ เช่นเปลี่ยน method จาก GET ไปเป็น PUT เพื่อแก้ไขข้อมูลที่เค้าไม่มีสิทธิเข้าถึง หรือพยายามเข้าถึง path ที่เป็นของ admin

API-06 Unrestricted Access to Sensitive Business Flow

ในปัจจุบันการใช้งาน third party ที่มีค่าใช้จ่ายตามปริมาณการใช้งาน เช่น SMS, Notification Services ต่างๆ หรือ การใช้ Function as a Service(FaaS)

ปัญหานี้จะเกิดจากการที่เรามี API ที่คิดค่าใช้จ่ายตามปริมาณการใช้แต่เราไม่ได้ limit การใช้งาน เพราะ request ที่ส่งเข้ามาอาจเป็นการโจมตีจาก attacker ก็ได้ ดังนั้นเราต้องป้องกันโดยการกำหนดความถี่ของการใช้งาน ซึ่ง Rate Limiting อาจไม่เพียงพอต่อการป้องกัน เพราะมันเป็นเรื่องของเงินเราจะปล่อยให้มี traffic เข้ามาเยอะมากไม่ได้

และในข้อนี้ได้รวมเอา Insufficience Logging and Monitoring เข้ามาด้วยดังนั้นในข้อนี้ต้องมีการเก็บ Log ในทุกๆ Layer และมีการ Monitor การทำงานของ API เสมอเมื่อมีความผิดปกติต้องมีการ response อัตโนมัติหรือส่ง alert ไปยัง Incident response team(ผู้ที่คอยตรวจจับและรับมือกับผู้บุกรุก) ทันที

API-07 Server Side Request Forgery(SSRF)

ปัญหานี้ถือได้ว่าเป็นน้องใหม่ล่าสุดทั้งใน OWASP Top 10 และ OWASP API Security Top 10 SSRF เป็นปัญหาที่เกิดจากการ Call service ต่อเนื่องกันไปเรื่อยๆ เช่น ถ้าเราส่งคำสั่งซื้อสินค้าผ่านทาง API สิ่งที่เกิดขึ้นคือจะมี request ส่งไปที่

1. API Gateway เพื่อคัดกรองผู้ที่มีสิทธใช้บริการ
2. Order service เพื่อบันทึกคำสั่งซื้อ และส่งต่อไปยัง payment service
3. Payment Service ทำหน้าที่ตัดเงินออกจากบัญชีของลูกค้า

ดังนั้นเมื่อการทำงานของระบบจะเป็นการส่ง request ต่อไปเรื่อยๆแบบนี้ โดยเฉพาะใน Microservices Atchitecture ก็จะทำให้การโจมตี service ที่อยู่หลังบ้านโดยการส่ง request ต่อกันไปเรื่อยๆ เช่นถ้าเราต้องการโจมตี payment service เราต้องส่ง malicious request(request ที่มีอันตราย) ผ่านไปยัง api gateway และ order service

API-08 Security Misconfiguration

Security Misconfiguration หมายถึง การปรับ Configuration ที่ผิดพลาดทุกๆจุดตั้งแต่ Configuration ของ database, Configuration ของ Framework รวมไปจนถึง Configuration บน Operating system ซึ่งในปัจจุบันเราก็จะรวมถึงการเขียน Dockerfile และการปรับ Config ของ service ต่างๆบน cloudด้วย

ส่วนใหญ่ปัญหาของการ Configuration คือเราไม่ได้ปิด service ที่ไม่ได้ใช้ และการกำหนด Permission ให้เกินกว่าที่จะใช้งาน

API-09 Inventory Improper Management

การทำงานกับ API นั้นเราจะต้องบริหารจัดการ Inventory(บางทีเราก็จะเรียกว่า Assets) ซึ่งจะมองใน 2 มิติดังนี้

• Stage ของ API ก่อน API ของเราจะขึ้น Production ได้มันจำเป็นต้องผ่าน Staging หรือ Pre-Production ก่อน
• Version การใช้งาน API ส่วนใหญ่ดเราจะต้องมี version กำกับข้อนี้ถือว่าเป็น best practices สาเหตุที่ต้องมี version เนื่องจากเราต้องออกแบบ API ให้รองรับการใช้งานผ่าน Mobile ที่เราไม่สามารถกำหนดให้ user upgrade ได้ ซึ่งถ้าเราอยาก update api โดยที่ไม่กระทบกับผู้ใช้งาน mobile version เก่าเราก็จะแยก API ออกเป็นหลายๆ version

ดังนั้น API 1 service จะมีหลาย Stages และหลาย Version ดังนั้นการดูแลรักษาความปลอดภัยของระบบเราต้องดูแล API ทุกๆ Stages และทุกๆ Version ให้มีความปลอดภัย

API-10 Unsafe Consumption of APIs

ข้อนี้มากจาก Injection ในปี 2019 ซึ่งในข้อนี้จะรวบรวมปัญหาของการส่ง input ที่เป็น malicious input เข้ามาใน API ทั่้งหมด โดยจะเน้นที่ Injection เป็นหลัก

Injection คือปัญหาที่เกิดจากหารนำตัวแปรไปต่อกับ String แล้วนำ String นั้นไป query หรือ ไป execution โดยที่ไม่ได้ validate ให้ดี ส่วนใหญ่จะใช้การปิดข้อความเดิมและใส่ข้อความใหม่เข้ามาเพิ่ม

ปํญหา Injection นั้นไม่ได้มีแค่ SQL Injection เท่านั้นแต่ยังมี

• NoSQL Injection
• Command Injection
• Script Injection
• LDAP Injection
• XPath Injection

และปัญหานี้ยังได้รวมเอา Cross-Site Scripting(XSS) เข้ามาใน นี้ด้วยเพราะถึงแม้การทำ Cross-Site Scripting(XSS) จะไม่สามารถโจมตีได้เพราะ API ไม่ได้ execute javascript แต่เราสามารถฝัง script สำหรับการโจมตีไว้ใน database เพื่อรอให้ frontend ที่เป็น web ดึงไป execute ได้

Injection อยู่ในอันดับที่ 8 ใน OWASP API Security Top 10 ปี 2019

จาก OWASP API Security TOP 10 2019 สู่ 2023

อ่านต่อเพิ่มเติม

• OWASP Top 10 2021
• https://apisecurity.io/owasp-api-security-top-10/