ช่องโหว่ความปลอดภัยในเครื่องมือรัน SQL สำหรับ LLM เมื่อการ์ดแสดงผลกับตอนกดใช้ไม่ตรงกัน
นักพัฒนาพบข้อผิดพลาดร้ายแรงในเครื่องมือรันคำสั่ง SQL ที่ช่วยให้ LLM ทำงานอย่างปลอดภัย หลังพบว่าคอลัมน์ที่แสดงตอนพรีวิวไม่ตรงกับคอลัมน์ที่ถูกบันทึกจริงเมื่อกดใช้งาน
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- เครื่องมือรัน SQL สำหรับ LLM แสดงผลการเปลี่ยนแปลงแค่ 1 คอลัมน์ แต่ตอนกดใช้กลับเขียนทับข้อมูลในคอลัมน์อื่นด้วย
- สาเหตุเพราะระบบใช้ชื่อตัวแปรเดียวกันระหว่างชุดคอลัมน์ที่เปลี่ยนแปลงกับชุดคอลัมน์ที่คำสั่ง SQL เขียนข้อมูล
- การตรวจสอบความถูกต้องล้มเหลวเพราะไม่ได้ตรวจสอบแถวที่ข้อมูลเดิมตรงกับค่าเป้าหมายอยู่แล้ว
- การตรวจสอบโค้ดแบบเดิมมองข้ามไฟล์ apply.ts ไปอย่างน่าเหลือเชื่อจนต้องรื้อตรวจใหม่ทั้งหมด
นักพัฒนาซอฟต์แวร์รายหนึ่งได้สร้างเครื่องมือชื่อว่า @hyuga/llm-safe-sql บน npm ซึ่งออกแบบมาเพื่อให้โมเดลภาษาขนาดใหญ่ (LLM) เสนอคำสั่ง UPDATE จากนั้นระบบจะรันจริงในทรานแซคชัน วัดค่าก่อนและหลัง แล้วทำการ rollback เสมอเพื่อให้มนุษย์ตรวจสอบและอนุมัติก่อนคอมมิตจริง แนวคิดสำคัญคือสิ่งที่มนุษย์อนุมัติไม่ใช่คำอธิบาย SQL ของโมเดล แต่คือสิ่งที่ฐานข้อมูลทำจริง ๆ ตอนที่ SQL รันขึ้นมา
อย่างไรก็ตาม สัปดาห์ก่อนหน้านี้มีการพบข้อผิดพลาดที่ซ่อนอยู่ตั้งแต่เวอร์ชันแรก โดยจากผลลัพธ์จริงในเวอร์ชัน 0.4.0 คำสั่งคือการอัปเดตตาราง customers ให้เปลี่ยนชื่อจาก Tanaka เป็น Sato สำหรับลูกค้าไอดี 1 แต่รหัสไปรษณีย์ postcode ยังคงเป็น 00100 เท่าเดิม การ์ดอนุมัติจึงแสดงผลว่ามีการเปลี่ยนแปลงเพียง 1 แถวและ 1 คอลัมน์เท่านั้น
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ทว่าก่อนที่แผนดังกล่าวจะถูกนำไปกดใช้จริง มีคนอื่นเข้ามาแก้ไขรหัสไปรษณีย์ของลูกค้ารายนี้ให้เป็น 90210 ไปก่อนแล้ว เมื่อมีการกดใช้แผนที่อนุมัติไว้ ระบบได้ทำการอัปเดตข้อมูลและแสดงผลว่าสำเร็จโดยไม่มีคำเตือนใด ๆ ทั้งสิ้น และคำว่า postcode ก็ไม่เคยปรากฏบนการ์ดอนุมัติหรือบันทึกตรวจสอบเลยแม้แต่ครั้งเดียว
ช่องโหว่นี้สะท้อนให้เห็นถึงอันตรายของการใช้ตัวแปรปะปนกันระหว่างตรรกะการแสดงผลและตรรกะการตรวจสอบความปลอดภัยของระบบฐานข้อมูล ในระบบซอฟต์แวร์ที่ซับซ้อน การแยกระหว่างข้อมูลที่ตั้งใจจะเปลี่ยนกับข้อมูลที่คำสั่ง SQL แตะต้องจริง ๆ เป็นสิ่งสำคัญมาก เพราะคำสั่งเช่นการกำหนดค่าให้เท่ากับค่าเดิม (SET x = ค่าเดิม) หรือการใส่สถานะสำรอง มักทำให้เกิดช่องว่างที่ระบบตรวจสอบมองไม่เห็นหากไม่มีการออกแบบชุดข้อมูลตรวจสอบที่รัดกุมตั้งแต่ต้น
ปัญหาดังกล่าวเกิดขึ้นเพราะชุดคอลัมน์ที่เปลี่ยนแปลงกับชุดคอลัมน์ที่คำสั่ง SQL เขียนข้อมูลนั้นถูกใช้ชื่อเดียวกัน ต้นเหตุคือชุดคำสั่งกำหนดค่าให้เท่ากับค่าเดิมไม่ได้ถูกมองว่าเป็นเรื่องแปลกใน SQL แต่เมื่อเกิดขึ้นในระบบตรวจสอบความปลอดภัย มันทำให้การตรวจสอบก่อนและหลังการทำงานผิดเพี้ยนไป นอกจากนี้ยังมีปัญหาในระดับที่กว้างขึ้น เมื่อคำสั่ง WHERE ตรงกับหลายแถวและมีบางแถวที่มีค่าเป้าหมายอยู่แล้ว การตรวจสอบความถูกต้องจะไม่ทำงานกับแถวเหล่านั้นเลย
"The set of columns that change and the set of columns the statement writes are different sets, and I had used one name for both."
ผู้พัฒนาเครื่องมือ @hyuga/llm-safe-sql
แนวทางแก้ไขของผู้พัฒนาคือการหยุดนำสองชุดนี้มารวมกัน โดยปรับให้ PlanRow เก็บข้อมูล covered ทุกคอลัมน์ที่คำสั่งกำหนดค่า พร้อมบันทึกภาพก่อนและหลังแม้ว่าค่าจะไม่เปลี่ยน เพื่อให้ระบบตรวจสอบความถูกต้องได้ทั้งสองฝั่ง และในเวอร์ชัน 0.4.2 ระบบได้เปลี่ยนเป็นปฏิเสธการทำงานพร้อมแจ้งเตือน ROW_CHANGED ทันทีหากข้อมูลเกิดการเปลี่ยนแปลงไปจากตอนที่สร้างแผน
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น