عارضی IP اجازت فہرست کے لنکس: اجازت دراصل کیا قبول کرتی ہے

ایک کلک کو عارضی فائر وال قاعدے میں بدلنا سہولت بخش ہے، اور یہ ساتھ ہی ایک اجازت کا نظام بھی بناتا ہے جو طے کرتا ہے کہ کون کسی خدمت تک پہنچ سکتا ہے۔ یہ جو جاری کرتا ہے وہ شخص نہیں، پتہ ہے، اور یہ فرق اسی لمحے اہم ہوتا ہے جب دو لوگ ایک ہی NAT ساجھا کرتے ہیں۔ اجازت کا دائرہ محدود کریں، اس کی دانستہ توثیق کریں، اور لنک بننے سے پہلے اختتام کو معنی دیں۔ آپ کے سامنے فیصلہ یہ ہے کہ حد کہاں رکھی جائے، یہ نہیں کہ حد ہونی چاہیے یا نہیں۔

طے کریں کہ اجازت کس سوال کا جواب دیتی ہے

ضرورت سے شروع کریں۔ اگر کسی نامزد شخص کو خدمت تک پہنچنا ہے اور ایپلیکیشن پہلے ہی اس شخص کی توثیق کرتی ہے، تو توثیق شدہ گیٹ وے شناخت کو نفاذ کے مقام پر ہی رکھتا ہے اور پتے کی قبولیت کی کوئی ضرورت نہیں۔ اگر ہدف بلڈ ایجنٹ، انتظامی جمپ پورٹ یا ایسا آلہ ہو جو صارف کے لاگ ان میں شریک نہیں ہو سکتا، تو محدود دائرے کی پتہ اجازت ہی واحد عملی کنٹرول ہو سکتی ہے۔

صارفین کی طرف دیکھنے والی ایپلیکیشن کے لیے پتے کی قبولیت چننا اصل اجازت کا مسئلہ کہیں اور منتقل کر دیتا ہے، اور پھر پورٹل اس خلا کا الزام ورثے میں پاتا ہے جو اس نے کبھی بند نہیں کیا۔

سرور پر درخواست محدود کریں

براؤزر کو منزل، پورٹ یا سابقہ نہیں چننا چاہیے۔ پورٹل خدمت کو اپنے ہی ریکارڈ سے حل کرتا ہے اور حق کو سرور کی طرف کی جانچ سے پرکھتا ہے، یہ وہی اصول ہے جسے OWASP کی اجازت کی رہنمائی ہر درخواست پر لاگو کرتی ہے۔ پتے کا اخذ بھی محفوظ حد ہی میں آتا ہے: جب معکوس پراکسی گاہک کا پتہ بتائے، تو صرف ترتیب شدہ پراکسی زنجیر اور اس کے دستاویزی ہیڈر سلوک کو قبول کریں۔ مہمان کا فراہم کردہ فارورڈنگ ہیڈر اصل کے بارے میں دعویٰ ہے، اس کا ثبوت نہیں۔

پھر جانچیں کہ پورٹل اور خدمت ایک ہی ماخذ دیکھتے ہیں۔ منقسم ٹنلنگ، ایک پراکسی چھلانگ اور IPv4 بمقابلہ IPv6 دو منزلوں کو دو مختلف پتے دے سکتے ہیں، اس لیے ایک راستے سے فعال کی گئی اجازت اگلی درخواست کو نہ ڈھانپ سکے۔

نصب کرنے سے پہلے اجازت دکھائیں

لنک کھولنے پر تجویز کردہ خدمت، مشاہدہ شدہ ماخذ اور مدت دکھنی چاہیے، اور ابھی کچھ بھی نہ بدلنا چاہیے۔ وہی ایک قدم ای میل سے آیا لنک عمل سے تجویز میں بدل دیتا ہے، اور پیش منظر بوٹ یا میل اسکینر کو محض اسے لا کر رسائی دینے سے روکتا ہے۔

توثیق عام کراس سائٹ اور ماخذ دفاعوں کے ساتھ حالت بدلنے والی درخواست ہونی چاہیے۔ ٹوکن یک بار استعمال ہو اور قاعدہ نصب ہونے کے لمحے ہی جوہری طور پر خرچ ہو جائے، اور ریکارڈ مالک، خدمت، پتہ، اجازت شناخت کنندہ اور اختتام درج کرے، کچا ٹوکن کبھی لاگ کیے بغیر۔

ٹوکن کی ترسیل قاعدے جیسی ہی احتیاط مانگتی ہے۔ اختتام پذیر یا پہلے ہی خرچ شدہ لنک جو اب بھی قاعدہ بناتا ہے، اسی چابی سے لگا دوسرا دروازہ ہے۔

اجازت زندہ ہونے پر بھی پتہ مشترک ہے

دفتری NAT، کیریئر NAT اور مشترکہ VPN اخراج میں سے ہر ایک کئی لوگوں کو ایک پتے کے پیچھے رکھتا ہے۔ اس پتے کو قبول کرنا اس کے پیچھے موجود سب کو قبول کرنا ہے — جہاں تک خدمت کی اگلی حد کا تعلق ہے —، جبکہ اس بات کا کوئی ثبوت نہیں دیتا کہ خدمت جس کھاتے کی توقع رکھتی ہے وہ کس کے پاس ہے۔

قاعدہ ہٹانا بھی عالمگیر قطع تعلق نہیں ہے۔ قائم شدہ کنکشن، کیش شدہ ایپلیکیشن ٹوکن اور طویل المدتی سیشن قاعدے سے منٹوں یا اس سے بہت زیادہ عرصے تک زندہ رہ سکتے ہیں، اس لیے آپ کی چنی ہوئی عمر کو یہ نہیں بتانا چاہیے کہ قاعدہ کتنی دیر ہے، بلکہ یہ کہ قبولیت کے بعد خدمت کیا کرتی ہے۔

چار حالتوں اور دونوں پتہ خاندانوں کی جانچ کریں

اجازت اتنی ہی اچھی ہے جتنی چار حالتیں یہ برداشت کرتی ہے: نئی منظور شدہ درخواست، غیر منظور شدہ درخواست گزار، اسی لنک کی تکرار، اور اختتام کے بعد وہی درخواست۔

پھر ہر خاندان کو الگ الگ جانچیں، کیونکہ خدمت جو ماخذ پتہ دیکھتی ہے وہ ان کے درمیان مختلف ہو سکتا ہے۔

dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com

مفید نتیجہ عام صارف اجازت کے تحت ایک عارضی، قابلِ آڈٹ قبولیت کا فیصلہ ہے، نہ کہ پہلے کلک کرنے والے کا نام اٹھانے والا مستقل دروازہ۔