Secure coding — input, output, error আর secret-এর নিয়ম

১ · Trust boundary — কোডের ভেতরে দারোয়ান কোথায়

একটি অফিসের গেট ভাবুন। দারোয়ান গেটেই পরিচয়পত্র দেখেন, তারপর ভেতরে একটি পাস দেন। ভেতরের প্রতিটি টেবিলে আর পরিচয়পত্র দেখতে হয় না, পাস দেখলেই চলে। কিন্তু গেটে কেউ না থাকলে প্রতিটি কর্মচারীকে নিজে নিজে সন্দেহ করতে হতো, আর একজন ভুলে গেলেই বিপদ।

কোডেও একই ব্যাপার। Trust boundary হলো সেই রেখা, যেখানে ডেটা কম বিশ্বাসের জায়গা থেকে বেশি বিশ্বাসের জায়গায় আসে। এটি পর্ব ৪-এর data flow diagram-এর রেখা, এবার সেটি কোডে নামল। শুধু web form নয়, নিচের সবকিছুই সীমানা:

• ব্যবহারকারীর input, URL, header, cookie, mobile app-এর অনুরোধ
• অন্য service-এর API উত্তর, webhook, message queue
• আপলোড করা ফাইল, config ফাইল, environment, command-line argument
• ডেটাবেস থেকে পড়া পুরোনো মান, যদি অন্য কেউ লিখে থাকে (second-order ঝুঁকি)

দ্বিতীয় দিকটিও জরুরি। ভেতরের ডেটা যেখানে কোনো interpreter বা বাইরের জগতে যায়, সেই জায়গাকে বলে sink: HTML পাতা, SQL, shell, log, ফাইলের পথ। ভুল সাধারণত হয় দুই জায়গায়, ঢোকার সময় আর বের হওয়ার সময়। মাঝখানের কোড সেই দুই পাহারার ওপর নির্ভর করে।

২ · Input — allowlist, parse আর canonicalise

মোবাইল ব্যাংকিংয়ের PIN-এর ঘরে শুধু সংখ্যা চলে, আর নির্দিষ্ট দৈর্ঘ্যের। এই হলো allowlist: কী চলবে তা বলা, কী চলবে না তার তালিকা নয়। Denylist সবসময় অসম্পূর্ণ, কারণ খারাপ সবকিছুর তালিকা কেউ জানে না। Input validation-এর তিন স্তর মনে রাখুন: গঠন (সংখ্যা তো?), পরিসর (১ থেকে ৫০,০০০ টাকার মধ্যে?), আর ব্যবসার নিয়ম (এই হিসাবে এত টাকা আছে?)।

পরের ধাপটি আরও শক্তিশালী। সাধারণ যাচাই একটি হ্যাঁ বা না দিয়ে ডেটাকে আগের মতোই string রেখে দেয়। তারপর প্রতিটি ভেতরের ফাংশনকে ভাবতে হয়, “এটি কি যাচাই করা?” Parse, don't validate বলে: যাচাই করেই ডেটাকে একটি নতুন ধরনে রূপ দিন। Alexis King ২০১৯ সালের একটি লেখায় কথাটি জনপ্রিয় করেন। যাচাই না হওয়া ডেটা তখন সেই ধরনে থাকতেই পারে না।

আর একটি ক্রম না মানলে সব যাচাই বৃথা: আগে canonicalise, পরে check. একই জিনিসের অনেক রূপ থাকলে আগে সেটিকে একটি মানক রূপে আনতে হয়। যাচাই আগে হলে, আর পরে কোনো ধাপে রূপ বদলালে, যা যাচাই হলো আর যা ব্যবহার হলো তা আলাদা জিনিস। এই ত্রুটির নিজের নামই আছে: CWE-180. পথের ক্ষেত্রে একই নীতি resolve-then-check, দেখুন পর্ব ৪২।

টাকার একটি ঘর ধাপে ধাপে দেখুন। ব্যবহারকারী কোথাও থেকে কপি করে পেস্ট করেছেন, তাই শুরুতে ফাঁকা জায়গা আর দুটি full-width অঙ্ক আছে।

