SQL injection คืออะไร และคุณจะป้องกันมันอย่างไร?

Question

Accepted Answer

**SQL injection** คือช่องโหว่ที่ผู้โจมตีแทรกคำสั่ง SQL ที่เป็นอันตรายผ่าน input ของผู้ใช้ เพื่อบิดเบือนคำสั่ง query ของฐานข้อมูลในการขโมยข้อมูล ข้ามการยืนยันตัวตน หรือทำลายข้อมูล มันเป็นหนึ่งในช่องโหว่เว็บที่อันตรายและคลาสสิกที่สุด แต่ป้องกันได้ด้วยเทคนิคที่เหมาะสม

## SQL injection ทำงานอย่างไร

```text
When user input is concatenated directly into a SQL query, an attacker can INJECT SQL:
```

```js
// ❌ VULNERABLE — user input concatenated into the query
const query = `SELECT * FROM users WHERE email = '${userInput}'`;
// attacker enters:  ' OR '1'='1
// → SELECT * FROM users WHERE email = '' OR '1'='1'   → returns ALL users!
// or:  '; DROP TABLE users; --   → could delete the table
```

input ของผู้โจมตีถูกปฏิบัติเสมือนเป็น **โค้ด SQL** แทนที่จะเป็นข้อมูล ทำให้พวกเขาสามารถเขียน query ใหม่ได้ (ข้ามการล็อกอิน ดึงข้อมูลทั้งหมด ลบตาราง)

## การป้องกัน: parameterized queries (วิธีแก้หลัก)

```js
// ✅ PARAMETERIZED / PREPARED statements — input is treated as DATA, never as code
const query = 'SELECT * FROM users WHERE email = ?';
db.execute(query, [userInput]);     // the value is safely bound, not concatenated
// → the database treats userInput as a literal value → injection impossible
```

**Parameterized queries (prepared statements)** แยกโค้ด SQL ออกจากข้อมูล ทำให้ input ไม่สามารถถูกตีความเป็น SQL ได้ นี่คือการป้องกันหลักที่เชื่อถือได้

## การป้องกันเพิ่มเติม

```text
✓ PARAMETERIZED queries / prepared statements → the #1 fix (always use them)
✓ ORMs/query builders → use parameterization under the hood (but don't bypass with raw
  string concatenation)
✓ INPUT VALIDATION (defense in depth) — validate/sanitize, but NOT a substitute for
  parameterization
✓ LEAST PRIVILEGE DB accounts (limit damage); avoid exposing detailed DB errors
→ NEVER build queries by concatenating user input.
```

## ทำไมจึงสำคัญ

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

การเข้าใจ **ว่ามันทำงานอย่างไร** ว่าการต่อ input ของผู้ใช้เข้าไปใน query SQL โดยตรงทำให้ผู้โจมตี **แทรกโค้ด SQL ได้** (input ของพวกเขาถูกปฏิบัติเป็นโค้ดแทนที่จะเป็นข้อมูล) ทำให้พวกเขาสามารถข้ามการยืนยันตัวตน (`' OR '1'='1`) ดึงข้อมูลทั้งหมด หรือแม้แต่ลบตาราง (`'; DROP TABLE`) จำเป็นสำหรับการรู้จักและหลีกเลี่ยงช่องโหว่นี้

SQL injection อาจร้ายแรงอย่างหายนะ (การละเมิดข้อมูลทั้งหมด การทำลายข้อมูล การข้ามการยืนยันตัวตน) ทำให้มันสำคัญอย่างยิ่ง

การเข้าใจ **การป้องกัน** เป็นเรื่องจำเป็น: **parameterized queries (prepared statements)** เป็นวิธีแก้หลักที่เชื่อถือได้ พวกมัน **แยกโค้ด SQL ออกจากข้อมูล** ทำให้ input ของผู้ใช้ถูกปฏิบัติเสมือนเป็นค่าตัวอักษรที่ไม่สามารถถูกตีความเป็น SQL ได้ ทำให้ injection เป็นไปไม่ได้

นี่คือการป้องกันอันดับ 1 ที่นักพัฒนาทุกคนต้องใช้

การเข้าใจ **การป้องกันเพิ่มเติม** การใช้ ORM/query builder (ซึ่งใช้ parameterization แต่ไม่หลีกเลี่ยงด้วยการต่อสตริงแบบ raw) การตรวจสอบ input ในฐานะ defense-in-depth (แต่ไม่ใช่สิ่งที่ใช้แทน parameterization) บัญชีฐานข้อมูลแบบ least-privilege และการหลีกเลี่ยงการเปิดเผยข้อความ error ของฐานข้อมูลโดยละเอียด รวมถึงกฎสำคัญที่ว่า **ห้ามต่อ input ของผู้ใช้เข้าไปใน query** สะท้อนการป้องกันที่ครอบคลุม

เนื่องจาก SQL injection เป็นช่องโหว่ที่อันตราย พบบ่อย และคลาสสิก ที่มีผลกระทบรุนแรง (การละเมิดข้อมูล การสูญเสียข้อมูล การข้ามการยืนยันตัวตน) ที่ป้องกันได้อย่างสมบูรณ์ด้วย parameterized queries และเนื่องจากการเข้าใจว่ามันทำงานอย่างไรและจะป้องกันอย่างไรจำเป็นสำหรับนักพัฒนาทุกคนที่ทำงานกับฐานข้อมูล การเข้าใจ SQL injection และการป้องกันจึงเป็นความรู้ด้านความปลอดภัยที่จำเป็นและต้องรู้ เป็นช่องโหว่พื้นฐานที่ต้องเข้าใจและป้องกัน ซึ่งวิธีแก้ที่เรียบง่ายและเชื่อถือได้ (parameterized queries) เป็นความรู้สำคัญที่ป้องกันหนึ่งในกลุ่มการโจมตีที่สร้างความเสียหายมากที่สุด