باب اپنے درست اکاؤنٹ کے ذریعے لیب API میں سائن ان کرتا ہے، GET /invoices/inv_100 کی درخواست کرتا ہے، اور ایلس (Alice) کا انوائس (بل) حاصل کر لیتا ہے۔ حملہ آور نے نہ تو کوئی ٹوکن چرایا، نہ لاگ ان کے عمل کو بائی پاس کیا، اور نہ ہی پاس ورڈ کا اندازہ لگایا۔ باب نے روٹ (route) میں موجود آبجیکٹ شناخت کنندہ (object identifier) کو تبدیل کیا جسے سرور نے یہ چیک کیے بغیر قبول کر لیا کہ آیا inv_100 باب کی ملکیت ہے یا نہیں۔ لہٰذا، دفاع کرنے والے کے لیے سوال اس بات سے کہیں زیادہ مخصوص اور مفید ہے کہ آیا لاگ ان کام کر رہا ہے یا نہیں۔ کیا ہر درخواست کے لیے API یہ ثابت کرتا ہے کہ تصدیق شدہ صارف (principal) اس آبجیکٹ پر یہ عمل انجام دینے کا مجاز ہے؟
ہمارا زیرِ استعمال سسٹم ایک چھوٹی REST API ہے جس میں POST /login، GET /invoices/{invoiceId}، PUT /invoices/{invoiceId}، اور GET /admin/audit شامل ہیں۔ ایلس inv_100 کی مالک ہے، باب inv_200 کا مالک ہے، اور ایڈمنسٹریٹر آڈٹ ریکارڈز پڑھ سکتا ہے۔ ایک تھریٹ ماڈل (threat model) اس بات کی نشاندہی کرتا ہے کہ حملہ آور کا کن چیزوں پر پہلے سے کنٹرول ہے، درخواست کس حد (boundary) کو عبور کرتی ہے، حملہ آور کیا چاہتا ہے، اور سرور کا کون سا فیصلہ درخواست کو روکنے کا باعث بننا چاہیے۔ یہاں، باب کا اپنی تصدیق شدہ درخواست اور invoiceId پر کنٹرول ہے؛ وہ ایلس کا انوائس حاصل کرنا چاہتا ہے؛ لہٰذا ڈیٹا کے اسٹور سے باہر جانے سے پہلے ‘اجازت نامہ’ (authorization) کے عمل کو رسائی مسترد کر دینی چاہیے۔
تصدیقِ شناخت (Authentication) یہ ثابت کرتی ہے کہ درخواست باب کی طرف سے آئی ہے۔ تاہم، ‘اجازت نامہ’ (Authorization) کے عمل کو یہ فیصلہ کرنا ہوتا ہے کہ آیا باب inv_100 کو پڑھ سکتا ہے یا نہیں۔ ان فیصلوں کو ایک ہی جانچ (check) سمجھنا ناکامی کا باعث بنتا ہے، کیونکہ ایک درست شناخت ملکیت یا انتظامی استحقاق (privilege) کے بارے میں کچھ نہیں بتاتی۔ اس کورس کے دوران ہمارا مقصد اسی API کو مزید محفوظ بنانا اور یہ ثابت کرنا ہے کہ ہر حد (boundary) جانچ کے دوران اپنی حفاظت برقرار رکھتی ہے۔ درج ذیل نقشہ ان حدود کی نشاندہی کرتا ہے جنہیں باب عبور کرتا ہے۔
یہ خاکہ ظاہر کرتا ہے کہ کوئی درخواست (request) تصدیقِ شناخت (authentication) کے مرحلے سے تو گزر سکتی ہے لیکن اجازت (authorization) یا ڈیٹا تک رسائی کے مرحلے پر ناکام ہو سکتی ہے۔ ‘آبجیکٹ آئیڈینٹیفائر’ (object identifier) صرف تب خطرناک بنتا ہے جب API اسے کسی ریکارڈ کو حاصل کرنے کے لیے استعمال کرے، بغیر اس ریکارڈ کو تصدیق شدہ صارف (principal) کے ساتھ منسلک کیے۔
ملکیت کی جانچ (ownership check) کا فقدان OWASP API Security Top 10 2023 میں API1:2023 Broken Object Level Authorization (یا BOLA) کہلاتا ہے۔ کوئی بھی ایسا اینڈ پوائنٹ (endpoint) جو کلائنٹ کے زیرِ کنٹرول آبجیکٹ ID وصول کرتا ہے، اسے اس آبجیکٹ کے لیے اجازت (authorization) کے فیصلے کی ضرورت ہوتی ہے۔ GET /invoices/inv_100 اور PUT /invoices/inv_100 الگ الگ آپریشنز ہیں، لہذا ہر ایک کے لیے الگ فیصلے کی ضرورت ہوتی ہے، چاہے دونوں ایک ہی انوائس کا حوالہ دے رہے ہوں۔
دیگر ابتدائی خطرات بھی اسی درخواست کے راستے (request path) کے گرد گھومتے ہیں۔ API2:2023 Broken Authentication کا تعلق اس بات سے ہے کہ آیا API ‘باب’ (Bob) کی درست شناخت کرتا ہے یا نہیں۔ API3:2023 Broken Object Property Level Authorization کا تعلق اس بات سے ہے کہ آیا انوائس کے مجاز جواب (response) میں ایسے فیلڈز ظاہر یا قبول کیے جاتے ہیں جن تک ‘باب’ کو رسائی نہیں ہونی چاہیے، جیسے کہ اندرونی approvalLimit۔ API4:2023 Unrestricted Resource Consumption کا تعلق ‘باب’ کی جانب سے ایسی مہنگی (وسائل خرچ کرنے والی) درخواستیں بھیجنے سے ہے جو سسٹم کی صلاحیت ختم کر دیں یا ادائیگی والے ‘ڈاؤن اسٹریم’ (downstream) کام کو متحرک کر دیں۔ API5:2023 Broken Function Level Authorization کا تعلق ‘باب’ کی جانب سے انتظامی اجازت نہ ہونے کے باوجود GET /admin/audit تک رسائی حاصل کرنے سے ہے۔
ہر زمرہ درخواست کے ایک مختلف حصے کو تبدیل کرتا ہے، لیکن یہ سب اس بات کی جانچ کرتے ہیں کہ آیا سرور کلائنٹ کے ان پٹ، صرف ٹوکن، یا اینڈ پوائنٹ کے نام پر انحصار کرنے کے بجائے کسی حد (boundary) کا نفاذ کرتا ہے یا نہیں۔ یہ جدول حملہ آور کی تبدیلی، محفوظ کیے جانے والے نتیجے، اور دفاع کرنے والوں کو درکار شواہد کا جائزہ لیتا ہے۔