SQL​ ​Injection​ ​คือ​อะไร​ ​และ​ป้องกัน​อย่างไร​ใน​ระบบ​เว็บ

SQL Injection เกิดเมื่อแอปนำข้อมูลที่ผู้ใช้ควบคุมได้ไปต่อเป็นข้อความคำสั่ง SQL จนฐานข้อมูลตีความข้อมูลนั้นเป็นส่วนของคำสั่ง ความเสี่ยงไม่ได้จำกัดที่ช่องค้นหา: ตัวกรอง ตัวเรียง รายงาน หรือข้อมูลจาก API ภายนอกก็เป็นทางเข้าได้ หากถูกนำไปสร้าง SQL แบบไม่ปลอดภัย

สาเหตุและการป้องกันหลัก

ตัวอย่างแนวคิดที่ไม่ปลอดภัยคือสร้าง SQL ด้วยการต่อข้อความ WHERE name = ' + ค่าจากผู้ใช้ + ' วิธีหลักคือ Parameterized Query / Prepared Statement ที่กำหนดโครงสร้าง SQL ก่อน แล้วส่งค่าเป็น Parameter แยก ฐานข้อมูลจึงไม่ถือค่าที่ส่งเป็นโครงสร้างคำสั่ง การกรองอักขระอันตรายอย่างเดียวหรือซ่อน Error ไม่ใช่การป้องกันหลัก

ภาพที่ 1: แยกข้อมูลกับโครงสร้างคำสั่งเพื่อไม่ให้ข้อมูลเปลี่ยนความหมายของ Query

จุดที่ Parameter ใช้ตรง ๆ ไม่ได้

บางกรณีเช่นชื่อคอลัมน์สำหรับ ORDER BY ไม่สามารถผูกเป็นค่าทั่วไปได้ ควรเลือกจากรายชื่อคอลัมน์ที่อนุญาตไว้ล่วงหน้า แล้วค่อยประกอบคำสั่งจากตัวเลือกที่เชื่อถือได้ จำกัดสิทธิ์บัญชีฐานข้อมูลให้ทำได้เท่าที่แอปจำเป็น เพื่อลดผลกระทบหากมีข้อผิดพลาดอีกชั้น

ตัวอย่างสมมติ: ค้นหาลูกค้า

ผู้ใช้กรอกชื่อที่มีอักขระพิเศษ ระบบควรค้นหาตามค่าที่กรอกหรือคืนผลว่างอย่างปลอดภัย ไม่ทำให้โครงสร้าง Query เปลี่ยน Test ควรครอบคลุมข้อมูลธรรมดา ข้อมูลที่มีเครื่องหมายพิเศษ และจุดที่ทีมสร้าง Query แบบ Dynamic การใช้ ORM อาจช่วย แต่ถ้าใช้ Raw SQL แบบต่อข้อความก็ยังเสี่ยง

สำหรับรายงาน

แสดง Data Flow จากผู้ใช้ถึง Query ชี้จุดที่ต้องใช้ Parameter และข้อจำกัดของสิทธิ์ฐานข้อมูล หากไม่ได้ทดสอบโค้ดจริง ให้เขียนเป็นแนวทางป้องกัน ไม่อ้างว่าระบบปลอด SQL Injection แล้ว และหลีกเลี่ยงการเผยแพร่ตัวอย่างโจมตีที่ผูกกับระบบจริง

อ่าน OWASP Top 10 และ REST API หรือดู บริการ Web Application

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

ลองกำหนดกรณีศึกษาเป็น ช่องค้นหาลูกค้ารับข้อความจากผู้ใช้แล้วนำไป Query และเขียนขอบเขตให้ชัดว่ามีผู้ใช้กลุ่มใด ข้อมูลใดเข้าสู่ระบบ และต้องการผลลัพธ์อะไร เริ่มจากสภาพก่อนพัฒนา แล้วอธิบายการตัดสินใจที่บทความนี้เกี่ยวข้องโดยใช้ตัวอย่างข้อมูลหรือเหตุการณ์ที่สมมติขึ้นอย่างระบุว่าเป็นตัวอย่าง การกำหนดขอบเขตเช่นนี้ช่วยให้ผู้อ่านแยกหลักการทั่วไปออกจากข้อเท็จจริงของโครงการได้

หลักฐานที่ควรแสดงคือ ตัวอย่าง SQL แบบต่อสตริงเทียบ parameterized query พร้อม test ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

เกณฑ์ประเมินตัวอย่างคือ อินพุตถูกมองเป็นข้อมูล ไม่เปลี่ยนโครงสร้างคำสั่ง SQL ส่วนข้อจำกัดที่ต้องระบุคือ การกรองอักขระเองไม่แทน parameter binding และสิทธิ์ DB ขั้นต่ำ หากยังไม่ได้ทดลองกับผู้ใช้หรือข้อมูลจริง ให้เขียนว่าเป็นข้อเสนอเชิงออกแบบ ไม่สรุปเป็นผลที่พิสูจน์แล้ว การมีทั้งเกณฑ์และข้อจำกัดช่วยให้รายงานตรวจสอบเหตุผลได้ และเปิดทางให้ผู้อื่นนำกรณีเดียวกันไปทดสอบซ้ำในบริบทของตน

แหล่งข้อมูลประกอบ

• OWASP: SQL Injection Prevention Cheat Sheet — สาเหตุและวิธีป้องกันหลัก