IDOR ও broken access control: যখন অন্যের data দেখা যায়
URL-এ একটি ID বদলে অন্য কারও invoice দেখা যায়। IDOR সহজ, সাধারণ ও গুরুতর। কীভাবে ঘটে ও কীভাবে ঠেকাবেন, জানুন।
IDOR (Insecure Direct Object Reference), API-তে যাকে BOLA (Broken Object Level Authorization)-ও বলে, এমন ত্রুটি যেখানে অ্যাপ request-এর একটি identifier দিয়ে object আনে, কিন্তু বর্তমান user সেটি দেখার অনুমতি পায় কি না যাচাই করে না।
এটি Broken Access Control-এর অংশ, যা OWASP তাদের ২০২১ Top 10-এ প্রথম স্থানে রেখেছিল।
একটি সহজ উদাহরণ
আপনি আপনার invoice খোলেন:
GET /api/invoices/1001
Server দেখে আপনি logged in, এবং invoice 1001 ফেরত দেয়। সংখ্যাটি 1002 করলে যদি অন্য গ্রাহকের invoice আসে, সেটি IDOR। অ্যাপ authentication (আপনি কে) যাচাই করেছে, কিন্তু authorization (এই invoice আপনার কি না) নয়।
কোথায় দেখা যায়
- URL ও API পথে ID:
/users/42,/orders/9001। - Request body ও query string-এ ID:
?account_id=7। - ফাইল download:
/download?file=report_12.pdf। - লুকানো ফর্ম ফিল্ড ও মোবাইল অ্যাপের API call।
- শুধু read নয়, কাজও: update, delete ও "role বদল" endpoint।
কেন এত সাধারণ
- ডেভেলপাররা user logged in কি না দেখে, কিন্তু প্রতি-object যাচাই ভুলে যায়।
- প্রতিটি নতুন endpoint-এ যাচাই লাগে, আর একটি ভুলে যাওয়া endpoint-ই যথেষ্ট।
- স্বয়ংক্রিয় scanner বুঝতে পারে না কোন object কার, তাই প্রায়ই পরীক্ষা বা review ছাড়া ধরা পড়ে না।
আসল সমাধান: প্রতিবার server-এ মালিকানা যাচাই
Query-তে user রাখুন, যাতে অনুমতি না থাকলে "পাওয়া যায়নি" হয়:
SELECT * FROM invoices WHERE id = $1 AND customer_id = $2; -- $2 হলো logged-in user
Row না এলে 404 বা 403 ফেরত দিন। সঙ্গতিপূর্ণ response দিন, যাতে আক্রমণকারী কোন ID আছে তা জানতে না পারে।
ভালো অভ্যাস
- Authorization কেন্দ্রীভূত করুন (policy স্তর, middleware বা database row-level security), যাতে প্রতিটি endpoint নতুন করে না বানায়।
- ডিফল্টে অস্বীকার। নতুন route স্পষ্টভাবে অনুমতি না দেওয়া পর্যন্ত নিষিদ্ধ থাকুক।
- User identity নিন session বা token থেকে,
user_id-এর মতো request ফিল্ড থেকে কখনো নয়। - Role-ভিত্তিক permission-ও যাচাই করুন (admin বনাম সাধারণ), read ও write দুটোতেই।
- প্রতিটি method (GET, PUT, DELETE) এবং সম্পর্কিত object (order-এর item, invoice-এর PDF)-এ যাচাই প্রয়োগ করুন।
- Test লিখুন যা user A হিসেবে login করে user B-র object পড়তে ও বদলাতে চেষ্টা করে, এবং ব্যর্থতা আশা করে।
যা যথেষ্ট নয়
- অনুমান-অযোগ্য ID (UUID) অনুমান কঠিন করে, কিন্তু log, লিংক ও ইমেইলের মাধ্যমে ফাঁস হয়, তাই এটি শুধু defence in depth।
- ইন্টারফেসে লিংক লুকানো।
- Client-side যাচাই। যে কেউ সরাসরি request পাঠাতে পারে।
বৈধভাবে পরীক্ষা
দুটি test অ্যাকাউন্ট দিয়ে আপনার নিজের অ্যাপ, বা লিখিত অনুমতি আছে এমন সিস্টেম (যেমন যে bug bounty program অনুমতি দেয়) পরীক্ষা করুন। যে আসল user-দের data দেখার অধিকার আপনার নেই তা দেখবেন না।
মূল কথা: প্রতিটি request server-এ authenticate ও authorize করুন, query বর্তমান user-এর মধ্যে সীমিত করুন, যাচাই কেন্দ্রীভূত করুন, এবং দুটি অ্যাকাউন্ট দিয়ে পরীক্ষা করুন।
ওয়েব সিকিউরিটি সিরিজ, পর্ব ১ (injection ও access control): 4 নম্বর (মোট 4)। আগের লেখা: CSRF: কীভাবে কাজ করে ও কীভাবে ঠেকাবেন.
