Broken access control — IDOR আর server-এ অনুমতি যাচাই

১ · পরিচয়পত্র দেখা হলো, লকার মিলিয়ে দেখা হলো না

একটি ব্যাংকের লকার কক্ষের কথা ভাবুন। দারোয়ান পরিচয়পত্র দেখে আপনাকে ভেতরে যেতে দিলেন। ভেতরে গিয়ে আপনি একটি চাবি হাতে ৪২ নম্বর লকারের সামনে দাঁড়ালেন। লকারটি আপনার নয়, কিন্তু কর্মকর্তা খাতায় মিলিয়ে দেখলেন না, শুধু ভাবলেন “ভেতরে যখন এসেছেন, ঠিকই আছে।” দারোয়ানের কাজে কোনো ভুল ছিল না। ভুল ছিল পরের ধাপে, যেখানে কেউ জিজ্ঞেস করেনি: এই লকার কি এই মানুষের?

Broken access control ঠিক এই ভুল। Authentication বলে “আপনি কে”, আর authorization বলে “আপনি এখানে কী করতে পারেন”. RBAC, ABAC আর least privilege-এর নকশা পর্ব ১৯-এ দেখেছেন। সেখানে প্রশ্ন ছিল নিয়মটি কেমন হবে। এই পর্বের প্রশ্ন আলাদা: নিয়মটি লেখা আছে, কিন্তু কোডের প্রতিটি পথে সেটি সত্যিই প্রয়োগ হচ্ছে কি না।

কেন এটি তালিকার শীর্ষে

OWASP Top 10 হলো web application-এর প্রধান ঝুঁকির একটি সচেতনতা-তালিকা। পুরো তালিকা পর্ব ৩৭-এ পাবেন। ২০২১ সালে broken access control পঞ্চম স্থান থেকে উঠে প্রথমে আসে, আর ২০২৫ সংস্করণেও প্রথমেই আছে। OWASP-এর ২০২৫ পাতা অনুযায়ী পরীক্ষিত application-গুলোর সবকটিতে (১০০%) এর কোনো না কোনো রূপ মিলেছে, আর এই শ্রেণির সঙ্গে ৪০টি CWE যুক্ত। সংখ্যাগুলো অংশ নেওয়া প্রতিষ্ঠানের ডেটা থেকে এসেছে, তাই পুরো ইন্টারনেটের চিত্র হিসেবে নয়, একটি দিকনির্দেশ হিসেবে পড়ুন।

কারণগুলো গঠনগত, শুধু অসাবধানতা নয়:

• নিয়মটি প্রতিটি app-এর নিজস্ব। “অর্ডার তার মালিক দেখবেন” কথাটি কোডের ভাষায় কোথাও লেখা না থাকলে যন্ত্র বুঝবে কী করে? Injection-এর একটি চেনা আকৃতি আছে, মালিকানার নেই।
• ভুলটি অনুপস্থিতি। ত্রুটি কোনো খারাপ লাইনে নেই, একটি না-লেখা লাইনে। পড়ে ধরা কঠিন।
• সাধারণ ব্যবহারে কিছুই ভাঙে না। রিনা নিজের অর্ডারই দেখেন, তাই test পাস করে, গ্রাহক অভিযোগ করেন না।
• পথ অসংখ্য। একটি নতুন route, একটি পুরোনো API version বা একটি CSV export, যেকোনো একটিতে যাচাই বাদ পড়লেই যথেষ্ট।

২ · Horizontal আর vertical — অনুমতি ভাঙার দুই দিক

একটি কাল্পনিক অনলাইন বাজার ধরুন। রিনা আর মিতু গ্রাহক, কামাল admin. অনুমতি দুই দিকে ভাঙতে পারে। রিনা যদি মিতুর অর্ডার দেখতে পান, সেটি horizontal সমস্যা: পদ একই, কিন্তু অন্যের জিনিস। রিনা যদি refund দেওয়ার মতো admin কাজ করতে পারেন, সেটি vertical সমস্যা: নিজের চেয়ে ওপরের ক্ষমতা, যাকে elevation of privilege বলে।

একই ভাগ OWASP API Security Top 10 (২০২৩)-এ আরও সূক্ষ্মভাবে আছে। মিলিয়ে নিন, কারণ ইন্টারভিউতে এই নামগুলো প্রায়ই আসে:

৩ · IDOR — /orders/<id> যেখানে server মালিক দেখে না

