روابط قائمة السماح المؤقتة لعناوين IP: ما الذي تسمح به المنحة فعلاً
الرابط الذي يفتح منفذ جدار حماية يسمح بعنوان، لا بشخص. حدّد النطاق، واطلب تأكيدًا واعيًا، واختبر إعادة الاستخدام والانتهاء وIPv6.
إن تحويل نقرة واحدة إلى قاعدة جدار حماية مؤقتة أمر مريح، وهو يبني أيضًا نظام تفويض يقرر من يجوز له الوصول إلى خدمة. وما يُصدره هو عنوان لا شخص، وهذا الفرق يهمّ في اللحظة التي يتشارك فيها شخصان عنوان 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
النتيجة المفيدة هي قرار قبول مؤقت قابل للتدقيق يقع تحت تفويض المستخدم العادي، لا فتح دائم يحمل اسم من نقر أولًا.