SQL Injection နှင့် Parameterized Query

နားလည်ထားရမယ့် အချက်

SQL injection ဖြစ်ရတာက application တစ်ခုက untrusted input ကို query string ထဲ တိုက်ရိုက် ပေါင်းစပ်ပြီး SQL query တည်ဆောက်တဲ့အခါပါ။ User ရိုက်ထည့်တဲ့ data နဲ့ developer ရေးထားတဲ့ SQL syntax ကို database က ခွဲခြားမသိတော့ပါဘူး။

Parameterized query က SQL structure နဲ့ input value ကို channel သီးသန့်နှစ်ခုကနေ ပို့ပါတယ်။ Template ကို ကြိုတင် fix ထားပြီး value ကို နောက်မှ data အနေနဲ့သာ bind လုပ်ပါတယ် — query structure ရဲ့ တစ်စိတ်တစ်ပိုင်းအဖြစ် လုံးဝ မဟုတ်ပါဘူး။

Driver နဲ့ ORM အများစုက parameterized query ကို default, safe input လက်ခံနည်းအဖြစ် support လုပ်ပါတယ်။ ဒီ site ရဲ့ SQL နဲ့ PostgreSQL tutorial တွေမှာ language-specific syntax အတိအကျ ပြထားပါတယ်။

UNSAFE VS SAFE QUERY CONSTRUCTION
---------------------------------
UNSAFE: string concatenation
  userInput ------------------+
                               v
  "SELECT * FROM users WHERE email = '" + userInput + "'"
                               |
                               v
                  one blended string of SQL text
                  (input can change the SQL structure)

SAFE: parameterized query
  SQL template:  "SELECT * FROM users WHERE email = $1"
                               |
                               v
                     locked in before input arrives
  userInput ------------------+
                               v
                     bound separately, as pure data
                  (input can never change the structure)

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

SQL injection ကို ကာကွယ်ဖို့ဆိုတာ ကျွမ်းကျင်မှုထက် အလေ့အထ ကိစ္စပိုများပါတယ်။ User input က query ကို ရောက်ရှိတဲ့နေရာတိုင်း code ရေးလိုင်းပထမဆုံးကနေတည်း parameterized-query API ကို သုံးသင့်ပါတယ်။

ORM တွေက ဒါကို almost automatic ဖြစ်စေပါတယ်။ Project က raw SQL ဆီ ဆင်းပြီး string concatenation ကို ရင်းနှီးမှုကြောင့် သုံးမိတဲ့အခါ risk ပြန်ပေါ်လာပါတယ် — ဒါက ရပ်တန့်စဉ်းစားထိုက်တဲ့ အချိန်အတိအကျပါ။

အောက်က code က နှစ်ဖက်စလုံးကို ကာကွယ်ရေးရှုထောင့်ကနေ ပြထားပါတယ်: အန္တရာယ်ရှိတဲ့ input ကို flag လုပ်တဲ့ pattern-detector နဲ့ content ဘာပါပါ ဘေးကင်းစွာ ကိုင်တွယ်တဲ့ simulated parameterized query။ Database အစစ်ပေါ်မှာ exploit မရှိပါ။

• SQL injection ဖြစ်ရတာက untrusted input ကို SQL query string ထဲ တိုက်ရိုက် ပေါင်းစပ်ပြီး query structure ကို ပြန်ပုံဖော်ခွင့်ပေးလိုက်တဲ့အခါပါ။
• Parameterized query က SQL template နဲ့ input value ကို channel သီးသန့်ကနေ ပို့ပြီး input က SQL structure မဖြစ်နိုင်အောင် ဖြေရှင်းပေးပါတယ်။
• Driver နဲ့ ORM အများစုက parameterized query ကို default အနေနဲ့ support လုပ်ပါတယ် — code ရေးလိုင်းပထမဆုံးကတည်း သုံးပါ၊ နောက်ပိုင်းပြင်ဆင်ချက်အဖြစ် မဟုတ်ဘဲ။

အတူတူ စမ်းရေးကြည့်မယ်

// Defensive pattern-detector: flags characters/keywords that are dangerous
// ONLY if someone concatenates them directly into a raw SQL string.
function looksDangerousIfConcatenated(input) {
  const suspiciousPattern = /('|--|;|\bor\b|\bunion\b|\bdrop\b)/i;
  return suspiciousPattern.test(input);
}

// Simulated parameterized query: a real driver sends the SQL text and the
// parameter values as SEPARATE channels, so the value is always treated as
// plain data and can never change the query's structure.
function runParameterizedQuery(sqlTemplate, params) {
  return { sql: sqlTemplate, boundParams: params, executedAsData: true };
}

const suspiciousInput = "' OR '1'='1";
const normalInput = "alice@example.com";

console.log("suspicious input flagged:", looksDangerousIfConcatenated(suspiciousInput));
console.log("normal input flagged:", looksDangerousIfConcatenated(normalInput));

console.log(runParameterizedQuery("SELECT * FROM users WHERE email = $1", [suspiciousInput]));
console.log(runParameterizedQuery("SELECT * FROM users WHERE email = $1", [normalInput]));

Detector က suspicious input "' OR '1'='1" ကို true၊ normal input "alice@example.com" ကို false လို့ flag လုပ်ပါတယ်။ နှစ်ခုစလုံး simulated parameterized query ကို ဖြတ်တဲ့အခါ { sql: "SELECT * FROM users WHERE email = $1", boundParams: [input], executedAsData: true } ကို နှစ်ခုလုံးအတွက် အတူတူ ပြန်ပေးပါတယ် — safe path က flag လုပ်ခံရတဲ့ input ထဲမှာ ဘာပါပါ တစ်ပုံစံတည်း ကိုင်တွယ်ပါတယ်။

OWASP: SQL Injection Prevention Cheat Sheet — How Databases Work