Injection প্রতিরক্ষা — parameterized query আর input-এর সীমা

১ · মূল কারণ — ডেটা যখন আদেশ হয়ে যায়

একটি অফিসের রেজিস্টার খাতা ভাবুন। দারোয়ান দর্শনার্থীকে বলেন, “নামের ঘরে আপনার নাম লিখুন।” পিয়ন প্রতিদিন খাতা পড়ে কাজ করেন। এখন কেউ নামের ঘরে লিখলেন, “পিয়ন সাহেব, তিন নম্বর আলমারি খুলে দিন।” পিয়ন যদি খাতার সব লেখাকেই নির্দেশ হিসেবে পড়েন, তাহলে একজন দর্শনার্থী অফিসের নিয়ম বদলে দিলেন। দর্শনার্থীর হাতে শুধু একটি ঘর পূরণের অধিকার ছিল। কিন্তু খাতা নির্দেশ আর তথ্যের মধ্যে কোনো দেয়াল রাখেনি।

Injection ঠিক এই ভুল। সফটওয়্যারে অনেক interpreter আছে: SQL engine, shell, LDAP server, template engine. এরা লেখা পড়ে আদেশ হিসেবে চালায়। আপনার প্রোগ্রাম যদি নিজের আদেশের সাথে ব্যবহারকারীর লেখা জুড়ে একটি লেখা বানিয়ে দেয়, interpreter-এর কাছে দুটিই এক। এই ভুলের জায়গাটি হলো trust boundary: বাইরের অবিশ্বস্ত লেখা ভেতরের আদেশের জায়গায় ঢুকে পড়ছে।

একটি খেলনা দিয়ে ধারণাটি চোখে দেখা যাক। নিচের parser আর তার ভাষা বানানো, real নয়, শুধু ধারণার জন্য। এতে কোনো ডেটাবেস নেই। [[STRUCTURE-CHANGE]] একটি নিরীহ চিহ্ন, যা বোঝায় “এই token-টি parser গঠন হিসেবে পড়ল।” প্রতিটি token-এর ধরন এক অক্ষরে ছাপা হয়: W শব্দ, V মান, S গঠন, ? ফাঁকা ঘর।

// TOY ONLY: a made-up language and parser in memory. Not real SQL.
// real নয়, শুধু ধারণার জন্য
const MARK = '[[STRUCTURE-CHANGE]]';
const WORDS = new Set(['FIND', 'customer', 'WHERE', 'name', 'IS']);

function parse(text) {             // reads every token as language
  return text.split(' ').map(tok => {
    if (tok === MARK) return 'S';
    if (tok === '?') return '?';
    return WORDS.has(tok) ? 'W' : 'V';
  }).join('');
}

function concatQuery(input) {      // unsafe pattern: input enters the text
  return parse('FIND customer WHERE name IS ' + input);
}
function boundQuery(input) {       // structure first, value kept apart
  return { shape: parse('FIND customer WHERE name IS ?'), value: input };
}

const EXPECTED = 'WWWWWV';
for (const input of ['Rahim', 'Rahim Uddin', 'Rahim ' + MARK]) {
  const c = concatQuery(input);
  const b = boundQuery(input);
  console.log('input :', input);
  console.log('  concat shape:', c, c === EXPECTED ? '(as designed)' : '(STRUCTURE CHANGED)');
  console.log('  bound  shape:', b.shape, '(fixed), value:', JSON.stringify(b.value));
}

২ · SQL injection — গঠন ভাঙে কীভাবে

SQL injection সবচেয়ে পরিচিত উদাহরণ। ঝুঁকিটি CWE তালিকায় CWE-89 নামে আছে, আর OWASP Top 10:2025-এ Injection বিভাগ পঞ্চম স্থানে। বিশদ মানচিত্র পাবেন পর্ব ৩৭-এ। কারণটি ডেটাবেস কোর্সে আগেই দেখেছেন ডেটাবেস নিরাপত্তা পর্বে। এখানে আমরা রক্ষকের পুরো নকশায় যাব। অনিরাপদ কোডের ধরনটি এমন:

# Unsafe coding pattern. Do not write this.
sql = "SELECT id, city FROM customers WHERE name = '" + "<user-input>" + "'"
db.execute(sql)