IDOR মানে Insecure Direct Object Reference. কঠিন নামের পেছনের ঘটনাটি সহজ। অর্ডারের পাতার ঠিকানা /orders/1042. শেষের সংখ্যাটি database-এর একটি সারিকে সরাসরি চিহ্নিত করে। Server সেই সংখ্যা দিয়ে সারি এনে দেখিয়ে দেয়, কিন্তু সারিটি কার, তা মেলায় না। ঠিকানার সংখ্যা ব্যবহারকারীর হাতে থাকা একটি দাবি, আর server সেটিকে অনুমতি ধরে নিয়েছে।

পাশাপাশি দেখুন। দুই কোডেই login আছে, দুটিই ঠিকঠাক চলে, পার্থক্য একটি শর্তে। এগুলো Express-ধাঁচের pseudocode, চালানোর জন্য নয়:

app.get('/orders/:id', requireLogin,
  async (req, res) => {
    const order = await db.orders
      .findById(req.params.id);
    // কার অর্ডার, দেখা হলো না
    res.json(order);
  });

app.get('/orders/:id', requireLogin,
  async (req, res) => {
    const order = await db.orders.findOne({
      id: req.params.id,
      ownerId: req.session.userId,
    });
    if (!order) return res.status(404).end();
    res.json(order);
  });

নিরাপদ রূপে ownerId আসছে যাচাই করা session থেকে, URL বা form থেকে নয়। ?user=rina ধরনের মান দিয়ে পরিচয় ঠিক করলে আবার একই ভুল হবে। Session-এর ভিত্তি পর্ব ১৭-এ আছে। এবার একটি অনুরোধ ধাপে ধাপে দেখুন: রিনা login করা অবস্থায় এমন একটি অর্ডার চাইছেন, যা তাঁর নয়।

GET /orders/1043
Cookie: session=example-token

example-token -> user = rina
                 role = customer

SELECT * FROM orders
WHERE id = 1043
  AND owner = 'rina'

id    owner  item
1042  rina   Panjabi
1043  mitu   Saree
ফল: 0 সারি

HTTP 404 Not Found

event=order.not_visible user=rina
object=1043 status=404

এবার একই অনুরোধ দুই handler-এ চালিয়ে দেখুন। সবকিছু কয়েকটি JavaScript object-এ আছে; কোনো আসল server বা network নেই।

// কাল্পনিক দোকান: in-memory ডেটা, কোনো আসল network নেই
const orders = [
  { id: 1042, owner: 'rina', item: 'Panjabi', total: 1800 },
  { id: 1043, owner: 'mitu', item: 'Saree', total: 3500 },
];
const deny = (status) => ({ status });

// অনিরাপদ: login দেখে, মালিকানা দেখে না
function getOrderVulnerable(req) {
  if (!req.user) return deny(401);
  const o = orders.find((x) => x.id === req.id);
  return o ? { status: 200, body: o } : deny(404);
}

// নিরাপদ: মালিকানা lookup-এর শর্তের ভেতরে
function getOrderFixed(req) {
  if (!req.user) return deny(401);
  const o = orders.find((x) => x.id === req.id && x.owner === req.user);
  return o ? { status: 200, body: o } : deny(404);
}

const requests = [
  { user: 'rina', id: 1042 }, // নিজের অর্ডার
  { user: 'rina', id: 1043 }, // অন্যের অর্ডার
  { user: 'rina', id: 9999 }, // নেই এমন অর্ডার
  { user: null, id: 1042 },   // login ছাড়া
];
for (const [name, handler] of [['vulnerable', getOrderVulnerable], ['fixed', getOrderFixed]]) {
  console.log('--- ' + name + ' ---');
  for (const r of requests) {
    const res = handler(r);
    const leak = res.body ? ' owner=' + res.body.owner : '';
    console.log(`${r.user} GET /orders/${r.id} -> ${res.status}${leak}`);
  }
}

--- vulnerable ---
rina GET /orders/1042 -> 200 owner=rina
rina GET /orders/1043 -> 200 owner=mitu
rina GET /orders/9999 -> 404
null GET /orders/1042 -> 401
--- fixed ---
rina GET /orders/1042 -> 200 owner=rina
rina GET /orders/1043 -> 404
rina GET /orders/9999 -> 404
null GET /orders/1042 -> 401

৪ · লুকানো বোতাম সুরক্ষা নয় — function-level check আর forced browsing

