นักพัฒนาแชร์ประสบการณ์แฮกแอป Rails ของตัวเองได้ง่ายๆ
GJ Hewitt นักพัฒนาแอป RepBoard บน Ruby on Rails เผยช่องโหว่ความปลอดภัยจากการเผลอใส่ฟิลด์ reviewable ใน Devise และการปิด CSRF protection
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- GJ Hewitt ผู้สร้าง RepBoard บน Ruby on Rails ตรวจสอบโค้ดตัวเองและพบช่องโหว่ร้ายแรง
- การตั้งค่า Devise อนุญาตให้พารามิเตอร์ reviewable ถูกอัปเดตผ่านฟอร์มได้โดยไม่ต้องแสดงผล
- การปิด CSRF protection ในไฟล์ตั้งค่าเริ่มต้นทำให้แอปเสี่ยงต่อการถูกโจมตี
GJ Hewitt นักพัฒนาซอฟต์แวร์ผู้สร้าง RepBoard แอปพลิเคชันบน Ruby on Rails ที่ช่วยให้ฟรีแลนซ์รวบรวมรีวิวจากลูกค้า ได้ออกมาแชร์ประสบการณ์ผ่านบทความบน Dev.to หลังจากที่เขาตัดสินใจลองตรวจสอบความปลอดภัยโค้ดของตัวเองตามบทความสอนใช้งานที่เพิ่งอ่าน โดยแอปดังกล่าวมีผู้ใช้งานสองประเภทคือฟรีแลนซ์ที่มีโปรไฟล์สาธารณะเพื่อรับรีวิว และลูกค้าที่เข้าสู่ระบบมาเพื่อเขียนรีวิว ซึ่งความแตกต่างของบัญชีทั้งสองประเภทนี้ถูกกำหนดด้วยคอลัมน์ boolean บนตาราง users ที่ชื่อว่า reviewable
ในการจัดการระบบยืนยันตัวตน เขาใช้ Devise และได้กำหนดค่าใน application_controller.rb ให้ฟิลด์ account_update อนุญาตให้รับค่า display_name, reviewable, bio, slug และ avatar_url ได้ ปัญหาก็คือการอนุญาตพารามิเตอร์ไม่เกี่ยวข้องกับการแสดงผลบนหน้าจอ ทำให้แอปยอมรับข้อมูลทุกอย่างที่ส่งเข้ามาในคำขอ ผู้ใช้จึงสามารถเข้าสู่ระบบด้วยบัญชีลูกค้า เปิดหน้าตั้งค่าบัญชี ใช้เครื่องมือ devtools เพิ่มแท็ก input ซ่อนไว้ว่า user[reviewable] มีค่าเท่ากับ 1 แล้วส่งข้อมูลด้วยรหัสผ่านของตนเองเพื่อยกระดับสิทธิ์กลายเป็นฟรีแลนซ์ได้ทันที
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
หลังจากพบปัญหาดังกล่าว เขาใช้เวลาแก้ไขเพียงสิบวินาทีด้วยการลบฟิลด์ reviewable ออกจากรายการอนุญาตใน devise_parameter_sanitizer และมองว่ารายการดังกล่าวทำหน้าที่เหมือนรายชื่อแขกที่หน้าประตู ซึ่ง Rails ยอมให้ใครก็ตามที่มีชื่อเข้ามาได้แม้จะเป็นชื่อที่เขาไม่เคยตั้งใจจะใส่ไว้ก็ตาม นอกจากนี้ เขายังพบปัญหาในส่วนการสร้างรีวิวที่ตรวจสอบเพียงว่าผู้เขียนเป็นลูกค้า แต่ไม่เคยตรวจสอบว่าผู้รับรีวิวเป็นฟรีแลนซ์จริงหรือไม่ ทำให้ลูกค้าสามารถรีวิวลูกค้าด้วยกันเองหรือรีวิวตัวเองได้ผ่านการแก้ไขฟิลด์ซ่อน
เหตุการณ์นี้ชี้ให้เห็นถึงความแตกต่างสำคัญระหว่าง Validation และ Authorization ในการพัฒนาซอฟต์แวร์ โดย Validation จะทำหน้าที่ตรวจสอบว่าข้อมูลมีความถูกต้องตามกฎของข้อมูลหรือไม่ เช่น การกำหนดให้ผู้รีวิวต้องเป็นลูกค้าและผู้ถูกรีวิวต้องเป็นฟรีแลนซ์ ซึ่งควรถูกใส่ไว้ที่ Model เพื่อป้องกันในทุกเส้นทางการใช้งาน ไม่ว่าจะเป็นผ่าน Console, Rake task หรือ Controller ขณะที่ Service object จะป้องกันเฉพาะเส้นทางที่ผ่านตัวมันเองเท่านั้น การแยกระหว่างกฎของข้อมูลและสิทธิ์การเข้าถึงให้ชัดเจนจึงเป็นหัวใจสำคัญในการป้องกันช่องโหว่เชิงตรรกะในแอปพลิเคชัน
เมื่อเขาเพิ่มการตรวจสอบลงในรีวิวโมเดลและรันคำสั่ง rake sample_data เพื่อโหลดฐานข้อมูลจำลองใหม่ ระบบก็เกิดข้อผิดพลาดทันที เนื่องจากไฟล์ seed เดิมถูกเขียนขึ้นโดยอิงจากกฎที่อยู่ในหัวของเขาเท่านั้น ไม่ได้ถูกบังคับด้วยโค้ดจริง ทำให้มีข้อมูลจำลองประเภทฟรีแลนซ์รีวิวฟรีแลนซ์กว่าห้าสิบรายการซึ่งแอปไม่ควรอนุญาตตั้งแต่แรก แสดงให้เห็นว่าหากชุดข้อมูลทดสอบไม่สามารถรอดพ้นจากการตรวจสอบความถูกต้องได้ แสดงว่ามีบางอย่างผิดปกติเกี่ยวกับกฎของแอปพลิเคชันนั้นๆ
ไม่เพียงแค่นั้น เขายังลองเปิดไฟล์คอนฟิกูเรชันที่เคยละเลยไปในไดเรกทอรี config/initializers/appdev_rails_settings.rb ซึ่งสืบทอดมาจากเทมเพลตโปรเจกต์เริ่มต้น และพบว่ามีการตั้งค่า Rails.application.config.action_controller.default_protect_from_forgery = false เอาไว้ ซึ่งเป็นการปิดระบบป้องกัน Cross-Site Request Forgery หรือ CSRF โดยตั้งใจไว้ใช้สำหรับห้องทดลองเรียนรู้ แต่กลับถูกนำมาใช้บนแอปพลิเคชันที่ใช้งานจริงและเผยแพร่สู่สาธารณะ
การผสมผสานระหว่างช่องโหว่การยกระดับสิทธิ์และการปิดระบบป้องกัน CSRF ทำให้หน้าเว็บที่เป็นอันตรายสามารถเปลี่ยนประเภทบัญชีของผู้ใช้ที่เข้าสู่ระบบอยู่โดยที่พวกเขาไม่ต้องคลิกอะไรเลย เขาจึงฝากข้อคิดไว้ว่าการที่สแกนความปลอดภัยแล้วไม่พบปัญหาไม่ได้แปลว่าไม่มีอะไรให้ค้นพบ และแนะนำให้นักพัฒนาที่ใช้เทมเพลตจากคอร์สเรียนหรือบูทแคมป์ลองตรวจสอบไฟล์ตั้งค่าในโฟลเดอร์ initializers ตั้งแต่วันแรกที่เริ่มโปรเจกต์
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น