AMOUNT_RE = re.compile(r"[0-9]{1,7}(\.[0-9]{2})?")

@dataclass(frozen=True)
class Amount:
    paisa: int

def parse_amount(raw: str) -> Amount:
    if len(raw) > 32:
        raise BadInput("too long")
    text = unicodedata.normalize("NFKC", raw).strip()
    if not AMOUNT_RE.fullmatch(text):
        raise BadInput("format")
    taka, _, frac = text.partition(".")
    paisa = int(taka) * 100 + int(frac or "0")
    if not 100 <= paisa <= 5_000_000:
        raise BadInput("range")
    return Amount(paisa)

৩ · Output — প্রতিটি প্রসঙ্গের নিজের নিয়ম

একই খবর আদালতে, চায়ের দোকানে আর টেলিগ্রামে আলাদা ভাষায় বলতে হয়। ডেটাও তেমন। < চিহ্নটি HTML-এ বিশেষ, shell-এও বিশেষ, কিন্তু অর্থ আলাদা। একই মান কোথায় যাচ্ছে, সেটিই ঠিক করে কী করতে হবে। একে বলে encoding context.

তাই output encoding হয় ডেটা ব্যবহারের ঠিক আগে, ঢোকার সময় নয়। ঢোকার সময় কোনো “সর্বজনীন পরিষ্কার” ফাংশন চালালে ডেটা নষ্ট হয়, আর দুইবার encode হওয়ার ঝুঁকি থাকে। ডেটাবেসে আসল মান থাকবে, দেখানোর সময় প্রসঙ্গ অনুযায়ী রূপ বদলাবে।

Injection-এর মূল ধারণা আর SQL-এর দিক আছে পর্ব ৩৯-এ, HTML-এর দিক পর্ব ৪০-এ। এখানে একটি কথাই নিয়ে যান: আদেশ আর ডেটার পথ আলাদা রাখুন, আর encoding-এর জন্য নিজের ফাংশন নয়, পরীক্ষিত library ব্যবহার করুন।

৪ · সংখ্যার ফাঁদ — overflow, truncation আর sign

পুরোনো গাড়ির ওডোমিটার ভাবুন। ৯৯,৯৯৯ কিলোমিটারের পরে মিটার ০০,০০০ দেখায়, গাড়ি নতুন হয়নি। কম্পিউটারের নির্দিষ্ট আকারের সংখ্যাও এমন। ৩২-bit signed সংখ্যার সর্বোচ্চ মান 2³¹ − 1 = 2,147,483,647. এরপর এক যোগ করলে সবচেয়ে ছোট ঋণাত্মক মানে ঘুরে যেতে পারে। তিনটি ভুল মনে রাখুন:

এবার একটি খেলনা দোকান, যেখানে মোট দাম পয়সায় ৩২-bit signed ঘরে থাকে। Math.imul ঠিক এমন একটি ঘরের মতো গুণ করে। checkedTotal আগে সঠিক ফল বের করে, তারপর ঘরে রাখার আগে সীমা দেখে।

// Toy shop: money in paisa, stored in a signed 32-bit field. No real payment.
const INT32_MAX = 2147483647;

// What a C-like signed 32-bit field does: wrap around, silently.
const wrappedTotal = (price, qty) => Math.imul(price, qty);

// Safe: compute exactly, then check the range BEFORE storing.
function checkedTotal(price, qty) {
  if (!Number.isInteger(price) || !Number.isInteger(qty)) return 'REJECT type';
  if (price <= 0 || qty <= 0) return 'REJECT sign';
  const exact = BigInt(price) * BigInt(qty);
  if (exact > BigInt(INT32_MAX)) return 'REJECT too large';
  return Number(exact);
}

const orders = [[250000, 4], [3000000, 1000], [3000000, 1500], [250000, -4]];
for (const [price, qty] of orders) {
  console.log(`price=${price} qty=${qty}`);
  console.log('  exact  :', (BigInt(price) * BigInt(qty)).toString());
  console.log('  wrapped:', wrappedTotal(price, qty));
  console.log('  checked:', checkedTotal(price, qty));
}