অনেক app-এ customer-এর পর্দায় “Refund” বোতাম দেখা যায় না, তাই দল ধরে নেয় কাজটি সুরক্ষিত। কিন্তু বোতাম শুধু একটি অনুরোধ পাঠানোর সুবিধা। আসল দরজা server-এর route. Browser-এর পাতা, JavaScript আর mobile app ব্যবহারকারীর যন্ত্রে থাকে, তাই সেখানে থাকা যেকোনো যাচাই ব্যবহারকারীর নিয়ন্ত্রণে। বাড়ির সদর দরজায় পর্দা টানলে দরজা তালাবদ্ধ হয় না।

UI-তে বোতাম লুকানো ভালো অভ্যাস, কারণ মানুষ অপ্রয়োজনীয় বিকল্প দেখেন না। তবে এটি ব্যবহারযোগ্যতার কাজ, নিরাপত্তার নয়। নিয়ম মনে রাখুন: UI বলে কী দেখাবে, server বলে কী হবে।

Missing function-level check মানে কাজটির route-এ পদের যাচাই নেই। Flask-ধাঁচের pseudocode-এ দেখুন:

@app.post("/admin/refunds")
@login_required
def refund():
    # যেকোনো login করা মানুষ চালাতে পারেন
    return issue_refund(request.json)

@app.post("/admin/refunds")
@login_required
@require_permission("refund.create")
def refund():
    return issue_refund(request.json)

এই যাচাই handler-এর ভেতরে নয়, তার আগে বসানো ভালো। তখন handler-এর কোনো লাইন, কোনো database কল, কোনো ইমেইল শুরুই হয় না। Express-এ এই স্তরকে middleware বলে। নিচে দুটি অনুরোধ অনুসরণ করুন: প্রথমে customer রিনা, তারপর admin কামাল।

1function requireRole(role) {2  return (req, res, next) => {3    if (!req.user) return res.sendStatus(401);4    if (req.user.role !== role)5      return res.sendStatus(403);6    next();7  };8}9// handler-এর আগে role check10app.post('/admin/refunds',11  requireRole('admin'), issueRefund);

Forced browsing: ধারণাটি

Forced browsing মানে কোনো link অনুসরণ না করে সরাসরি একটি ঠিকানায় যাওয়া, যেমন admin পাতা, পুরোনো backup ফাইল বা ভুলে যাওয়া report. দলের ধারণা থাকে “এই পাতার link কোথাও নেই, তাই কেউ পাবে না”. এটি security through obscurity: ঠিকানা গোপন থাকাই একমাত্র বাধা। ঠিকানা কিন্তু ইতিহাস, log, JavaScript ফাইল আর পুরোনো ডকুমেন্টে ছড়িয়ে পড়ে। এর প্রতিকার গোপন ঠিকানা নয়:

• প্রতিটি পাতা আর ফাইলে একই অনুমতি যাচাই।
• Backup, metadata আর config ফাইল web root-এর বাইরে; directory listing বন্ধ।
• পুরোনো API version বন্ধ করা, আর সব route-এর একটি তালিকা রাখা।
• Production-এ debug আর test পথ না রাখা।

৫ · Mass assignment — যে ঘর form-এ ছিলই না

ধরুন profile form-এ দুটি ঘর: নাম আর শহর। কোডের সুবিধার জন্য অনেকে পুরো body সরাসরি user object-এ ঢেলে দেন। Object-এ কিন্তু role বা creditBalance-ও আছে। Form-এ না থাকলেও অনুরোধে ঘর যোগ করা যায়, কারণ অনুরোধের গঠনও ব্যবহারকারীর হাতে। এই ভুলের নাম mass assignment, আর ASP.NET জগতে একে over-posting বলে।

// কাল্পনিক ব্যবহারকারী আর অনুরোধ: in-memory ডেটা
const fresh = () => ({ name: 'Rina', city: 'Dhaka', role: 'customer', credit: 0 });
const body = { name: 'Rina Akter', city: 'Rajshahi', role: 'admin', credit: 500000 };

// অনিরাপদ: যা এলো, সব বসে গেল
function updateUnsafe(user, input) {
  Object.assign(user, input);
}

// নিরাপদ: শুধু allowlist-এর ঘর; বাকিগুলো বাদ, আর log
const EDITABLE = new Set(['name', 'city']);
function updateSafe(user, input) {
  const dropped = [];
  for (const [key, value] of Object.entries(input)) {
    if (EDITABLE.has(key)) user[key] = value;
    else dropped.push(key);
  }
  if (dropped.length) console.log('LOG dropped fields:', dropped.join(', '));
}