এখানে ইনপুট SQL-এর উদ্ধৃতিচিহ্নের ভেতরে বসছে। কিন্তু উদ্ধৃতিচিহ্নটি SQL-এর গঠনের অংশ। ইনপুটের ভেতরেই একই চিহ্ন থাকলে পড়ার সীমানা বদলে যায়। ক্ষতি নির্ভর করে পরিস্থিতির ওপর: যে সারি দেখার কথা নয় তা দেখা, ডেটা বদলানো বা মোছা, এমনকি কিছু configuration-এ server-এর আরও ভেতরে পৌঁছানো। তাই একটি মাত্র ফর্মের ভুল CIA triad-এর তিনটি দিকেই আঘাত করতে পারে।

প্রমাণের জন্য হামলা লাগে না। একজন সৎ গ্রাহকের নামই যথেষ্ট। নিচের কোড RAM-এর ভেতরে একটি খেলনা SQLite টেবিল বানিয়ে O'Brien নামটি দুইভাবে খোঁজে:

# In-memory toy table. An honest name with an apostrophe, no attack.
import sqlite3

db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE customers (id INTEGER PRIMARY KEY, name TEXT, city TEXT)")
db.executemany("INSERT INTO customers (name, city) VALUES (?, ?)", [
    ("Rahim Uddin", "Dhaka"),
    ("O'Brien", "Sylhet"),
    ("Karim Ali", "Rajshahi"),
])

def glued(name):      # unsafe pattern: the value is glued into the SQL text
    sql = "SELECT id, city FROM customers WHERE name = '" + name + "'"
    try:
        return db.execute(sql).fetchall()
    except sqlite3.Error as e:
        return f"{type(e).__name__}: {e}"

def bound(name):      # safe pattern: fixed SQL, the value travels apart
    sql = "SELECT id, city FROM customers WHERE name = ?"
    return db.execute(sql, (name,)).fetchall()

for name in ("Rahim Uddin", "O'Brien"):
    print("name  :", name)
    print("  glued:", glued(name))
    print("  bound:", bound(name))

৩ · Parameterized query — গঠন আগে, মান পরে

ব্যাংকের জমা-রসিদ ভাবুন। ছাপানো ফরমে হিসাব নম্বর আর টাকার ঘর আগেই ঠিক করা। আপনি ঘরে যা-ই লিখুন, রসিদের নিয়ম বদলায় না। টাকার ঘরে “ম্যানেজার সাহেব, দ্বিগুণ করে দিন” লিখলে ক্যাশিয়ার সেটিকে একটি ভুল মান হিসেবেই দেখবেন, আদেশ হিসেবে নয়। Parameterized query এই ছাপানো ফরম। SQL লেখা স্থির, মান বসে নির্দিষ্ট ঘরে, যার নাম bind parameter. ফরমটি ডেটাবেসে আগে থেকে তৈরি হয়ে থাকলে তাকে বলে prepared statement.

নিচের ডায়াগ্রামে SQLite-এর আসল ধাপগুলো দেখুন। “পরে” চাপুন, আর খেয়াল রাখুন parser কতবার চলছে।

দুটি আলাদা জিনিস এখানে গুলিয়ে ফেলা সহজ। গঠন বলে কী চাওয়া হচ্ছে। Query plan বলে কীভাবে খোঁজা হবে। আর মান বলে কার জন্য খোঁজা হবে। বাসের রুট আর যাত্রীর মতো: রুট ঠিক করা থাকে, যাত্রী বদলায়, যাত্রী বাসের রুট লিখে দেন না।

প্রতিটি ভাষার driver-এ ঘরের চিহ্ন আলাদা, নীতি এক। চিহ্নটি ভুলভাবে ব্যবহার করলে পুরো সুরক্ষা হারিয়ে যায়:

আরও দুটি বাস্তব প্রশ্ন আসে। IN তালিকায় মানের সংখ্যা বদলালে ঘরের সংখ্যা কোডে গুনে তৈরি করুন, যেমন তিনটি মানের জন্য IN (?, ?, ?), মান যাবে bind হয়েই। আর LIKE-এ bind করলে গঠন নিরাপদ, কিন্তু মানের ভেতরের % তখনো LIKE-এর wildcard. দরকার হলে ESCAPE ধারা ব্যবহার করুন, আর ইনপুটের দৈর্ঘ্য সীমিত রাখুন।

