দুটি অ্যাকাউন্ট দিয়ে API-র authorization bug পরীক্ষা
বেশিরভাগ গুরুতর API bug কে কী করতে পারে তা নিয়ে। সহজ matrix ও দুটি অ্যাকাউন্ট দিয়ে সাবধানে পরীক্ষা করুন এবং পরিষ্কারভাবে প্রমাণ করুন।
API অনেক অপারেশন খোলা রাখে, আর সবচেয়ে মূল্যবান bug সাধারণত authorization নিয়ে: server কি যাচাই করে এই user এই object-এ এই কাজ করতে পারে কি না। Scanner জানে না কী অনুমোদিত হওয়া উচিত, তাই সাবধান হাতে পরীক্ষা তাদের ফসকানো জিনিস ধরে।
যা দরকার
- আপনার বানানো দুটি সাধারণ test অ্যাকাউন্ট (A ও B বলুন), একই role-এর।
- অ্যাপে role থাকলে প্রতিটির জন্য একটি করে অ্যাকাউন্ট (যেমন user ও admin), শুধু যেখানে প্রোগ্রাম বানানোর অনুমতি দেয়।
- Request রেকর্ড ও replay করতে proxy (যেমন Burp)।
- লিখিত অনুমতি: API scope-এ আছে।
Permission matrix বানান
কাজ ও কার অনুমতি থাকা উচিত তার একটি ছক করুন।
| কাজ | বেনামী | User A (নিজের object) | User A (B-র object) | Admin |
|---|---|---|---|---|
| Invoice দেখা | না | হ্যাঁ | না | হ্যাঁ |
| Profile edit | না | হ্যাঁ | না | হ্যাঁ |
| সব user-এর তালিকা | না | না | না | হ্যাঁ |
না চিহ্নিত ঘরগুলোই আপনার পরীক্ষা। প্রতিটির জন্য server-কে অবশ্যই প্রত্যাখ্যান করতে হবে।
দুটি মূল যাচাই
১. Object-level authorization (BOLA / IDOR)। A কি B-র ID ব্যবহার করে B-র object পড়তে বা বদলাতে পারে?
- B হিসেবে একটি object বানিয়ে তার ID লিখে রাখুন।
- A হিসেবে B-র ID-র জন্য request পাঠান (দেখা, আপডেট, মোছা)।
- প্রত্যাশিত: 403 বা 404। Bug: B-র data-সহ 200, বা সফল বদল।
২. Function-level authorization। সাধারণ user কি admin ফাংশন ডাকতে পারে? আপনার পাওয়া API path দেখুন (JavaScript পড়া দেখুন), সাধারণ user-এর token দিয়ে admin-গুলো চেষ্টা করুন এবং দেখুন server প্রত্যাখ্যান করে কি না।
আরও যা যাচাই করবেন
- Authentication ছাড়া access: token সরিয়ে request আবার পাঠান।
- একই path-এ ভিন্ন HTTP method (
GETঅনুমোদিত কিন্তুDELETEঅসুরক্ষিত)। - Mass assignment: API কি request body-তে
roleবাisAdmin-এর মতো বাড়তি ফিল্ড নিয়ে প্রয়োগ করে? - নতুন যাচাই এড়াতে পারে এমন API-র পুরোনো সংস্করণ।
- শুধু URL-এ নয়, body ও header-এও ID।
- পরোক্ষ রেফারেন্স: অন্য user-এর data ফেরত দেওয়া list endpoint, export ও report।
Repeater ব্যবহার ও তুলনা
User A হিসেবে একটি request রেকর্ড করুন। Repeater-এ B-র identifier বা token বসিয়ে পাঠান, এবং প্রত্যাশিত উত্তরের সাথে তুলনা করুন। একবারে একটি জিনিস বদলান, যাতে বোঝেন কী কারণে ফল।
নিরাপদ proof
- দেখান আপনার নিজের অ্যাকাউন্ট A আপনার নিজের অ্যাকাউন্ট B-র data দেখেছে, আসল গ্রাহকের নয়।
- কোনো পরীক্ষা আসল user-দের প্রকাশ করতে পারলে (যেমন ক্রমিক ID) enumerate করবেন না। একটি উদাহরণে প্রমাণ করে report করুন।
- Report-এর জন্য request ও response (সংবেদনশীল মান সরিয়ে) রাখুন।
- যে data আপনার নয় তা কখনো বদলাবেন বা মুছবেন না।
Report করা
কোন নিয়ম ভাঙা হয়েছে বলুন ("invoice শুধু তার মালিকের দেখার কথা"), সঠিক request দিন, অপ্রত্যাশিত response দেখান, প্রভাব বলুন এবং সমাধান (server-side মালিকানা যাচাই) প্রস্তাব করুন। আমাদের report লেখার গাইড দেখুন।
মূল কথা: দুটি অ্যাকাউন্ট ও permission matrix ব্যবহার করুন, একবারে একটি বদল দিয়ে object-level ও function-level access পরীক্ষা করুন, আর শুধু নিজের test data দিয়ে প্রমাণ করুন।
বাগ বাউন্টি সিরিজ, পর্ব ২ (recon ও টুল): 5 নম্বর (মোট 5)। আগের লেখা: Web archive ও public উৎস: ভুলে যাওয়া পেজ সঠিকভাবে খোঁজা.