const a = fresh();
updateUnsafe(a, body);
console.log('unsafe:', JSON.stringify(a));

const b = fresh();
updateSafe(b, body);
console.log('safe:  ', JSON.stringify(b));

unsafe: {"name":"Rina Akter","city":"Rajshahi","role":"admin","credit":500000}
LOG dropped fields: role, credit
safe:   {"name":"Rina Akter","city":"Rajshahi","role":"customer","credit":0}

বাস্তবে এর জন্য আলাদা input DTO বা schema রাখা হয়, যেখানে শুধু লেখার অনুমতি থাকা ঘর ঘোষণা করা থাকে। উল্টো দিকের ভুলও আছে: পুরো object পাঠিয়ে দিয়ে UI-তে কিছু ঘর না দেখানো। Password hash বা অভ্যন্তরীণ নোট তখন response-এ চলে যায়, শুধু পর্দায় দেখা যায় না। তাই লেখার allowlist-এর মতো পড়ার allowlist-ও লাগে। OWASP API3:2023 এই দুই দিককে একসাথে ধরে। ২০১২ সালে GitHub-এর একটি প্রকাশিত ঘটনা এই ভুলের দিকে পুরো Rails জগতের নজর ফেরায়; ভাবনার প্রশ্ন ২-এ এর শিক্ষা আছে।

৬ · Multi-tenant ডেটা ফাঁস — পাশের ফ্ল্যাটের চাবি

Multi-tenancy-র ভিত্তি আর নকশার বিকল্প পর্ব ১৯-এ দেখেছেন: প্রতিটি query-তে tenant শর্ত, আর tenant আসবে যাচাই করা session থেকে। এখানে দেখি বাস্তবে ফাঁসটি হয় কোন পথে। Cross-tenant ত্রুটি হলো IDOR-এর সবচেয়ে দামি রূপ, কারণ একটি ভুলে এক প্রতিষ্ঠানের ডেটা আরেক প্রতিষ্ঠানে যায়।

মূল পাতায় শর্তটি সাধারণত থাকে। ফাঁস হয় পাশের পথে। সবচেয়ে সাধারণ উদাহরণ cache:

// দুই tenant-এর একই key
const key = `report:${month}`;
const data = await cache.get(key);

// tenant আসে session থেকে
const t = req.session.tenantId;
const key = `t:${t}:report:${month}`;
const data = await cache.get(key);

অনিরাপদ রূপে প্রথম প্রতিষ্ঠানের report cache-এ ঢোকে, আর একই মাসে দ্বিতীয় প্রতিষ্ঠান সেটিই পায়। Query নির্ভুল ছিল, ভুল হলো এক স্তর ওপরে। একই পরীক্ষা করুন search index, CSV export, background job, ইমেইল টেমপ্লেট, ফাইল storage-এর path আর WebSocket channel-এ।

হাতে লেখা শর্তের ওপর একটি নিরাপত্তা-জাল হলো row-level security, যেখানে database নিজেই ছাঁকে। PostgreSQL-এর একটি উদাহরণ, নিজের database-এ চেষ্টা করার জন্য:

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
ALTER TABLE invoices FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON invoices
  USING (tenant_id = current_setting('app.tenant_id')::uuid)
  WITH CHECK (tenant_id = current_setting('app.tenant_id')::uuid);

-- প্রতিটি transaction-এর শুরুতে, session-এর tenant দিয়ে
SET LOCAL app.tenant_id = '<tenant-id-from-session>';

এখানে দুটি ফাঁদ আছে। প্রথমত, table-এর মালিক সাধারণভাবে RLS এড়িয়ে যান, তাই FORCE দরকার; superuser আর BYPASSRLS role তবু এড়ায়, তাই app-কে সেই ক্ষমতা দেবেন না। দ্বিতীয়ত, connection pool-এ একটি connection বারবার ব্যবহার হয়। মান SET LOCAL দিয়ে transaction-এর ভেতরে না রাখলে আগের অনুরোধের tenant পরের অনুরোধে থেকে যেতে পারে। Database-স্তরের আরও অনুমতি দেখুন DBMS কোর্সের database নিরাপত্তা পর্বে।

৭ · Business logic ত্রুটি — দাম আর পরিমাণ server নিজে হিসাব করে

