เจาะลึก IDOR: ช่องโหว่ร้ายที่แอปพลิเคชันส่วนใหญ่อาจมองข้าม
โลกดิจิทัลทุกวันนี้ เราต่างใช้แอปพลิเคชันและเว็บไซต์มากมายเพื่อจัดการข้อมูลส่วนตัว ซื้อของ ทำธุรกรรม หรือแม้แต่ติดต่อสื่อสารกัน แต่เคยสงสัยหรือไม่ว่าข้อมูลเหล่านั้นปลอดภัยแค่ไหน เมื่อไหร่ที่เราเผลอเข้าไปดูข้อมูลของคนอื่น หรือคนอื่นเผลอเข้ามาดูข้อมูลของเราได้ง่ายๆ โดยไม่รู้ตัว นี่แหละคือภัยเงียบที่เรียกว่า IDOR หรือ Insecure Direct Object References
นี่ไม่ใช่เรื่องไกลตัวเลย เพราะมันเป็นหนึ่งในช่องโหว่ด้านความปลอดภัยที่พบบ่อย และมักถูกโจมตีได้ง่ายกว่าที่คิด
IDOR คืออะไรกันแน่
IDOR ย่อมาจาก Insecure Direct Object References อธิบายง่ายๆ คือมันคือช่องโหว่ที่เกิดขึ้นเมื่อระบบเว็บไซต์หรือแอปพลิเคชัน อ้างอิงถึงวัตถุ (Object) ใดๆ โดยตรง เช่น ไฟล์, บัญชีผู้ใช้, รายการคำสั่งซื้อ หรือข้อมูลอื่นๆ โดยไม่ได้มีการ ตรวจสอบสิทธิ์การเข้าถึงอย่างเหมาะสม ของผู้ใช้งานที่กำลังร้องขอข้อมูลนั้น
ลองนึกภาพว่าเว็บที่เราใช้งานอยู่ใช้ตัวเลขเรียงกันเป็น ID ใน URL เช่น website.com/user?id=123 หากเป็นระบบที่มีช่องโหว่ ผู้ใช้งานอาจจะลองเปลี่ยน id=123 เป็น id=124 หรือ id=125 ก็จะสามารถเข้าถึงข้อมูลของคนอื่นได้ทันที หากระบบไม่มีการตรวจสอบเพิ่มเติมว่าผู้ใช้งานปัจจุบันมีสิทธิ์ดูข้อมูลของ ID นั้นๆ หรือไม่
ช่องโหว่นี้เกิดขึ้นได้อย่างไร
สาเหตุหลักๆ ของ IDOR มาจากการที่นักพัฒนาซอฟต์แวร์ มองข้ามการตรวจสอบสิทธิ์ ในฝั่งเซิร์ฟเวอร์ (Server-Side)
หลายครั้ง ระบบจะส่งพารามิเตอร์ที่เป็นรหัสอ้างอิงโดยตรงมากับ URL หรือในข้อมูลที่ส่งไปมาระหว่างเบราว์เซอร์กับเซิร์ฟเวอร์ โดยคิดว่ารหัสเหล่านี้จะถูกส่งมาอย่างปลอดภัย หรือคิดว่าไม่มีใครพยายามเปลี่ยนมัน
ตัวอย่างที่พบได้บ่อยคือการใช้ รหัสตัวเลขเรียงกัน หรือรหัสที่คาดเดาได้ง่าย เช่น order_id=1, invoice_id=2, document_id=3 หากไม่มีการยืนยันว่าผู้ใช้งานที่ร้องขอ document_id=3 เป็นเจ้าของเอกสารนั้นจริงๆ ก็จะเกิดปัญหาทันที
นี่รวมถึงการใช้ชื่อไฟล์ตรงๆ ใน URL เช่น example.com/download?file=report.pdf ที่ผู้ไม่หวังดีอาจเปลี่ยนเป็น file=confidential_data.zip เพื่อดาวน์โหลดไฟล์สำคัญได้
ผลกระทบที่ไม่น่ารัก
ผลกระทบจากช่องโหว่ IDOR นั้นกว้างขวางและน่ากังวล
สิ่งแรกคือ การเข้าถึงข้อมูลส่วนบุคคล ของผู้อื่นได้โดยไม่ได้รับอนุญาต ไม่ว่าจะเป็นชื่อ ที่อยู่ เบอร์โทรศัพท์ หรือแม้กระทั่งข้อมูลทางการเงิน
นอกจากนี้ ยังอาจนำไปสู่การ แก้ไขข้อมูล เช่น เปลี่ยนสถานะคำสั่งซื้อ เปลี่ยนโปรไฟล์ผู้ใช้งาน หรือแม้แต่ลบข้อมูลสำคัญของคนอื่น
ในบางกรณี IDOR อาจถูกใช้เพื่อ ยกระดับสิทธิ์การเข้าถึง (Privilege Escalation) ทำให้ผู้โจมตีเข้าถึงฟังก์ชันการทำงานที่สงวนไว้สำหรับผู้ดูแลระบบได้เลยทีเดียว
ป้องกันง่ายๆ แต่ต้องใส่ใจ
การป้องกัน IDOR ไม่ได้ซับซ้อน แต่ต้องอาศัยความเข้าใจและการใส่ใจในการพัฒนา
สิ่งสำคัญที่สุดคือการ ตรวจสอบสิทธิ์การเข้าถึง ในฝั่งเซิร์ฟเวอร์เสมอ ไม่ว่าจะมีการส่งข้อมูล ID มาด้วยวิธีใดก็ตาม ทุกครั้งที่มีการเรียกใช้ข้อมูลหรือวัตถุใดๆ ระบบจะต้องยืนยันว่าผู้ใช้งานปัจจุบันมีสิทธิ์ในการเข้าถึงวัตถุนั้นๆ จริงๆ
ควรใช้ รหัสอ้างอิงที่ไม่สามารถคาดเดาได้ (Non-guessable references) เช่น UUIDs (Universally Unique Identifiers) แทนการใช้ตัวเลขเรียงกัน เพื่อทำให้การสุ่มเดาหรือการเปลี่ยน ID ทำได้ยากขึ้นมาก
อีกแนวทางหนึ่งคือการ ใช้รหัสที่ไม่ใช่โดยตรง (Indirect references) เช่น ระบบอาจจะสร้างรหัสชั่วคราวที่ไม่ซ้ำกันสำหรับแต่ละเซสชันของผู้ใช้งาน เพื่ออ้างอิงถึงวัตถุจริงในฐานข้อมูล โดยที่ผู้ใช้งานภายนอกไม่สามารถมองเห็นหรือเดารหัสวัตถุจริงได้
การเข้าใจและจัดการกับช่องโหว่ IDOR เป็นสิ่งจำเป็นอย่างยิ่งในการสร้างแอปพลิเคชันที่ปลอดภัย และปกป้องข้อมูลของผู้ใช้งานจากผู้ไม่ประสงค์ดี