// Truncation: the check sees 32 bits, the copy keeps only 16.
const len = 70000;
const LIMIT32 = 100000;
console.log('length', len, 'passes 32-bit check:', len <= LIMIT32);
console.log('kept by a 16-bit field:', len & 0xffff);

নিরাপদ যাচাই কীভাবে লিখবেন

• কাজের আগে যাচাই করুন, পরে নয়। a * b করে ফল ঋণাত্মক কি না দেখা C-তে ভুল পদ্ধতি, কারণ overflow হয়ে গেলে compiler ধরে নিতে পারে এমন কিছু ঘটেইনি।
• ভাষার checked সুবিধা নিন। Java-তে Math.multiplyExact, Rust-এ checked_mul, GCC ও Clang-এ __builtin_mul_overflow, C23-এ ckd_mul.
• Python-এও সাবধান। Python-এর int সীমাহীন, কিন্তু ডেটাবেসের কলাম, NumPy আর binary format-এর ঘর সীমিত। JavaScript-এ Number নিরাপদ পূর্ণসংখ্যা শুধু 2⁵³ − 1 পর্যন্ত।
• টাকায় float নয়। পয়সায় পূর্ণসংখ্যা বা decimal ধরন রাখুন। Python-এ 0.1 + 0.2 দেয় 0.30000000000000004.

/* price and qty are already known to be positive int32_t values */
if (price > INT32_MAX / qty) {
    return ERR_TOO_LARGE;   /* reject before any overflow can happen */
}
int32_t total = price * qty;

C-র বিস্তারিত দেখুন undefined behavior আর secure coding পর্বে।

৫ · Race condition আর TOCTOU — যাচাই আর কাজের মাঝখানের ফাঁক

একটি যৌথ হিসাবের কথা ভাবুন। স্বামী আর স্ত্রী দুই শাখায় একই সময়ে কাউন্টারে গেলেন। দুই ক্যাশিয়ারই খাতা দেখলেন ১,০০০ টাকা আছে। দুজনেই ৮০০ টাকা দিয়ে দিলেন। কারও ভুল ছিল না, ভুল ছিল “দেখা” আর “দেওয়া” দুটি আলাদা ধাপ হওয়ায়।

ফল কাজের সময়ের ক্রমের ওপর নির্ভর করলে তাকে বলে race condition. এর সবচেয়ে পরিচিত রূপ TOCTOU, মানে time of check to time of use: আপনি যা যাচাই করেছেন, ব্যবহারের মুহূর্তে সেটি আর সত্য নাও থাকতে পারে। নিচে একটি খেলনা ওয়ালেট দেখুন, যেখানে ৮০০ টাকা তোলার দুটি অনুরোধ একসাথে এসেছে।

সমাধানের সারকথা: যাচাই আর কাজ একই atomic operation-এ করুন। ডেটাবেসে শর্তসহ UPDATE, transaction, row lock, unique constraint. মেমরিতে lock বা atomic compare-and-swap. ফাইলে “না থাকলে তবেই তৈরি” একটি ধাপে। নিচের কোড নিজের বানানো অস্থায়ী ফোল্ডারে দুই ধরনের কাজ দেখায়। দুই কর্মীর ক্রম কোডে স্থির করা, যাতে ফল প্রতিবার একই আসে।

# Works only inside a fresh temp folder that this block creates and deletes.
import os, tempfile

def racy(path, trace):
    # Fixed interleaving of two workers, so the result repeats on every run.
    a_free = not os.path.exists(path)    # A: time of check
    b_free = not os.path.exists(path)    # B: time of check
    trace.append(f"A sees free={a_free}, B sees free={b_free}")
    if a_free:
        with open(path, "w") as f: f.write("worker A")
        trace.append("A wrote the file")
    if b_free:
        with open(path, "w") as f: f.write("worker B")
        trace.append("B wrote the file (A's work is lost)")

def atomic(path, name, trace):
    flags = os.O_CREAT | os.O_EXCL | os.O_WRONLY
    try:
        fd = os.open(path, flags, 0o600)   # check and create are ONE step
    except FileExistsError:
        trace.append(f"{name}: already exists, stop safely")
        return
    with os.fdopen(fd, "w") as f:
        f.write(f"worker {name}")
    trace.append(f"{name}: created the file")