কিছু ত্রুটিতে অনুমতি ঠিক, প্রবেশও বৈধ, কিন্তু কাজের মান বা ক্রম ব্যবসার নিয়ম ভাঙে। রিনা নিজের cart-ই সাজাচ্ছেন, কিন্তু অনুরোধে দাম ১৮০০-র বদলে অন্য সংখ্যা, বা পরিমাণ ঋণাত্মক এলে কী হবে? এগুলো business logic flaw. কোনো চেনা আকৃতি নেই, কারণ প্রতিটি মান ব্যাকরণে বৈধ। “-1” একটি ঠিকঠাক সংখ্যা, শুধু দোকানের নিয়মে অর্থহীন।

নিয়মটি সরল: client জানাবে ইচ্ছা, server ঠিক করবে মূল্য। Hidden field-এর দাম, cart-এর যোগফল, ছাড়ের হার, ডেলিভারি চার্জ, কিছুই client থেকে নেবেন না। নিচের toy checkout দেখুন। টাকা রাখা হয়েছে পয়সায়, পূর্ণসংখ্যায়, কারণ দশমিক সংখ্যায় হিসাব গোলাকার ভুল আনে।

// দাম পয়সায়, server-এর নিজের তালিকায়। কোনো আসল পেমেন্ট নেই
const CATALOG = new Map([['panjabi', 180000], ['saree', 350000]]);
const COUPONS = new Map([['EID10', 10]]); // শতাংশ ছাড়
const MAX_QTY = 10;

function checkout(cart) {
  let subtotal = 0;
  for (const line of cart.items) {
    if (!CATALOG.has(line.sku)) return 'REFUSED unknown item';
    const { qty } = line;
    if (!Number.isInteger(qty) || qty < 1 || qty > MAX_QTY) {
      return `REFUSED bad quantity ${qty}`;
    }
    subtotal += CATALOG.get(line.sku) * qty; // line.unitPrice ব্যবহার হয়নি
  }
  const percent = COUPONS.get(cart.coupon) ?? 0;
  const total = subtotal - Math.floor((subtotal * percent) / 100);
  const flag = cart.clientTotal === total ? '' : ' (LOG price mismatch)';
  return `OK charge ${total / 100} taka${flag}`;
}

const carts = [
  { items: [{ sku: 'panjabi', qty: 2 }], clientTotal: 360000 },
  { items: [{ sku: 'panjabi', qty: 2, unitPrice: 100 }], clientTotal: 200 },
  { items: [{ sku: 'saree', qty: 1 }], coupon: 'EID10', clientTotal: 315000 },
  { items: [{ sku: 'saree', qty: 1 }], coupon: 'FAKE99', clientTotal: 35000 },
  { items: [{ sku: 'saree', qty: -1 }], clientTotal: -350000 },
  { items: [{ sku: 'panjabi', qty: 1.5 }], clientTotal: 270000 },
];
carts.forEach((c, i) => console.log(`cart ${i + 1}: ${checkout(c)}`));

cart 1: OK charge 3600 taka
cart 2: OK charge 3600 taka (LOG price mismatch)
cart 3: OK charge 3150 taka
cart 4: OK charge 3500 taka (LOG price mismatch)
cart 5: REFUSED bad quantity -1
cart 6: REFUSED bad quantity 1.5

একই পরিবারের আরও কিছু ত্রুটি:

• ধাপ এড়ানো: Payment ধাপ পার না করেই “অর্ডার সম্পন্ন” route-এ যাওয়া। Server-এ অর্ডারের অবস্থা (state) রাখুন, আর শুধু বৈধ পরিবর্তন মানুন।
• পেমেন্ট মিলিয়ে না দেখা: Gateway-র “success” বার্তায় টাকার পরিমাণ, মুদ্রা আর অর্ডার নম্বর মেলানো, আর বার্তাটি সত্যিই gateway-র কি না যাচাই করা।
• একই coupon বারবার: দুটি অনুরোধ একসাথে এলে race condition হতে পারে। Database-এর unique constraint বা atomic update দিয়ে একবার-ব্যবহার নিশ্চিত করুন।
• সীমার যোগফল: প্রতিদিনের transfer সীমা প্রতিটি অনুরোধে আলাদা না দেখে দিনের মোট যোগফলে দেখুন।

৮ · প্রতিরক্ষার নকশা — deny by default আর এক জায়গায় enforcement