৪ · ORM আর stored procedure — কতটা বাঁচায়, কোথায় বাঁচায় না

অনেকে বলেন, “আমরা ORM ব্যবহার করি, তাই injection নেই।” কথাটি অর্ধেক সত্য। সাধারণ ব্যবহারে ORM নিজেই মান bind করে। কিন্তু ORM-এর ভেতরেও raw query লেখার দরজা আছে, আর সেখানে জোড়া লেখা ঢোকালে ORM কিছুই করতে পারে না। OWASP Top 10:2025-ও সতর্ক করে যে ORM-এর নিজস্ব query ভাষাতেও জোড়া লেখা বিপজ্জনক। SQLAlchemy দিয়ে তিনটি ধরন দেখুন:

# 1. Safer: the ORM binds the value
stmt = select(Customer).where(Customer.name == name)

# 2. Unsafe pattern: raw text built by glueing; the ORM cannot help
stmt = text("SELECT id FROM customers WHERE name = '" + "<user-input>" + "'")

# 3. Safer raw query: a named parameter
stmt = text("SELECT id FROM customers WHERE name = :name").bindparams(name=name)

Stored procedure-এর ক্ষেত্রেও একই কথা। Procedure ডাকার সময় মান bind করলে ডাকটি নিরাপদ। কিন্তু procedure-এর ভেতরে যদি dynamic SQL জোড়া লেখায় বানানো হয়, ঝুঁকি শুধু ডেটাবেসের ভেতরে সরে গেল। PostgreSQL-এর উদাহরণ:

-- Unsafe pattern inside a procedure: the value joins the SQL text
EXECUTE 'SELECT id FROM customers WHERE city = ''' || p_city || '''';

-- Safer: the value travels through USING
EXECUTE 'SELECT id FROM customers WHERE city = $1' USING p_city;

ডেটাবেসের দিকের বিস্তারিত দেখুন ORM আর migration আর stored procedure পর্বে।

৫ · যেখানে placeholder চলে না — dynamic ORDER BY আর escaping

ধরুন একটি অনলাইন বাজারে ক্রেতা দাম বা নাম অনুযায়ী পণ্য সাজাতে চান। স্বাভাবিক ভাবনা: ORDER BY ?। কিন্তু placeholder শুধু মানের জন্য। কলামের নাম (SQL identifier) আর ASC/DESC হলো গঠনের অংশ। তাই ঘরে কলামের নাম দিলে সে একটি সাধারণ text মান হয়ে যায়। কোনো error আসে না, শুধু সাজানো হয় না! নিচের ডায়াগ্রামে তিনটি বিকল্প পরখ করে সিদ্ধান্ত নিন।

এই নীতি কোডে দেখুন। এখানে কোনো ডেটাবেস নেই। খেলনা অনুরোধগুলো শুধু SQL-এর স্থির টুকরো বেছে নেয়।

// Toy: map a requested sort to fixed SQL text. No database, no network.
const SORT_COLUMNS = new Map([
  ['price', 'price'], ['name', 'name'], ['newest', 'created_at'],
]);
const SORT_DIRS = new Map([['asc', 'ASC'], ['desc', 'DESC']]);

function orderBy(sort, dir) {
  const col = SORT_COLUMNS.get(sort);
  const way = SORT_DIRS.get(dir);
  if (col === undefined || way === undefined) return null;
  return `ORDER BY ${col} ${way}, id ASC`;   // only strings from the maps
}

const requests = [
  ['price', 'desc'],
  ['newest', 'asc'],
  ['price', 'DESC'],
  ['[[STRUCTURE-CHANGE]]', 'asc'],
  ['constructor', 'asc'],
];
for (const [sort, dir] of requests) {
  const clause = orderBy(sort, dir);
  console.log(sort.padEnd(21), dir.padEnd(5), '=>', clause ?? 'REJECTED (400)');
}

Escaping — কেন শেষ উপায়

Escaping মানে বিশেষ চিহ্নকে এমন রূপে লেখা, যাতে interpreter সেটিকে সাধারণ অক্ষর ভাবে। সমস্যা হলো, এটি মিশ্র পথটিকেই বাঁচিয়ে রাখে, আর প্রতিটি জায়গায় নিয়ম নিখুঁত হতে হয়: ডেটাবেসের ধরন, character encoding, server-এর সেটিং, উদ্ধৃতির ধরন। একটি জায়গায় ভুল হলেই সব শেষ। OWASP-এর SQL Injection Prevention Cheat Sheet তাই SQL-এ একে দৃঢ়ভাবে নিরুৎসাহিত করে। Parameterized query সম্ভব হলে escaping নয়। শুধু যেখানে সত্যিই আলাদা পথ নেই, সেখানে ওই interpreter-এর জন্য তৈরি পরীক্ষিত library ব্যবহার করুন, হাতে লেখা replace নয়। PostgreSQL-এ identifier দরকার হলে format('%I', ...) আছে, তবে সেখানেও আগে allowlist.

৬ · Input validation — বাড়তি স্তর, প্রধান ঢাল নয়

Input validation মানে ইনপুট প্রত্যাশিত ধরন, মাপ আর রূপের সাথে মেলে কি না যাচাই। মেট্রোর গেটে টিকিট দেখার মতো। এটি খুব কাজের, কারণ ভুল ডেটা শুরুতেই আটকে যায়। কিন্তু injection-এর একমাত্র ঢাল হিসেবে এটি যথেষ্ট নয়। OWASP Top 10:2025 সরাসরি বলে, এটি পূর্ণ প্রতিরক্ষা নয়, কারণ অনেক অ্যাপে বিশেষ চিহ্ন দরকার হয়। O'Brien তার জীবন্ত প্রমাণ।

Validation server-এ হতে হবে, কারণ browser-এর JavaScript যাচাই ব্যবহারকারীর হাতে। রূপ যাচাইয়ের আগে সাধারণ আকারে আনুন, আর দৈর্ঘ্যের সীমা দিন। নিচে বাংলাদেশি মোবাইল নম্বরের একটি যাচাইকারী। এটি বাংলা অঙ্ক ইংরেজিতে আনে, ফাঁকা আর হাইফেন সরায়, তারপর regex-এর সাথে পুরো লেখা মেলায়। ব্যবহৃত নম্বরগুলো বানানো।

// Toy validator for the Bangladeshi mobile number format. Made-up numbers.
const BN_DIGITS = '০১২৩৪৫৬৭৮৯';
const PHONE = /^(?:\+?88)?(01[3-9]\d{8})$/;   // anchors: match the whole text

function normalize(raw) {
  const digits = [...raw.trim()].map(ch => {
    const i = BN_DIGITS.indexOf(ch);
    return i >= 0 ? String(i) : ch;
  });
  return digits.join('').replace(/[\s-]/g, '');
}

function checkPhone(raw) {
  if (raw.length > 20) return 'REJECT (too long)';
  const m = PHONE.exec(normalize(raw));
  return m ? 'OK ' + '+88' + m[1] : 'REJECT (format)';
}

const samples = [
  '01700-000001',
  '০১৮০০০০০০০২',
  '+8801900000003',
  '01200000004',
  '0170000000',
  '01700000001 [[STRUCTURE-CHANGE]]',
];
for (const s of samples) console.log(s.padEnd(34), checkPhone(s));

কোন ইনপুটে কতটা validation চলে, তার একটি হিসাব: সংখ্যা, তারিখ, enum আর ফোন নম্বরে কড়া নিয়ম সম্ভব। মানুষের নাম, ঠিকানা আর মন্তব্যে নয়। সেখানে শুধু দৈর্ঘ্য আর encoding দেখা হয়, বাকি নিরাপত্তা দেয় bind. এটিই defense in depth: একটি স্তর অন্যটির বিকল্প নয়।

৭ · ভুল হলেও ক্ষতি সীমিত — least privilege আর নিরাপদ error

ধরে নিন, কোথাও একটি ভুল থেকে যাবে। তখন প্রশ্ন: ক্ষতি কতদূর যাবে? দোকানের কর্মচারীর হাতে ক্যাশ বাক্সের চাবি থাকলে এক কথা, পুরো মালিকের সিন্দুকের চাবি থাকলে আরেক কথা। ওয়েব অ্যাপের ডেটাবেস অ্যাকাউন্টই সেই চাবি। পর্ব ৩-এর least privilege এখানে blast radius ছোট রাখে। এটি injection থামায় না, ক্ষতির সীমা টানে।

-- Example for your own database. The login secret lives in a secret store.
CREATE ROLE shop_web LOGIN;
GRANT CONNECT ON DATABASE shop TO shop_web;
GRANT USAGE ON SCHEMA public TO shop_web;
GRANT SELECT ON products TO shop_web;
GRANT SELECT, INSERT ON orders TO shop_web;
-- No DROP, no ALTER, no access to admin tables, not a superuser.
CREATE ROLE shop_report LOGIN;          -- a separate read-only reporting role
GRANT SELECT ON orders TO shop_report;

• প্রতি অ্যাপে আলাদা অ্যাকাউন্ট: ওয়েব, রিপোর্ট আর migration এক login-এ নয়। Migration-এর অধিকার চলমান অ্যাপের কাছে থাকবে না।
• শুধু দরকারি অধিকার: শুধু পড়ার পাতায় শুধু পড়ার অ্যাকাউন্ট। সংবেদনশীল কলাম view দিয়ে আড়াল করুন।
• কোনো superuser নয়: ডেটাবেস-প্রক্রিয়াও সাধারণ OS অ্যাকাউন্টে চালান। বিশদ পর্ব ২০-এ।

SQLite-এ user account নেই, তাই ধারণাটি একটি read-only সংযোগ দিয়ে দেখা যায়। স্থানীয়ভাবে Python 3.14 আর SQLite 3.50-এ চালিয়ে পাওয়া ফল নিচে:

db.execute("PRAGMA query_only = ON")          # this connection may only read
print(db.execute("SELECT id, total FROM orders").fetchall())
db.execute("DELETE FROM orders")              # refused by the database

# Output of a local run:
# [(1, 500)]
# sqlite3.OperationalError: attempt to write a readonly database

এটি শুধু ধারণার জন্য। query_only একটি সংযোগের সেটিং, অ্যাকাউন্টের অধিকার নয়। বাস্তবে server-ভিত্তিক ডেটাবেসের role অনেক শক্ত সীমা দেয়, আর SQLite-এ ফাইলটি mode=ro দিয়ে খোলা ভালো।

Error-এ schema ফাঁস নয়

কাঁচা database error-এ টেবিল, কলাম, কখনো পুরো SQL লেখা থাকে। ব্যবহারকারীর পর্দায় এটি দেখানো information disclosure (CWE-209), কারণ এতে ভেতরের নকশা বাইরে চলে যায়। নিয়ম সহজ: বিস্তারিত থাকবে server-এর log-এ, ব্যবহারকারী পাবেন একটি সাধারণ বার্তা আর একটি correlation ID, যাতে support দল ঘটনাটি খুঁজে পায়।

try:
    rows = find_orders(customer_id)
except DatabaseError:
    ref = new_reference()                       # e.g. "ref-7f3a"
    log.exception("order lookup failed", extra={"ref": ref})   # full detail, server only
    return error_page(500, "Something went wrong. Reference: " + ref)   # no SQL, no stack trace

Production-এ debug page আর stack trace বন্ধ রাখুন। এর সাধারণ configuration পর্ব ৪৪-এ দেখা হবে।

৮ · একই রোগ, অন্য ভাষায় — command থেকে log পর্যন্ত

SQL শুধু একটি উদাহরণ। যেখানেই লেখা জুড়ে কোনো interpreter-এ পাঠানো হয়, একই প্রশ্ন: “এখানে কি আলাদা পথ আছে?” থাকলে সেটি ব্যবহার করুন।

Command injection — shell-কে বাদ দিন

একটি অ্যাপ OS-এর কোনো প্রোগ্রাম চালাতে গিয়ে পুরো আদেশ এক লেখায় বানিয়ে shell-কে দিলে OS command injection (CWE-78)-এর ঝুঁকি। Shell নিজের চিহ্ন আর ব্যাকরণ দিয়ে লেখাটি পড়ে, তাই ইনপুট আদেশের অংশ হতে পারে। প্রতিকারের ক্রম:

1. বাইরের প্রোগ্রামই না চালানো। ফাইল সংকোচনের কাজে ভাষার নিজস্ব library ব্যবহার করুন।
2. Shell ছাড়া argument array. প্রোগ্রাম আর প্রতিটি argument আলাদা উপাদান, মাঝে কোনো shell নেই। এটি SQL-এর bind-এর সমতুল্য।
3. ইনপুট allowlist-এ যাচাই, কারণ প্রোগ্রামটি নিজেই argument-কে option ভাবতে পারে। অনেক tool-এ -- লিখে option-এর শেষ চিহ্নিত করা যায়।

# Design example only, not for running here.
import gzip, shutil, subprocess

# Unsafe pattern: one text handed to a shell
subprocess.run("gzip -k " + "<user-input>", shell=True)

# Better: no shell, one list item per argument, a time limit
subprocess.run(["gzip", "-k", "--", checked_path], shell=False, check=True, timeout=10)

# Best here: no external program at all
with open(checked_path, "rb") as src, gzip.open(out_path, "wb") as dst:
    shutil.copyfileobj(src, dst)

Argument array shell-এর ঝুঁকি সরায়, তবে ফাইলের পথের ঝুঁকি নয়। checked_path অনুমোদিত ফোল্ডারের ভেতরে কি না তা আলাদা যাচাই, যা পর্ব ৪২-এ আসবে।

অন্য interpreter-গুলো, এক নজরে

Log-কে নিরীহ ভাববেন না। ২০২১ সালের Log4Shell-এ সমস্যা ছিল এখানেই: log library লেখার ভেতরের বিশেষ অংশকে শুধু ছাপেনি, প্রক্রিয়াও করত। লেখার জিনিস তখন আদেশ হয়ে গিয়েছিল।

Second-order — দেরিতে জাগা বাগ

O'Brien নিবন্ধনের সময় bind হয়ে নিরাপদে জমা হলো। মাসখানেক পর একটি রাতের রিপোর্ট সেই নাম ডেটাবেস থেকে পড়ে SQL লেখায় জুড়ে দিল, ভেবে যে “আমাদের ডেটাবেসের মান তো বিশ্বস্ত।” রিপোর্ট ভেঙে গেল। এটিই second-order injection-এর ধারণা: ইনপুট ঢোকার জায়গায় নয়, ব্যবহারের জায়গায় বাগ। নিয়মটি তাই সহজ: উৎস যা-ই হোক, প্রতিটি query-তে bind. ডেটাবেস থেকে পড়া মানও ডেটা।

৯ · ধরা আর যাচাই — WAF, log, query নজরদারি, review আর SAST

প্রতিরোধের পরও জানতে হবে, কেউ চেষ্টা করছে কি না আর কোথাও বাগ রয়ে গেছে কি না। পর্ব ৪-এর threat model থেকে ঠিক করুন কোন পাতা সবচেয়ে সংবেদনশীল, আর সেখান থেকে শুরু করুন।

Query fingerprint হলো মান বাদ দেওয়া গঠনের ছাপ। Parameterized অ্যাপে গঠনের সংখ্যা সীমিত, তাই “ওয়েব অ্যাকাউন্ট থেকে একটি একদম নতুন গঠন” বেশ অর্থবহ সংকেত। PostgreSQL-এর pg_stat_statements বা MySQL-এর performance schema এমন হিসাব রাখতে পারে। নিচে নিজের log-এর জন্য একটি শিক্ষামূলক Sigma নিয়ম। সীমা আর ক্ষেত্রের নাম আপনার ব্যবস্থা অনুযায়ী মিলিয়ে নিন। SIEM-এ নিয়ম সাজানো পর্ব ৫৬-এ দেখবেন।

title: SQL errors from the web account (teaching example)
status: experimental
description: Syntax or privilege errors from the app login. Tune on your own logs.
logsource:
  category: database
  product: postgresql
detection:
  selection:
    user: shop_web
    sql_state|startswith: '42'
  condition: selection
falsepositives:
  - A new release that shipped a broken query
level: medium

একটি হিসাব: WAF-এর alert কতটা বিশ্বাসযোগ্য

পর্ব ২৩-এর base-rate fallacy এখানে কাজে লাগে। ধরে নেওয়া সংখ্যা: একদিনে ১০,০০,০০০ অনুরোধ, এর মধ্যে আসল injection চেষ্টা ২০টি। WAF নিয়ম ৯০% চেষ্টা ধরে, আর সাধারণ অনুরোধের ০.১%-এ ভুল সতর্কতা দেয়।

• সত্য ধরা: 20 × 0.90 = ১৮টি
• ভুল সতর্কতা (false positive): 999,980 × 0.001 ≈ ১,০০০টি
• Precision = 18 ÷ (18 + 999.98) ≈ ০.০১৭৭, অর্থাৎ প্রায় ১.৮%

অর্থাৎ ৯৮%-এর বেশি alert ভুল। এর মানে WAF অকেজো নয়। এর মানে WAF-এর একটি alert নিজে থেকে হামলার প্রমাণ নয়, আর এটি কোড ঠিক করার বিকল্পও নয়। WAF-এর সবচেয়ে ভালো ভূমিকা সাময়িক virtual patch: কোড ঠিক হওয়া পর্যন্ত সময় কেনা। বিস্তারিত CDN, WAF আর edge পর্বে, আর পর্ব ৪৪-এ।

নিজের কোডে পরীক্ষা

• Code review-এ একটি প্রশ্ন: Review-এ প্রতিটি query দেখে জিজ্ঞেস করুন, “SQL লেখায় কি কোনো চলক ঢুকছে?” ঢুকলে সেটি কোথা থেকে এল? এই “parameter binding review” সস্তা, কার্যকর।
• SAST: tool কোড না চালিয়েই taint analysis করে: অবিশ্বস্ত উৎস থেকে মান কি জোড়া লেখা হয়ে execute-এ পৌঁছায়? Build pipeline-এ রাখুন। False positive থাকবে। বিস্তারিত পর্ব ৪৯-এ।
• নিরীহ regression test: নিজের অ্যাপে এমন test রাখুন যা O'Brien, বাংলা নাম, খুব লম্বা লেখা আর [[STRUCTURE-CHANGE]] দেয়, আর আশা করে সঠিক ফল বা পরিষ্কার 400, কখনো 500 নয়।

দ্রুত খসড়া তালিকার জন্য নিজের repository-তে সাধারণ খোঁজও চলে। এটি শুধু review-এর শুরু, প্রমাণ নয়:

# Run on your own source tree. Rough hints for review, expect false alarms.
grep -rnE 'execute\(\s*f"' src/
grep -rnE 'execute\(.*\+' src/
grep -rn 'shell=True' src/

অন্যের সাইটে, বা নিয়োগকর্তার system-এও, লিখিত অনুমতি ছাড়া এমন পরীক্ষা নয়। অনুমোদিত পরীক্ষার নিয়ম পর্ব ৫০-এ।

১০ · AI-এর যুগে injection

AI কোড লিখে দেয় দ্রুত, কিন্তু পুরোনো ইন্টারনেটের টিউটোরিয়াল থেকেও শেখে। তাই জোড়া লেখার কোড এখনো বেরিয়ে আসতে পারে, আর দেখতে একদম স্বাভাবিক লাগে। আর আজকের অ্যাপে AI নিজেই একটি নতুন interpreter, যার ঝুঁকি prompt injection পর্ব ৫১-এ দেখবেন।

AI-এর কোড মেনে নেওয়ার আগে

• প্রতিটি query-র SQL লেখা স্থির, ইনপুট শুধু bind হয়ে যাচ্ছে
• Raw query, dynamic ORDER BY আর stored procedure-এর ভেতরটা আলাদা করে পড়েছি
• Shell নেই, অথবা তার পক্ষে একটি স্পষ্ট কারণ আছে
• O'Brien, বাংলা নাম আর খুব লম্বা ইনপুটে নিজের ল্যাবে চালিয়েছি
• Error-এ SQL বা stack trace বাইরে যাচ্ছে না
• Prompt-এ কোনো secret বা ব্যক্তিগত ডেটা পেস্ট করিনি, আর CVE বা মান-উল্লেখ মূল উৎসে মিলিয়েছি