with tempfile.TemporaryDirectory() as d:
    log = []
    p1, p2 = os.path.join(d, "racy.txt"), os.path.join(d, "atomic.txt")
    racy(p1, log)
    atomic(p2, "A", log)
    atomic(p2, "B", log)
    print("\n".join(log))
    print("racy file holds  :", open(p1).read())
    print("atomic file holds:", open(p2).read())

একই নীতি idempotency-তে কাজে লাগে। পেমেন্ট অনুরোধে একটি অনন্য key রাখলে, আর সেই key-তে unique constraint দিলে, একই অনুরোধ দুইবার এলেও টাকা একবারই কাটে। Race ধরতে test-এ একাধিক thread চালান, আর race detector আছে এমন ভাষায় সেটি ব্যবহার করুন, যেমন Go-র -race বা C-তে ThreadSanitizer.

৬ · Resource limit আর ReDoS — অসীম কিছুই নয়

ঈদের আগে দর্জির দোকান ভাবুন। একজন গ্রাহক ৫০০টি পাঞ্জাবির অর্ডার দিলে বাকি সবাই বসে থাকবেন। তাই দোকানি সীমা বেঁধে দেন। সফটওয়্যারেও প্রতিটি অনুরোধ সময়, মেমরি, CPU আর সংযোগ খায়। সীমা না থাকলে একটি বড় অনুরোধই বাকিদের আটকে দিতে পারে। এই ঝুঁকি পর্ব ২৮-এর denial of service-এর কোড-স্তরের রূপ। CWE Top 25-এর শেষ ঘরে আছে CWE-770: সীমা ছাড়া resource বরাদ্দ।

Regular expression থেকে denial of service

Regex একটি ছোট বিশেষ ইঞ্জিন চালায়। অনেক ভাষার ইঞ্জিন backtracking করে: একটি পথে না মিললে ফিরে গিয়ে আরেক পথ দেখে। সাধারণ pattern-এ এতে সমস্যা নেই। কিন্তু যদি pattern-এ একটি পুনরাবৃত্তির ভেতরে আরেকটি পুনরাবৃত্তি থাকে, বা দুই বিকল্প একই লেখা মেলাতে পারে, তাহলে না-মেলা লেখায় পথের সংখ্যা ঘাতীয় হারে বাড়তে পারে। এতে একটি ছোট input-ও CPU আটকে দেয়। একে বলে ReDoS (CWE-1333).

হিসাবটি দেখুন। ধরুন pattern-এর পথের সংখ্যা 2ⁿ, যেখানে n হলো input-এর দৈর্ঘ্য, আর ইঞ্জিন সেকেন্ডে 10⁸ ধাপ চালায়। এই গতি একটি ধরে নেওয়া সংখ্যা।

• n = ২০: 2²⁰ ÷ 10⁸ ≈ ০.০১ সেকেন্ড
• n = ৩০: 2³⁰ ÷ 10⁸ ≈ ১০.৭ সেকেন্ড
• n = ৪০: 2⁴⁰ ÷ 10⁸ ≈ ১১,০০০ সেকেন্ড, মানে প্রায় ৩ ঘণ্টা

মাত্র ২০টি অক্ষর বাড়লে সময় প্রায় ১০ লাখ গুণ হলো। প্রতিরক্ষা কয়েকটি স্তরে:

• Linear-time engine: RE2, Go-র regexp আর Rust-এর regex crate নকশাগতভাবে ঘাতীয় backtracking এড়ায়। .NET 7 থেকে RegexOptions.NonBacktracking আছে।
• Timeout: .NET-এর matchTimeout, বা Python-এর তৃতীয় পক্ষের regex module-এর timeout. Python-এর নিজের re-তে timeout নেই, তবে ৩.১১ থেকে atomic group আছে।
• আকার সীমা: Regex চালানোর আগে input-এর দৈর্ঘ্য সীমিত করুন। উপরের হিসাবে n ছোট রাখাই বড় প্রতিরক্ষা।
• ব্যবহারকারীর দেওয়া pattern নয়: বাইরের কেউ regex লিখতে পারলে সেটি কোড চালানোর সমান ঝুঁকি।
• Review আর tool: নিজের regex-এ নেস্টেড পুনরাবৃত্তি খুঁজুন, আর parser থাকলে regex বাদ দিন।

