Brief #10 · Security
Multi-Tenant Data Isolation
Medium⏱ 10-14 ঘণ্টাশীঘ্রই
এমন bug খুঁজে বন্ধ করো, যেটা দিয়ে URL এর একটা সংখ্যা বদলে এক company আরেক company এর invoice পড়তে পারে।
Outline free · tracking সহ বানাতে Pro লাগবে
MBriefTeam এর পক্ষ থেকে
আমরা অনেক ছোট ব্যবসাকে একটা database এর ওপর invoicing tool বিক্রি করি। একজন security researcher email করেছেন: Company A হিসেবে login করে তিনি /invoices/1042 খুলেছেন আর Company B এর invoice দেখেছেন। এটা broken object-level authorization, API এর এক নম্বর ঝুঁকি। সব জায়গায় সারাও, আর নিশ্চিত করো এটা আর ফিরে আসতে পারবে না।
যা বানাবে
- 1একটা ছোট multi-tenant API (tenant, user, invoice), যেটা শুরুতে ইচ্ছা করে দুর্বল।
- 2Exploit টা automated test হিসেবে লেখো: user A tenant B এর data পড়ে, বদলায় আর মোছে।
- 3Application স্তরে সারাও: প্রতিটা query token এর tenant দিয়ে সীমাবদ্ধ।
- 4PostgreSQL row-level security দিয়ে দ্বিতীয় একটা দেয়াল যোগ করো।
- 5অন্য tenant এর ID তে 403 না, 404 দাও, আর কেন তা ব্যাখ্যা করো।
ধাপে ধাপে walkthrough
Walkthrough শীঘ্রই আসছে
এই project এর ধাপে ধাপে walkthrough, প্রতিটা ধাপে আসল output সহ, এখনো লেখা হচ্ছে। ততক্ষণ brief পড়ে নিজে চেষ্টা করতে পারো; walkthrough তৈরি হলে tracking চালু হবে।
শেষ হবে যখন
- প্রতিটা exploit test এখন অন্য tenant এর data ছুঁতে পারে না।
- Application এর check সরিয়ে দিলেও RLS পড়া আটকায়।
- কোনো নতুন endpoint tenant check বাদ দিলে একটা test CI fail করায়।
- Security advisory এর ধরনে একটা ছোট report।
আরো এগোতে চাইলে
- Tenant এর ভেতরে role (admin, accountant, viewer), একটা policy table সহ।
- ক্রমিক ID বদলে UUID দাও, আর ব্যাখ্যা করো কেন শুধু এটা সমাধান না।