เจาะโค้ด 512 แอปจาก Lovable พบ 16% เปิดช่องผู้ใช้ทั่วไปแก้ข้อมูลได้
จากการตรวจสอบไฟล์ Migration ของ 512 แอปบน GitHub พบ 16.2% ตั้งค่า RLS ผิดพลาดให้ผู้เยี่ยมชมที่ไม่ได้ล็อกอินแก้ไขหรือลบข้อมูลทุกแถวได้
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ตรวจสอบไฟล์ Migration ของ 512 แอปสาธารณะที่สร้างด้วย Lovable บน GitHub
- พบ 16.2% ของโปรเจกต์ปล่อยให้ผู้ใช้ทั่วไปที่ไม่ได้ล็อกอินแก้ไขหรือลบข้อมูลในตารางได้
- มี 10.4% ของตารางทั้งหมดที่ถูกสร้างขึ้นโดยไม่เปิดใช้งานระบบ Row Level Security (RLS) เลย
- เครื่องมือ VibeRaven เป็นตัวช่วยสแกนโค้ดก่อนนำไปใช้งานจริงบนฐานข้อมูล Supabase
การสร้างแอปพลิเคชันด้วยเครื่องมือ AI ปัจจุบันมีความรวดเร็วและสะดวกสบายมากขึ้น แต่ในขณะเดียวกันก็อาจนำมาซึ่งช่องโหว่ด้านความปลอดภัยที่คาดไม่ถึง ล่าสุดมีการศึกษาไฟล์ Migration ของโครงการสาธารณะจำนวน 512 โปรเจกต์ที่สร้างด้วยแพลตฟอร์ม Lovable และใช้งานฐานข้อมูล Supabase ซึ่งผลลัพธ์ที่ได้น่าตกใจไม่น้อย
โอฮาด คอร์ (Ohad Kr) ผู้พัฒนาเครื่องมือโอเพนซอร์ส VibeRaven สำหรับตรวจสอบโค้ดของแอปประเภท Vercel และ Supabase ได้ทำการวิเคราะห์ซอร์สโค้ดที่แอปพลิเคชันเหล่านี้จัดทำขึ้น แทนที่จะเป็นการเจาะระบบฐานข้อมูลสดๆ เพื่อดูว่ามีการตั้งค่าความปลอดภัยที่ผิดพลาดอย่างไรบ้าง โดยการสแกนครั้งนี้มุ่งเน้นไปที่ไฟล์ Migration ที่มาพร้อมกับโปรเจกต์ Lovable บน GitHub ในช่วงเดือนตุลาคม 2026
จากกลุ่มตัวอย่าง 512 โครงการ ผลปรากฏว่ามีโปรเจกต์ถึง 83 โครงการ หรือคิดเป็น 16.2% ที่จัดส่งนโยบาย Migration ซึ่งอนุญาตให้ผู้เยี่ยมชมที่ไม่ได้ลงชื่อเข้าใช้สามารถอัปเดตหรือลบข้อมูลทุกแถวในตารางได้ นอกจากนี้ยังมีอีก 7 โครงการ (1.4%) ที่ยอมให้ผู้ใช้ที่ล็อกอินแล้วทำเช่นเดียวกันได้ และอีก 53 โครงการ (10.4%) ที่สร้างตารางขึ้นมาแต่ไม่เคยเปิดใช้งานระบบความปลอดภัย Row Level Security (RLS) บนตารางนั้นเลย
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
สาเหตุสำคัญประการหนึ่งที่เคยมีการรายงานจาก UpGuard เกี่ยวกับฐานข้อมูล Supabase นับหมื่นแห่งที่ถูกเปิดexposed ไว้คือ การสร้างตารางผ่าน API โดยอัตโนมัติ ซึ่งเป็นวิธีการที่เหล่า Coding Agent ทำงานอยู่แล้ว โดยตารางเหล่านี้จะไม่ถูกเปิดใช้งาน RLS เป็นค่าเริ่มต้น การสแกนโค้ดก่อนนำไป deploy จึงช่วยให้เห็นความเสี่ยงที่ซ่อนอยู่ในขั้นตอนก่อนที่จะกลายเป็นฐานข้อมูลจริง
"Policy "Owners can update their agents" on public.agents lets anyone, signed in or not, update every row, to any values: using (true). The name says "Owners can update their agents", but nothing in the policy checks who the caller is."
VibeRaven Scan Report
อีกหนึ่งข้อผิดพลาดที่พบซ้ำๆ คือการตั้งค่านโยบายในทำนองว่า "Service role can manage all sessions" พร้อมกับเงื่อนไข using (true) ซึ่งในความเป็นจริงแล้ว Service role มีสิทธิ์บายพาส RLS อยู่แล้วโดยไม่ต้องมีนโยบายมารองรับ การใส่คำสั่งลักษณะนี้จึงเป็นการเปิดตารางให้ทุกคนเข้าถึงได้โดยปริยาย เว้นแต่จะมีการจำกัดขอบเขตไว้ให้ชัดเจนสำหรับ service_role เท่านั้น
ในมุมมองด้านความปลอดภัย คอนเซปต์ของ Row Level Security (RLS) ใน Supabase ถือเป็นหัวใจสำคัญในการปกป้องข้อมูลระดับแถว (Row-level) หากนักพัฒนาพึ่งพา AI หรือเครื่องมือช่วยเขียนโค้ดอัตโนมัติโดยไม่ตรวจสอบไฟล์ Migration ให้รอบคอบ คำสั่งง่ายๆ อย่าง using (true) บนคำสั่งอัปเดตหรือลบข้อมูลอาจกลายเป็นช่องโหว่ใหญ่ที่เปิดให้ใครก็ได้บนอินเทอร์เน็ตเข้ามาแก้ไขฐานข้อมูลได้ทันที แม้ว่าชื่อนโยบายจะฟังดูปลอดภัยก็ตาม
อย่างไรก็ตาม ตัวเลขเหล่านี้ไม่ได้หมายความว่า 16.2% ของแอปพลิเคชัน Lovable ทั้งหมดในปัจจุบันกำลังถูกโจมตีอยู่ เนื่องจากข้อมูลนี้นำมาจากคลังโค้ดสาธารณะบน GitHub ซึ่งส่วนใหญ่เป็นโปรเจกต์ทดลอง (Side projects) และโค้ดใน GitHub ก็อาจจะไม่ตรงกับสิ่งที่รันอยู่บนระบบจริงเสมอไป เพราะนักพัฒนาอาจจะทำการแก้ไขผ่านหน้าแดชบอร์ดของ Supabase ไปแล้วภายหลัง
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น