৭ · Error আর logging — চুপ করা নয়, ফাঁস করাও নয়

বিদ্যুৎ চলে গেলে ব্যাংকের লকার খুলে যায় না, বন্ধ থাকে। এটিই fail closed, যা পর্ব ৩-এ দেখেছেন। কোডে নিয়মটি সহজ: permission যাচাইয়ের সময় error হলে উত্তর “না”। উল্টোটা, মানে fail open, CWE-636. নিচের অনিরাপদ ধরনটি প্রায়ই দেখা যায়:

# Unsafe pattern: a swallowed exception turns an error into "allowed"
def can_view(user, doc):
    allowed = True
    try:
        allowed = policy.check(user, doc)
    except Exception:
        pass                       # the failure disappears here
    return allowed

# Safer: deny by default, record the real cause, show a plain message
def can_view(user, doc):
    try:
        return policy.check(user, doc) is True
    except PolicyError:
        log.exception("policy_check_failed", extra={"doc_id": doc.id})
        return False

এখানে তিনটি নিয়ম কাজ করছে। প্রথমত, শুরুর মান “না”। দ্বিতীয়ত, শুধু চেনা exception ধরা, সব নয়। তৃতীয়ত, exception গিলে ফেলা নয়। গিলে ফেলা error (CWE-390) পরে অন্য জায়গায় অদ্ভুত আচরণ হয়ে দেখা দেয়, আর তদন্ত তখন অন্ধকারে হয়।

ব্যবহারকারীকে কী দেখাবেন আর log-এ কী রাখবেন, এই দুটি আলাদা। Stack trace, SQL, ফাইলের পথ বা library version বাইরে গেলে হামলাকারীর কাজ সহজ হয় (CWE-209). পর্ব ৪৪-এর নিরাপদ error-এর মতো সাধারণ বার্তার সাথে একটি correlation id দিন, যা দিয়ে আপনার দল log-এ আসল কারণ খুঁজে পায়।

Log-এর উল্টো বিপদও আছে: log নিজেই ফাঁসের পথ (CWE-532). Log অনেক মানুষ পড়েন, অনেক system-এ কপি হয়, আর অনেকদিন থাকে। Password, OTP, PIN, token, পূর্ণ কার্ড নম্বর কখনো log-এ নয়। ফোন নম্বরের মতো ব্যক্তিগত তথ্য যতটা সম্ভব কম। নিচের খেলনা redactor দুই পদ্ধতি পাশাপাশি দেখায়।

// Toy log redactor on made-up lines. Phone numbers and tokens are fake.
const RULES = [
  [/\b(?:\+?88)?01[3-9]\d{8}\b/g, m => '***PHONE-' + m.slice(-2)],
  [/\bBearer\s+[A-Za-z0-9._-]{1,200}/g, () => 'Bearer ***TOKEN'],
  [/\b(token|password|otp|pin)=[^\s&]{1,200}/gi, (m, k) => k + '=***'],
];

function redactText(line) {
  return RULES.reduce((s, [re, fn]) => s.replace(re, fn), line);
}

// Better: a structured event keeps only fields on an allowlist.
const SAFE_FIELDS = new Set(['event', 'user_id', 'ip', 'status']);
function safeEvent(ev) {
  return Object.fromEntries(
    Object.entries(ev).filter(([k]) => SAFE_FIELDS.has(k)));
}

const lines = [
  'login ok user=u1042 phone=01900000001 ip=203.0.113.7',
  'GET /api/me Authorization: Bearer example-token-1234',
  'reset request token=example-token-9 otp=000000 status=200',
  'contact phone ০১৯০০০০০০০০১ noted by agent',
];
for (const l of lines) console.log(redactText(l));

