OWASP 2021 อันดับ 1: Broken Access Control
Broken Access Control เป็นช่องโหว่ที่เกิดจากการกำหนดสิทธิ์ของผู้ใช้ (Permission) ที่ผิดพลาด ทำให้ผู้ใช้ที่ไม่ได้รับอนุญาต (Unauthorized User) สามารถเข้าถึงข้อมูลหรือฟังก์ชันที่ไม่ควรเข้าถึงได้ การทำงานของช่องโหว่นี้มักเกิดจากการที่ระบบไม่มีการตรวจสอบสิทธิ์อย่างเข้มงวด เช่น การให้สิทธิ์กับผู้ใช้มากเกินไป จนสามารถเจาะเข้าทั้งระบบได้ หรือผู้ใช้สามารถใช้สิทธิ์ของคนอื่นที่มีสิทธิ์มากกว่าได้
(Source: https://gemini.google.com/)
ช่องโหว่นี้แบ่งออกเป็นสองประเภทหลัก คือ Insecure Direct Object Reference (IDOR) ที่เป็นปัญหาการพยายามข้ามสิทธิ์ไปยังข้อมูลของคนอื่น และ Function Level Access Control ที่เป็นปัญหาการพยายามยกระดับสิทธิ์ให้สูงขึ้น อันตรายของช่องโหว่นี้รวมถึง:
- การเข้าถึงไฟล์ข้อมูลลูกค้า เช่น บัตรเครดิตที่เก็บใน Web Server
- การเข้าถึงไฟล์ข้อมูลในลักษณะ Directory Browsing โดยเห็นไฟล์ทั้งหมดใน server
- การแก้ไขข้อมูลของผู้ใช้คนอื่นในระบบได้ด้วยการแก้ไข URL เพียงเล็กน้อย
- ปัญหา Path Traversal ที่ผู้โจมตีสามารถสุ่มพิมพ์ path หรือ sub directory ในช่อง URL
- การเข้าถึงข้อมูลจาก cache ที่ค้างอยู่ฝั่ง client โดยไม่ต้อง Login เข้าระบบ
แฮกเกอร์ใช้ประโยชน์จากช่องโหว่นี้ได้อย่างไร?
ผู้โจมตีมีหลายวิธีในการเจาะระบบผ่านการควบคุมการเข้าถึงที่หละหลวม โดยอาศัยเทคนิคต่างๆ ดังนี้:
- การยกระดับสิทธิ์ (Privilege Escalation):
- แนวตั้ง (Vertical): คือการที่ผู้ใช้ทั่วไปสามารถเข้าถึงฟังก์ชันของผู้ดูแลระบบได้ เช่น ผู้ใช้ธรรมดาค้นพบ URL ของหน้าแอดมิน (/admin) และระบบไม่ได้ตรวจสอบสิทธิ์ ทำให้สามารถเข้าไปจัดการข้อมูลหรือลบบัญชีผู้ใช้อื่นได้
- แนวนอน (Horizontal): คือการที่ผู้ใช้สามารถเข้าถึงข้อมูลของผู้ใช้คนอื่นในระดับเดียวกันได้ ตัวอย่างคลาสสิกคือการเปลี่ยน ID ใน URL เช่น จาก myaccount?id=123 เป็น myaccount?id=456 แล้วระบบแสดงข้อมูลของบัญชีอื่นโดยไม่ตรวจสอบความเป็นเจ้าของ
- การจัดการคำขอ (Request Manipulation): แฮกเกอร์อาจแก้ไขพารามิเตอร์ที่ส่งไปยังเซิร์ฟเวอร์ เช่น เปลี่ยนค่าในฟอร์มที่ซ่อนอยู่, คุกกี้, หรือ URL เพื่อหลอกให้ระบบมอบสิทธิ์ที่สูงกว่าให้
- การคาดเดา URL ที่ไม่ปลอดภัย: นักพัฒนามักคิดว่าการใช้ URL ที่ซับซ้อน (/admin-secret-panel-xyz) จะปลอดภัย แต่แฮกเกอร์สามารถค้นพบ URL เหล่านี้ได้จากไฟล์ JavaScript, การดักจับทราฟฟิก หรือใช้เครื่องมือเดาสุ่ม
ลักษณะของการเกิด Broken Access Control
- ไม่มีการตรวจสอบสิทธิ์อย่างเพียงพอ
- ผู้ใช้งานสามารถเข้าถึง URL, API, หรือไฟล์ที่ไม่ได้รับอนุญาตเพียงเพราะรู้ตำแหน่งของทรัพยากร (เช่น การเปลี่ยนค่าพารามิเตอร์ใน URL)
- ใช้การอ้างอิงถึงข้อมูล/ไฟล์โดยตรงที่ไม่ผ่านการตรวจสอบสิทธิ์ (Insecure Direct Object References – IDOR) เช่น ผู้ใช้สามารถเปลี่ยน user_id=1001 เป็น user_id=1002 เพื่อเข้าถึงข้อมูลบัญชีของผู้อื่นได้
- มีการตั้งค่า Permission ที่กว้างเกินไป เช่น ผู้ใช้ระดับปกติสามารถเข้าถึงหน้าจัดการระบบ (Admin Panel) ได้
- ขาดการบังคับใช้การตรวจสอบสิทธิ์ในฝั่งเซิร์ฟเวอร์ ระบบอาจพึ่งพาเพียงฝั่ง Client (JavaScript หรือ Cookie) โดยไม่ตรวจสอบซ้ำในฝั่ง Server
(Source: https://gemini.google.com/)
ผลกระทบที่เกิดขึ้น
- ข้อมูลรั่วไหล (Data Breach): ข้อมูลส่วนบุคคลหรือข้อมูลเชิงธุรกิจถูกเปิดเผย
- การเปลี่ยนแปลงสิทธิ์ผู้ใช้: ผู้โจมตีสามารถอัปเกรดสิทธิ์ของตนเอง
- การยึดระบบ: หากเข้าถึงฟังก์ชันของผู้ดูแลระบบ อาจนำไปสู่การถูกควบคุมทั้งระบบ
- ความเสียหายด้านชื่อเสียงและกฎหมาย: โดยเฉพาะเมื่อข้อมูลส่วนบุคคลรั่วไหล (PDPA, GDPR)
กรณีศึกษาจากบริษัทยักษ์ใหญ่
หากคิดว่าปัญหานี้เป็นเรื่องไกลตัว ลองดูเหตุการณ์ที่เคยเกิดขึ้นจริงกับบริษัทเทคโนโลยีชั้นนำ:
- Facebook (2013): ช่องโหว่ที่ทำให้นักวิจัยความปลอดภัยสามารถลบรูปภาพออกจากบัญชีของผู้ใช้คนใดก็ได้โดยไม่ต้องขออนุญาต
- Instagram (2019): ช่องโหว่ประเภท IDOR (Insecure Direct Object Reference) ทำให้แฮกเกอร์สามารถดูโพสต์และสตอรี่ส่วนตัวของผู้อื่นได้ เพียงแค่เปลี่ยน User ID ในคำขอ API
- GitHub (2022): บั๊กที่อนุญาตให้ผู้ใช้ยกระดับสิทธิ์ของตนเองให้สูงขึ้นภายใน Repository โดยไม่ได้รับอนุญาต
- Optus (2023): ผู้ให้บริการโทรคมนาคมรายใหญ่ของออสเตรเลียถูกแฮกข้อมูลลูกค้าเกือบ 10 ล้านราย ผ่านช่องโหว่ IDOR ที่เปิดให้เข้าถึงข้อมูลได้โดยตรง
การป้องกันช่องโหว่
การป้องกัน Broken Access Control ต้องอาศัยการใช้หลักการ Deny by Default และการตรวจสอบสิทธิ์อย่างเข้มงวดในทุกขั้นตอน โดยระบบควรปฏิเสธการเข้าถึงทั้งหมดเป็นค่าเริ่มต้น และอนุญาตเฉพาะการเข้าถึงที่ได้รับการระบุอย่างชัดเจน นอกจากนี้ควรใช้ Centralized Access Control ที่จัดการสิทธิ์การเข้าถึงจากจุดเดียว แทนการกระจายการตรวจสอบสิทธิ์ไปยังหลายจุดในโค้ด ซึ่งอาจทำให้เกิดช่องโหว่จากการพลาดตรวจสอบ
มาตรการป้องกันเฉพาะที่มีประสิทธิภาพรวมถึงการใช้ Secure Coding Practices เช่น การหลีกเลี่ยงการเปิดเผย ID ที่ผู้ใช้สามารถคาดเดาได้ โดยใช้ UUID หรือ Token แทน Sequential ID การจำกัดอัตราการเรียกใช้ API (Rate Limiting) เพื่อป้องกันการโจมตีแบบอัตโนมัติ และการบันทึก Log การเข้าถึงที่ผิดปกติเพื่อตรวจจับการโจมตีได้อย่างรวดเร็ว การตั้งค่า CORS อย่างถูกต้องโดยระบุเฉพาะ origin ที่เชื่อถือได้ และการใช้ Content Security Policy (CSP) เพื่อลดความเสี่ยงจากการโจมตี Cross-site scripting ที่อาจนำไปสู่การหลีกเลี่ยงการควบคุมการเข้าถึงข้อมูล
แหล่งข้อมูลอ้างอิงบทความ
https://www.invicti.com/blog/web-security/broken-access-control/
https://dritestudio.co.th/article/how-broken-access-control-made
https://itsgno.github.io/BrokenAccessControl/
https://dsdi.msu.ac.th/?article=network&fn=week-14
https://www.youtube.com/watch?v=oYMCLLlUDvw