প্রতিটি route-এ হাতে যাচাই লেখার ভরসায় থাকলে একদিন একটি বাদ পড়বেই। তাই ভুলকে নিরাপদ দিকে ঠেলে দিতে হবে। লক্ষ্য হলো: যাচাই বাদ পড়লে ফল হবে “প্রবেশ নেই”, “সবার জন্য খোলা” নয়।

Deny by default আর central enforcement

Deny by default মানে প্রকাশ্য বলে ঘোষণা করা ছাড়া সবকিছু বন্ধ। Enforcement এক জায়গায় থাকলে নিয়ম এক ভাষায় লেখা যায়, পড়া যায়, পরীক্ষা করা যায়। এই বিন্দুকে পর্ব ১৯-এ PEP বলেছি। নিচের ধরনে route বসাতেই policy লাগে:

// policy ছাড়া route বসলে app চালুই হবে না
function route(method, path, { policy, handler }) {
  if (typeof policy !== 'function') {
    throw new Error(`no policy: ${method} ${path}`);
  }
  app[method](path, (req, res) => {
    if (!policy(req.user, req)) return res.status(403).end();
    return handler(req, res);
  });
}

// "প্রকাশ্য" হওয়াও একটি স্পষ্ট সিদ্ধান্ত
route('get', '/health', { policy: policies.isPublic, handler: health });
route('post', '/refunds', {
  policy: policies.can('refund.create'),
  handler: refund,
});

এখানে ভুলে policy না দিলে ত্রুটি ধরা পড়ে app চালুর সময়, production-এ নয়। Framework-এ একই কাজ করে global authentication filter বা declarative annotation. যেটিই বেছে নিন, লক্ষ্য একই: খোলা রাখতে হলে সেটি লিখে জানাতে হবে।

মালিকানা query-র ভেতরে, পরে নয়

আগে সারি এনে পরে if দিয়ে মেলানো কাজ করে, কিন্তু query-তে শর্ত বসানো তিন কারণে ভালো:

• ভোলা কঠিন: current_user.orders ধরনের স্কোপ থেকে শুরু করলে অন্যের সারি হাতেই আসে না। Rails-এর association আর Django-র get_object_or_404(Order, pk=id, owner=request.user) এই ধারার উদাহরণ।
• তালিকায় ফাঁস নেই: পাতায় ২০টি সারি এনে পরে ছাঁকলে কোনো পাতা ফাঁকা বা ছোট আসে, আর মোট সংখ্যা অন্যের ডেটার আভাস দেয়।
• লেখার কাজ atomic: যাচাই আর পরিবর্তন এক statement-এ হয়। মাঝখানে অবস্থা বদলের ফাঁক (TOCTOU) থাকে না।

order = db.get_order(order_id)
if order.owner_id != current_user.id:
    abort(403)
if order.status == "open":
    db.set_status(order_id, "cancelled")

rows = db.execute(
    "UPDATE orders SET status = 'cancelled' "
    "WHERE id = ? AND owner_id = ? "
    "AND status = 'open'",
    (order_id, current_user.id)).rowcount
if rows == 0:
    abort(404)

ব্যতিক্রমও আছে। জটিল নিয়মে, বা যেখানে policy engine বস্তুর গুণ দেখে সিদ্ধান্ত নেয়, আগে সারি পড়তেই হয়। তখনও সিদ্ধান্ত হবে ফল পাঠানোর আগে, আর কোনো লেখা হবে সিদ্ধান্তের পরে।

অনুমান-অযোগ্য ID: বাড়তি স্তর, প্রতিকার নয়

১০৪২-এর বদলে UUID ব্যবহার করলে পরের ID আন্দাজ করা কঠিন হয়, তাই ঠিকানা ধরে একের পর এক খোঁজা অকেজো হয়। এটি ভালো defense in depth, তবে অনুমতি নয়। ID গোপন কিছু নয়: তা URL, ইমেইল, log, browser history আর স্ক্রিনশটে ঘোরে। একবার কারও হাতে গেলে মালিকানা যাচাই ছাড়া আর কোনো বাধা নেই। লকারের নম্বর ছাপা না থাকলে সুবিধা আছে, তবু তালা তো লাগবেই।

৯ · পরীক্ষা, log আর alert — যাচাই যে সত্যিই আছে, তার প্রমাণ

