শেয়ার করা সাবডোমেন, দুটি প্রবেশপথ: কে কোন রেকর্ড দেখে?

ক্লিনিক A এবং ক্লিনিক B একটি কোডবেস, দুটি সাবডোমেন এবং অফিস ও VPN দর্শনার্থীদের মিশ্রণ ভাগ করে নেয়। নেটওয়ার্ক দল সাধারণত দুটি প্রবেশপথ আলাদাভাবে কনফিগার করে, এবং এটি ঠিকই আছে, যতক্ষণ অ্যাপ্লিকেশন তা না করে। নিচের যাচাইগুলো অ্যাপ্লিকেশনেই থাকা উচিত এবং অনুরোধ কোন দরজা দিয়ে এসেছে তা নির্বিশেষে একইভাবে আচরণ করা উচিত।

প্রথম: হোস্টনাম কেবল একটি টেন্যান্টের নাম বলে

প্রশাসক যে ম্যাপিং রক্ষণাবেক্ষণ করেন তার সঙ্গে অনুরোধ করা হোস্টনাম মিলিয়ে দেখুন এবং অজানা কিছু বাতিল করুন। কাঁচা হেডারের বদলে ফ্রেমওয়ার্কের যাচাই করা হোস্ট মান ব্যবহার করুন, যাতে তৈরি করা Host কোনো লুকআপ কী ইনজেক্ট করতে না পারে। সফল মিল কোডকে বলে কোন টেন্যান্ট কনফিগারেশন ও ব্র্যান্ডিং লোড করতে হবে। তবে আহ্বানকারী ওই টেন্যান্টের ডেটা দেখতে পারবে কি না, তা এটি বলে না। দ্বিতীয় প্রশ্নটি আলাদা ইনপুটসহ আলাদা ফাংশনে রাখুন।

একটি হোস্টনাম লুকআপ থেকে একসঙ্গে কনটেক্সট ও অনুমতি ফেরানো কোনো শেয়ার করা হেল্পার ফাংশনই বাগের শুরু।

দ্বিতীয়: সদস্যপদ আসে সেশন থেকে

যাচাই করা ব্যবহারকারীর সক্রিয় সদস্যপদ খুঁজুন এবং প্রথম যাচাইয়ের টেন্যান্টের সঙ্গে তুলনা করুন। যে ব্যবহারকারী দুই ক্লিনিকেরই সদস্য তিনি সুইচ করতে পারেন, কিন্তু সুইচটি অনুরোধের কনটেক্সটে লিপিবদ্ধ একটি স্পষ্ট কাজ হওয়া উচিত, URL থেকে অনুমান নয়। যে ব্যবহারকারী এক ক্লিনিকের সদস্য এবং অন্যটি অনুরোধ করেন তিনি প্রত্যাখ্যাত হন, ডাউনলোড ও API কলসহ।

একটি রেকর্ড শনাক্তকারী ও একটি টেন্যান্ট প্যারামিটার সম্পাদনা করে নেতিবাচক কেসটি পরীক্ষা করুন। কোনো একটি পরিবর্তন ডেটা ফেরালে বোঝা যায় স্কোপ অনুরোধ থেকে পড়া হচ্ছে, যাচাই করা সদস্যপদ থেকে নয়।

কুকি স্কোপ ও একক সাইন-অন ঠিক করে অ্যাকাউন্ট কোথায় উপস্থাপন করা যায়। ওই অ্যাকাউন্ট কী পড়তে পারবে তা তারা ঠিক করে না।

তৃতীয়: নেটওয়ার্ক ব্যক্তি সম্পর্কে কিছুই প্রমাণ করে না

একটি VPN গেটওয়ে একটি টানেল প্রমাণ করে, আর একটি প্রকাশ্য অনুমোদন-তালিকা একটি ঠিকানা পরিসর প্রমাণ করে। কোনোটিই কোনো ব্যক্তিকে শনাক্ত করে না। NAT অনেক ব্যবহারকারীকে একটি উৎস ঠিকানায় ঠেলে দেয়, আর অফিস পরিসর ভবনের সবাইকে একইভাবে। দুটিকেই পরিবহন-তথ্য হিসেবে গণ্য করুন এবং অনুমোদন অ্যাপ্লিকেশনেই রাখুন, বা এমন ইন্টিগ্রেশনে রাখুন যা পরিচয় স্পষ্টভাবে দাবি করে এবং সেই হিসেবে পর্যালোচিত হয়।

DNS তৃতীয় পরিবহন-তথ্য। একটি ব্যক্তিগত উত্তর ব্যক্তিগত রুট দাবি করে, আর একটি প্রকাশ্য ফ্রন্টএন্ড সমর্থিত উৎস-পথ দাবি করে। এর কোনোটিই কোনো অনুমতি বহন করে না।

দেয়ালে রাখার মতো এক বাক্য: নেটওয়ার্ক ঠিক করে অনুরোধ কীভাবে আসে, আর অ্যাপ্লিকেশন ঠিক করে তা কী পড়তে পারে।

চতুর্থ: দুই প্রবেশপথেই ম্যাট্রিক্স চালান

নিয়ন্ত্রিত অ্যাকাউন্ট দিয়ে A-তে A, B-তে B, B-তে A, একটি অজানা হোস্টনাম এবং সদস্যপদহীন একটি যাচাই করা অ্যাকাউন্ট পরীক্ষা করুন। চতুর্থ ও পঞ্চমটি বন্ধভাবে ব্যর্থ হওয়া উচিত, কোনোভাবেই ডিফল্ট টেন্যান্টে পড়া উচিত নয়। একই ম্যাট্রিক্স VPN প্রবেশপথ দিয়েও চালান, প্রতিটি অ্যাকাউন্টের জন্য একটি সেশন জার নিয়ে:

curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-b.example.com/records/42
curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-a.example.com/records/42

তারপর অনুমোদন-তালিকার একটি এন্ট্রি বদলে আবার চালান। ফলাফল বদলালে বোঝা যায় একটি নেটওয়ার্ক নিয়ন্ত্রণ অনুমোদনের সিদ্ধান্ত নিচ্ছে।

ফ্রন্টএন্ডে যেকোনো পরিবর্তনের পরে ম্যাট্রিক্সটি পুনরাবৃত্তি করুন, কারণ যাচাই এড়িয়ে যাওয়া দ্বিতীয় কোড-পথই এই সীমা ক্ষয়ের সবচেয়ে সাধারণ উপায়। প্রত্যাশিত ফলাফল বিরক্তিকর: প্রতিটি প্রবেশপথ একই উত্তর দেয়।