ทุกวันนี้ทุกคนทำกิจกรรมในโลกไซเบอร์ มีโทรศัพท์เครื่องเดียวก็สามารถจัดการหลายสิ่งหลายอย่างได้ ซึ่งส่วนใหญ่หลายกิจกรรมมักจะมีการลงชื่อเข้าใช้งาน หรือก็คือการ Log in ก่อนการใช้งาน เช่น เมื่อต้องการซื้อของออนไลน์ ก็ต้องจำเป็นสำหรับ Log in หรือแอปที่หลายคนใช้กันอย่างแอปของธนาคารที่เราจำเป็นต้อง Log in เพื่อยืนยันว่าตัวเราเองที่เป็นผู้ใช้ ซึ่งสิ่งเหล่านี้คือการทำ Authentication และการทำ Authorization แต่วันนี้ขอหยิบยกเรื่อง Authorization มาคุยกันก่อนนะคะ
Authorization ?
Authorization คือสิ่งที่สำคัญในการระบุและกำหนดว่าระดับการเข้าถึงหรือสิทธิ์ของผู้ใช้ผ่านตัวตนที่เขาได้ล็อคอินหรือระบุ หรือถ้าพูดให้เห็นภาพ ในระดับองค์กรนั้นก็มีการใช้ Authorization ในการระบุว่าพนักงานคนไหนสามารถเข้าถึงหรือใช้ข้อมูลของบริษัท และก็เป็นการระบุเพิ่มเติมอีกว่า ข้อมูลไหนที่พนักงานคนนั้นสามารถดูหรือใช้งานได้ ซึ่งพอเรา Log in เข้าสู่ระบบแล้ว ระบบทราบแล้วว่าเราเป็นใคร ระบบก็จะทำการ Authorization เพื่อตรวจสอบว่าเรามีสิทธิ์จะเห็นหรือจะทำอะไรบ้าง
ตัวอย่างของการไม่ทำ Authorization
- ในกรณีที่เรามีสิทธิเท่ากันและมีเมนูหรือฟังก์ชันที่เหมือนกัน เช่น
คุณ A เป็นผู้ใช้งานทั่วไป และคุณ B เป็นผู้ใช้งานทั่วไปเช่นกัน
เมื่อคุณ A เข้า “http://www.somebank.com/view_transaction.php?user_id=6”
และเปลี่ยน “user_id=6” เป็น “user_id=7” หรือคุณ A ทำการวิธีคาดเดา หรือ brute force ก็สามารถพบข้อมูล transaction ของผู้อื่นได้ ซึ่งประเด็นนี้จัดอยู่ในช่องโหว่ประเภท Insecure Direct Object Reference (IDOR)
2. ในกรณีที่เรามีสิทธิเท่ากัน แต่มีเมนูหรือฟังก์ชันไม่เหมือนกัน เช่น
เว็บไซต์ขนส่งสินค้าแห่งหนึ่ง คุณ A เป็นผู้ใช้งานทั่วไป ซึ่งเป็นสมาชิกที่ใช้บริการเว็บไซต์ขนส่งสินค้าแห่งนี้มาเป็นเวลานาน ส่วนคุณ B เป็นผู้ใช้งานทั่วไป เช่นกัน แต่เป็นสมาชิกใหม่ที่ยังไม่เคยใช้บริการเว็บไซต์ขนส่งสินค้าแห่งนี้ ซึ่งสำหรับสมาชิกใหม่ จะได้รับคูปองส่วนลดเมื่อใช้บริการครั้งแรก 50 % หากไม่มีการทำ Authorization คุณ A สามารถขโมย Cookie ของคุณ B เพื่อเข้าใช้งานฟังก์ชันของคูปองส่วนลดนั้นได้
3. ในกรณีที่เรามีสิทธิไม่เท่ากัน เช่น
เว็บไซต์ขนส่งสินค้าแห่งหนึ่ง คุณ A เป็นผู้ใช้งานทั่วไป และคุณ B เป็นผู้ดูแลระบบ
กรณีนี้ถ้าคุณ A หา URL ของผู้ดูแลระบบเจอ คุณ A จะสามารถเข้าถึงและใช้งานเสมือนเป็นผู้ดูแลระบบ สิ่งนี้อาจทำให้เกิดกระทบได้หลายส่วน เช่น สามารถกำหนดสิทธิของผู้ใช้งาน จากผู้ใช้งานทั่วไปเป็นผู้ดูแลระบบอีกคน หรือกรณีที่ฝั่งผู้ดูแลระบบมีการเก็บข้อมูลสำคัญ เช่น ข้อมูลของผู้ใช้งานคนอื่น , ข้อมูลบัตรเครดิต , username/password ฯลฯ ทำให้คุณ A สามารถเข้าถึงข้อมูลเหล่านี้ได้
4. กรณีที่เป็น API ที่มีการเก็บข้อมูลที่สำคัญอยู่ หากไม่มีการทำ Authorization หรือมีการทำแต่ยังไม่เหมาะสม จนทำให้ผู้อื่นสามารถเรียกใช้ได้ทุกคน โดยไม่มีการตรวจสิทธิการใช้งาน ข้อมูลเหล่านั้นมีสิทธิที่จะตกอยู่ในมือของผู้ไม่ประสงค์ดีได้
กรณีที่กล่าวมานี้เป็นกรณีเบื้องต้นที่พบเห็นได้บ่อยครั้ง โดยเป็นช่องโหว่ที่เกี่ยวกับ Authorization ซึ่ง OWASP TOP 10 ปี 2021 ของ Web application ถูกจัดอยู่ในข้อ A01: Broken Access Control และ OWASP TOP 10 ปี 2016 ของ Mobile ถูกจัดอยู่ในข้อ M6: Insecure Authorization
สาเหตุหลักของการที่ทำให้เกิดปัญหาเกี่ยวกับ Authorization
- Developer ไม่มีการตรวจสอบสิทธิของผู้ใช้งาน หรือมีการทำการตรวจสอบสิทธิที่ไม่เพียงพอเมื่อมีการทำงานที่จำเป็นต้องใช้สิทธิในการยืนยันตัวตน เช่น ไม่ได้มีการตรวจสอบยืนยันตัวตนก่อนการเรียกใช้งานฟังก์ชัน เป็นต้น
- Developer ไม่มีการตรวจสอบข้อมูลประเภท user id หรือ object id เช่น “http://www.somebank.com/view_transaction.php?user_id=6” ที่สามารถเปลี่ยนแปลงค่าของ user_id ได้ ทำให้สามารถเข้าถึงข้อมูลของผู้ใช้งานคนอื่น
- เปิด directory listing ไว้ ทำให้ผู้ไม่ประสงค์ดีสามารถเข้าถึง path ที่เก็บไว้ได้
โดยแนวทางป้องกันของสาเหตุข้างต้น
- Developer ควรที่จะมีการตรวจสิทธิของผู้ใช้งานทุกครั้ง ทุกฟังก์ชันการทำงาน และ Developer ควรตรวจสอบเกี่ยวกับการอนุญาตให้ผู้ใช้งานแต่ละท่านสามารถดูข้อมูลได้เฉพาะเท่าที่ควร และเห็นได้เฉพาะข้อมูลของตัวเอง เช่น เว็บไซต์ใช้ Session ID ในการจัดการและระบุถึงบัญชีผู้ใช้ที่เข้าสู่ระบบสำเร็จ เพื่อระบุตัวตนของผู้ใช้งาน แต่เว็บไซต์ทั่วไปอาจจะใช้ User ID ซึ่งเป็นค่าค่าหนึ่งที่เก็บอยู่ในฐานข้อมูลในการอ้างอิง การเก็บ User ID ที่อ้างอิงจากฐานข้อมูลใน URL หรือ POST parameter จะทำให้ผู้ไม่ประสงค์ดีสามารถใช้ User ID ในการเข้าถึงและดำเนินการใด ๆ กับฐานข้อมูลได้ โดยปลอมตัวเป็นผู้ใช้งานและเข้าถึงข้อมูลที่ไม่ได้รับอนุญาตได้
- ตรวจสอบการทำ authorization ใน web page ที่มีการรับข้อมูลจากผู้ใช้งาน โดยทำการตรวจสอบข้อมูลประเภท user id หรือ object id ที่สามารถแก้ไขได้ โดยการตรวจสอบนี้ไม่เพียงเฉพาะการรับข้อมูลจาก URL เท่านั้น ทาง Developer ต้องตรวจสอบข้อมูลที่ได้รับมาชนิด POST ด้วย
- Disable directory listing โดยปกติ web application software เช่น Apache จะมีฟังก์ชัน directory listing นั่นคือ การผู้ใช้งานทำการเข้าถึง path ที่เป็น folder ไฟล์ที่อยู่ใน folder จะถูกแสดงออกมาทั้งหมด ฟังก์ชันนี้ควรถูกปิดเนื่องจากเปิดโอกาสให้ผู้ไม่ประสงค์ดีสามารถเห็นรายชื่อของไฟล์ใน folder ซึ่งนำไปสู่การเข้าถึงไฟล์โดยไม่ได้รับอนุญาต
- ทำให้ user id หรือ object id ยากแก่การเดาสุ่ม การทำชื่อไฟล์หรือ user id ให้ยากแก่การเดาสุ่มนั้น จะช่วยป้องกันช่องโหว่ประเภท IDOR ได้ระดับนึง เนื่องจากผู้ไม่ประสงค์ดี ไม่อาจจะคาดเดาชื่อไฟล์หรือ user id ได้ถูกต้องได้ง่ายนัก วิธีนี้เป็นเพียงแค่ลดความเสี่ยง ไม่ได้เป็นการแก้ไขปัญหาที่ต้นเหตุ