নিয়ম লেখা আছে বলে সেটি কাজ করছে, এমন নয়। অনুমোদন-ছক হলো একটি টেবিল: সারিতে route, কলামে ব্যবহারকারীর ধরন, ঘরে প্রত্যাশিত status. এটি পর্ব ১৯-এর access control matrix-এর পরীক্ষাযোগ্য রূপ। ভালো ছকে “নেতিবাচক” ঘর বেশি থাকে: অন্য ব্যবহারকারী, অন্য tenant, login ছাড়া।

route                 anon rina mitu kamal
GET /orders/1042       401  200  404  200
DELETE /orders/1042    401  403  403  200
GET /admin/users       401  403  403  200

route                 anon rina mitu kamal
GET /orders/1042       401  200  404  200  pass
DELETE /orders/1042     ·    ·    ·    ·
GET /admin/users        ·    ·    ·    ·

route                 anon rina mitu kamal
GET /orders/1042       401  200  404  200
DELETE /orders/1042    401  200   ·    ·
চাওয়া 403, পাওয়া 200: FAIL

route                 anon rina mitu kamal
GET /orders/1042       401  200  404  200
DELETE /orders/1042    401  200  200  200
দুই customer-ই মুছতে পারছেন

GET /admin/users       401  403  403  200  pass
10/12 passed
CI: RED, merge blocked

DELETE /orders/1042 + requireRole('admin')
DELETE /orders/1042    401  403  403  200  pass
12/12 passed
CI: GREEN

এবার একই ছক কোডে চালান। Test ফাইলের নিচে একটি বাড়তি পরীক্ষাও আছে: app-এর এমন route, যার সারি ছকে নেই। এটি ছাড়া নতুন route চুপচাপ পরীক্ষার বাইরে থেকে যায়। এই ধরনের test প্রতিটি পরিবর্তনে Continuous Integration-এর ধাপে চলে।

// কাল্পনিক app: কোনো আসল server বা network নেই
const owner = { 1042: 'rina' };
const roles = { rina: 'customer', mitu: 'customer', kamal: 'admin' };
const login = (u, next) => (u ? next() : 401);
const app = {
  'GET /orders/1042': (u) => login(u, () =>
    (u === owner[1042] || roles[u] === 'admin' ? 200 : 404)),
  // বাগ: login দেখা হয়েছে, admin পদ দেখা হয়নি
  'DELETE /orders/1042': (u) => login(u, () => 200),
  'GET /admin/users': (u) => login(u, () => (roles[u] === 'admin' ? 200 : 403)),
  'GET /reports/export': (u) => login(u, () => 200), // ছকে সারি নেই
};

const actors = [null, 'rina', 'mitu', 'kamal'];
const matrix = {
  'GET /orders/1042':    [401, 200, 404, 200],
  'DELETE /orders/1042': [401, 403, 403, 200],
  'GET /admin/users':    [401, 403, 403, 200],
};

let total = 0, failed = 0;
for (const [route, expected] of Object.entries(matrix)) {
  actors.forEach((actor, i) => {
    const got = app[route](actor);
    total += 1;
    if (got !== expected[i]) {
      failed += 1;
      console.log(`FAIL ${route} as ${actor}: want ${expected[i]}, got ${got}`);
    }
  });
}
const untested = Object.keys(app).filter((r) => !(r in matrix));
untested.forEach((r) => console.log(`UNTESTED ${r}`));
console.log(`${total - failed}/${total} passed, ${untested.length} untested`);
console.log(failed || untested.length ? 'CI: RED, merge blocked' : 'CI: GREEN');

FAIL DELETE /orders/1042 as rina: want 403, got 200
FAIL DELETE /orders/1042 as mitu: want 403, got 200
UNTESTED GET /reports/export
10/12 passed, 1 untested
CI: RED, merge blocked

নিজের app-এ দুই ব্যবহারকারী হয়ে পরীক্ষা

স্বয়ংক্রিয় test-এর পাশাপাশি হাতের পরীক্ষাও কাজের, বিশেষ করে নতুন feature-এ। Staging পরিবেশে দুটি test account বানান, ক ও খ, প্রয়োজনে দুটি tenant-এ। ক-এর প্রতিটি কাজ করার সময় ঠিকানা আর অনুরোধগুলো লিখে রাখুন। তারপর খ হয়ে একই বস্তুর অনুরোধ দিন। প্রত্যাশা: খ কিছুই পাবেন না। এটি নিজের সিস্টেমে, নিজের নকল ডেটায়। অন্যের সিস্টেমে এমন পরীক্ষা শুধু লিখিত অনুমতিতে, যার নিয়ম পর্ব ৫০-এ আছে।