const ev = { event: 'pay', user_id: 'u1042', status: 200,
             pin: '0000', phone: '০১৯০০০০০০০০১' };
console.log(JSON.stringify(safeEvent(ev)));

৮ · Secret, randomness আর তুলনা

লকারের চাবি লকারের গায়ে টেপ দিয়ে আটকে রাখলে তালার দাম থাকে না। কোডে লেখা password বা API key ঠিক তাই (CWE-798). কোড অনেকের হাতে যায়, পুরোনো commit-এ থেকে যায়, আর backup-এ ছড়ায়। একবার ছড়ালে একে বলে secret sprawl.

• কোডে নয়: মান আসবে বাইরে থেকে। ছোট প্রকল্পে environment variable বা .env ফাইল চলে, আর ফাইলটি version control-এ যাবে না। মনে রাখুন, environment child process পায়, আর crash report-এও উঠতে পারে।
• Vault ভালো পথ: বড় system-এ secret থাকে vault বা cloud secret manager-এ, অধিকার আর audit সহ। Dynamic secret আরও ভালো, কারণ সেটি অল্প সময় বাঁচে। প্রথম চাবির সমস্যা, মানে secret zero, দেখেছেন পর্ব ২০-এ।
• Commit-এর আগেই ধরুন: Pre-commit hook আর CI-তে secret scanning রাখুন। বিস্তারিত Git নিরাপত্তা পর্বে।
• ফাঁস হলে আগে rotate: Commit মুছলেই secret মোছে না। কেউ হয়তো আগেই কপি করেছে। তাই আগে rotation করে পুরোনোটি বাতিল করুন, তারপর log দেখুন, শেষে ইতিহাস পরিষ্কার করুন।

Randomness: শুধু CSPRNG

লুডুর ছক্কার জন্য যে র‍্যান্ডম চলে, ব্যাংকের OTP-র জন্য তা চলে না। সাধারণ PRNG তৈরি হয় দ্রুততা আর সমান বণ্টনের জন্য, অনুমান ঠেকানোর জন্য নয়। Token, session id, reset link, salt, key আর nonce-এর জন্য লাগে CSPRNG: আগের সব আউটপুট দেখেও পরেরটি অনুমান করা বাস্তবে অসম্ভব। Python-এ secrets, Node.js-এ crypto.randomBytes, browser-এ crypto.getRandomValues, Java-তে SecureRandom, Go-তে crypto/rand, PHP-তে random_bytes.

তুলনা: সময়ও তথ্য ফাঁস করে

ধরুন সিন্দুকের তালা প্রথম অঙ্ক ভুল হলেই সাথে সাথে শব্দ করে, দ্বিতীয় অঙ্ক ভুল হলে একটু পরে। শব্দের সময় শুনেই কেউ এক এক অঙ্ক করে এগোতে পারত। সাধারণ == প্রথম অমিলেই থেমে যায়, তাই সময় বলে দেয় কতটা মিলেছে। MAC, token বা signature তুলনায় লাগে constant-time comparison: Python-এ hmac.compare_digest, Node.js-এ crypto.timingSafeEqual, Java-তে MessageDigest.isEqual, PHP-তে hash_equals, Go-তে subtle.ConstantTimeCompare. এই বিষয়ের ভিত্তি দেখুন পর্ব ৯-এ।

import hmac, math, random, secrets

# 1. random: same seed, same "token". Never use it for secrets.
one, two = random.Random(2026), random.Random(2026)
print("random A:", "%032x" % one.getrandbits(128))
print("random B:", "%032x" % two.getrandbits(128))

# 2. secrets: from the OS CSPRNG. Do not print real tokens; show only shape.
token = secrets.token_urlsafe(32)
print("secrets token length:", len(token), "chars from 32 random bytes")
print("two secrets tokens equal?", secrets.token_hex(32) == secrets.token_hex(32))

# 3. How much guessing room?
print("6-digit code bits:", round(math.log2(10**6), 1))
print("32-byte token bits:", 32 * 8)

# 4. Early-exit compare leaks HOW FAR the match went (toy counter, no timing).
def toy_equal(a, b):
    steps = 0
    for x, y in zip(a, b):
        steps += 1
        if x != y:
            return False, steps
    return len(a) == len(b), steps