প্রত্যাখ্যান log করুন, alert দিন

একটি 403 সাধারণ ঘটনা, হয়তো পুরোনো bookmark. কিন্তু একই ব্যবহারকারীর কয়েক মিনিটে অনেকগুলো ভিন্ন বস্তুতে প্রত্যাখ্যান সাধারণ নয়। এটি খুঁজে দেখার মতো সংকেত, যেমন আপনার মহল্লায় কেউ রাত জেগে একের পর এক দরজার হাতল ঘোরালে সন্দেহ হয়। OWASP-ও প্রতিরোধের তালিকায় access control ব্যর্থতা log করা আর admin-কে জানানোর কথা বলে। এর জন্য log-এ ঘরগুলো নির্দিষ্ট থাকা চাই:

{
  "time": "2026-10-31T14:02:11Z",
  "event": "authz.denied",
  "user_id": "u_2041",
  "tenant_id": "t_17",
  "action": "order.read",
  "object_id": "1043",
  "route": "GET /orders/:id",
  "status": 404,
  "source_ip": "203.0.113.24"
}

একটি সূক্ষ্ম কথা: query-তে মালিকানা বসালে “অন্যের সারি” আর “সারি নেই” একই ফল দেয়। তাই একটি বস্তু-খোঁজা route-এর 404-ও এই log-এ লিখুন, নইলে যে সংকেত দরকার, সেটিই হারাবে। Sigma-র correlation ধরনে নিয়মটি এমন হতে পারে। সংখ্যাগুলো ধরে নেওয়া; নিজের baseline দেখে ঠিক করবেন।

title: App authorization denied
name: app_authz_denied
status: experimental
logsource:
  category: application
  product: example-shop
detection:
  selection:
    event: authz.denied
  condition: selection
level: low
---
title: One user denied on many different objects
correlation:
  type: value_count
  rules:
    - app_authz_denied
  group-by:
    - user_id
  timespan: 10m
  condition:
    field: object_id
    gte: 20
level: high

Alert এলে কী করবেন: প্রথম প্রশ্ন “চেষ্টা হয়েছে?” নয়, “কোনো অনুরোধ সফল হয়েছে?” একই user-এর সফল অনুরোধে এমন বস্তু খুঁজুন, যা তাঁর নয়। সফল হলে এটি সম্ভাব্য ডেটা ফাঁস: account বা token বন্ধ করা, প্রমাণ রাখা, ত্রুটি সারানো, কার ডেটা গেছে তা হিসাব করা, আর আইন বা চুক্তি অনুযায়ী জানানোর প্রশ্ন আইনজীবীকে করা। Incident response-এর পুরো ধারা পর্ব ৬১-এ পাবেন। Rate limit-ও বসান: এটি প্রতিকার নয়, তবে ক্ষতির গতি কমায়।

১০ · AI-এর যুগে অনুমতি যাচাই

AI খুব দ্রুত CRUD route লিখে দেয়, আর প্রশ্ন না করলে সাধারণত “কাজ করে” এমন সহজ রূপটি লেখে। সেই সহজ রূপে login থাকে, মালিকানা প্রায়ই থাকে না। কারণ বোধগম্য: আপনার ব্যবসার নিয়ম AI জানে না, আর কোডটি নমুনা ডেটায় ঠিকই চলে। তাই এই শ্রেণির ত্রুটি AI-যুগে কমবে, এমন ধরে নেওয়ার কারণ নেই।

AI-এর লেখা route হাতে পেলে

• পরিচয় আসছে যাচাই করা session থেকে, অনুরোধের body বা URL থেকে নয়
• Query-তে owner আর tenant শর্ত আছে, শুধু ID নয়
• লেখা আর পড়া, দুই দিকেই ঘরের allowlist আছে
• দাম, ছাড় আর যোগফল server-এ নতুন করে হিসাব হচ্ছে
• অন্য user, অন্য tenant আর login-ছাড়া test পাস করেছে, আর আমি নিজে সেই test পড়েছি
• Diff-এ কোনো check সরানো হয়নি, আর উল্লেখ করা CVE বা standard মূল উৎসে মিলিয়েছি
• Prompt-এ কোনো secret বা ব্যক্তিগত ডেটা পাঠাইনি; মানুষের ওপর প্রভাব ফেলে এমন সিদ্ধান্ত একজন মানুষ নিয়েছেন