stored = "example-sig-7f3a"
for guess in ("Xxample-sig-7f3a", "example-Xig-7f3a", "example-sig-7f3X"):
    print(guess, "toy steps:", toy_equal(stored, guess)[1],
          "| compare_digest:", hmac.compare_digest(stored, guess))
print("match:", hmac.compare_digest(stored, "example-sig-7f3a"))

৯ · বিপজ্জনক API, safe default আর review-এর অভ্যাস

কিছু API হলো ধারালো ছুরি। এদের কাজই হলো লেখাকে কোড বানানো, বা বাইরের ডেটা থেকে object তৈরি করা। ভেতর থেকে আসা ডেটায় এগুলো চলে, কিন্তু সীমানার বাইরের ডেটা পেলেই বিপদ।

Library বাছাইয়ের সময় safe default দেখুন। ডিফল্টে নিরাপদ পথ থাকলে ভুলে যাওয়া কোনো বিপদ আনে না। তবে নিজে যাচাই করুন, কারণ ডিফল্ট সবসময় নিরাপদ নয়। যেমন Jinja2-তে auto-escaping নিজে থেকে চালু থাকে না, যদিও Flask সাধারণত চালু করে দেয়। Python-এর requests-এ timeout না দিলে কোনো সময়সীমা থাকে না। তাই প্রতিটি নতুন library-তে দেখুন: TLS যাচাই, timeout, escaping আর আকার সীমার ডিফল্ট কী?

Linter আর type system — যন্ত্রকে পাহারায় বসান

মানুষ ক্লান্ত হয়, যন্ত্র হয় না। Linter আর SAST tool কোড না চালিয়েই বিপজ্জনক ধরন খোঁজে: Python-এ Bandit বা Ruff, বহু ভাষায় Semgrep, C-তে compiler-এর -Wall -Wextra -Wconversion. এগুলো উদাহরণ মাত্র, আর false positive থাকবেই। বিস্তারিত পর্ব ৪৯-এ।

Type system আরও শক্ত দেয়াল। Amount, UserId বা TrustedHtml-এর মতো আলাদা ধরন থাকলে “যাচাই না হওয়া মান sink-এ গেল” ভুলটি build-এর সময়ই ধরা পড়ে। Browser-এর Trusted Types ঠিক এই চিন্তার ফল। আর Rust-এর মতো ভাষা অনেক মেমরি ত্রুটি compile-এর সময়েই আটকায়।

Code review — একটি ভুল থেকে একটি নিয়ম

একটি ভুল ঠিক করলে একটি ঘর বাঁচে। ভুলটি থেকে নিয়ম বানালে পুরো মহল্লা বাঁচে। নিচে একটি pull request-এর review থেকে স্থায়ী নিয়ম হওয়ার পথ দেখুন।

token = str(random.random())
send_reset_link(user, token)

CWE-338
Use of Cryptographically Weak PRNG
প্রভাব: reset token অনুমানযোগ্য হতে পারে

token = secrets.token_urlsafe(32)
send_reset_link(user, token)

def test_tokens_are_long_and_unique():
    tokens = {new_token() for _ in range(1000)}
    assert len(tokens) == 1000
    assert all(len(t) >= 43 for t in tokens)

$ grep -rnE 'random\.(random|randint|choice)\(' src/
src/invite.py:18: code = random.randint(0, 999999)
src/banner.py:7:  tip = random.choice(tips)

rules:
  - id: no-random-for-tokens
    languages: [python]
    severity: ERROR
    message: Use the secrets module for tokens
    pattern-either:
      - pattern: random.random(...)
      - pattern: random.randint(...)

CI: নতুন নিয়ম চলে, ভাঙলে merge বন্ধ
Checklist: “নতুন token কি CSPRNG থেকে?”
ব্যতিক্রম: কারণসহ লেখা, যেমন banner.py

প্রতিটি পরিবর্তনে এই দশটি প্রশ্ন করতে পারেন। বিস্তারিত পদ্ধতি আছে code review পর্বে।

1. নতুন কোনো trust boundary তৈরি হলো? সেখানে parse আছে?
2. প্রতিটি sink-এ প্রসঙ্গের সঠিক encoding বা bind আছে?
3. Authentication আর authorization প্রতিটি পথে আছে? (পর্ব ৩৮)
4. সংখ্যা আর আকারের সীমা, শূন্য আর ঋণাত্মক মান ভাবা হয়েছে?
5. যাচাই আর কাজের মাঝে ফাঁক আছে? দুটি অনুরোধ একসাথে এলে?
6. আকার, সময় আর সংখ্যার সীমা আছে? Regex কি নিরাপদ?
7. Error হলে দরজা বন্ধ থাকে? কোনো exception গিলে ফেলা হয়েছে?
8. Log বা error-এ secret বা ব্যক্তিগত তথ্য গেল?
9. Secret, token, nonce আর তুলনা ঠিক পদ্ধতিতে হচ্ছে?
10. বিপজ্জনক API, নতুন dependency বা বন্ধ করা নিরাপত্তা আছে?

SEI CERT আর CWE Top 25

দুটি উৎস মনে রাখুন। SEI CERT coding standards Carnegie Mellon-এর Software Engineering Institute-এর ভাষাভিত্তিক নিয়মের সংকলন: C, C++, Java, Android আর Perl. INT32-C বলে signed overflow ঠেকাতে, INT31-C বলে রূপান্তরে ডেটা না হারাতে, FIO45-C বলে ফাইলে TOCTOU এড়াতে, MSC30-C বলে rand() ব্যবহার না করতে, আর ENV33-C বলে system() না ডাকতে। অর্থাৎ এই পর্বের প্রায় সব অভ্যাসের একটি লিখিত নিয়ম আছে, যা দলে মানদণ্ড হিসেবে নেওয়া যায়।

CWE Top 25 হলো MITRE-র বার্ষিক তালিকা, প্রকাশিত CVE ডেটা থেকে হিসাব করা। ৩১ অক্টোবর ২০২৬-এর যাচাই অনুযায়ী সর্বশেষ সংস্করণ ২০২৫-এরটি, প্রকাশ ডিসেম্বর ২০২৫, প্রায় ৩৯ হাজার CVE রেকর্ড থেকে। পুরো তালিকা MITRE-র সাইটে দেখে নিন, কারণ প্রতি বছর ক্রম বদলায়।

তালিকায় না থাকা মানে নিরাপদ নয়। Integer overflow (CWE-190) আগের কয়েকটি তালিকায় ছিল, ২০২৫-এর তালিকায় নেই, কিন্তু ভুলটি হারিয়ে যায়নি। তালিকা ডেটা-নির্ভর, আপনার প্রকল্পের ঝুঁকি মাপে না। সেই কাজ করে threat modeling, আর পুরো প্রক্রিয়াটি পর্ব ৪৫-এর secure SDLC-এর অংশ।

১০ · AI-এর যুগে secure coding

AI খুব দ্রুত কাজের কোড লেখে। কিন্তু “চলছে” আর “নিরাপদ” এক জিনিস নয়, আর AI প্রায়ই প্রথমটি দেখিয়েই থেমে যায়। সে আপনার threat model জানে না, আর আপনার কোডের সীমানাও চেনে না। তাই এই পর্বের প্রশ্নগুলো আপনাকেই করতে হবে।

AI-এর কোড merge করার আগে

• প্রতিটি লাইন বুঝেছি, আর diff পড়েছি
• কোনো secret বা ব্যক্তিগত তথ্য prompt-এ পাঠাইনি
• কোনো নিরাপত্তা-যাচাই বন্ধ করা হয়নি
• অস্বাভাবিক input-এ চালিয়েছি: শূন্য, ঋণাত্মক, খুব বড়, বাংলা অঙ্ক, ফাঁকা
• Linter, SAST আর secret scanning পরিষ্কার
• প্রতিটি CVE, CWE আর library মূল উৎসে মিলিয়েছি
• মানুষের ওপর প্রভাব ফেলে এমন সিদ্ধান্ত একজন মানুষই নিচ্ছেন