ما الذي يمكن لبوابة ويب مخترقة أن تصل إليه؟
تحد البوابة الإلكترونية مما يفتحه الزائر، لا مما يمكن لمضيف مخترق أن يتصل به. مراجعتان وجدول صلاحيات وأوامر إثبات الوصول.
افترض أن مضيف البوابة قد اختُرِق بينما تظل شهادته صالحة. كل قاعدة كانت تحكم الصفحات التي يجوز للزائر طلبها تبقى سارية، ولا واحدة من تلك القواعد تقيّد الاتصال الذي يفتحه المهاجم الآن من ذلك المضيف نحو شبكة قاعدة البيانات الفرعية. هذه الفجوة هي سبب أن نقطة الدخول الشبكية فقط ليست الادعاء نفسه الذي تقدمه شبكة مقسّمة. يحتاج الادعان إلى مراجعتين منفصلتين، من نقطتي بداية مختلفتين، قبل أن يصح تقديم أي منهما بأمانة.
ادعان، وواحد منهما فقط يبدأ عند الزائر
الادعاء الأول يتعلق بشخص: زائر لديه متصفح وجلسة صالحة يمكنه فتح تطبيق واحد ولا شيء غير ذلك. نقطة دخول شبكية فقط تجيب عن هذا الادعاء جيدا، لأن الزائر يتلقى صفحة لا مسارا. هذه الإجابة جديرة بالاحتفاظ بها، وهي أيضا الادعاء الوحيد الذي تسجله معظم المخططات.
الادعاء الثاني يتعلق بمكوّن: يُفترض أن البوابة، أو عملية التطبيق خلفها، تحت سيطرة شخص آخر. انطلاقا من هذا الافتراض يتحول السؤال من أي عناوين URL مسموح بها إلى أي وجهات وهويات يمكن للعملية أن تصل إليها بعد ذلك.
للادعان مالكوان مختلفان، وينتجان أدلة مختلفة، ويفشلان باستقلال. يمكن لفريق الهوية أن يثبت الأول باختبار جلسة؛ أما الثاني فيحتاج إلى سياسة شبكية ومراجعة حساب خدمة وضوابط مضيف. التصميم الذي يسجل نصف الزائر فقط يبدو مكتملا على شريحة مراجعة وهزيلا أثناء حادثة، لأن الضوابط المهمة بعد الاختراق لم تكن أبدا داخل النطاق. سمِّ الادعاء الذي يدعمه كل ضابط، وإلا نُسبت قاعدة بوابة واحدة إلى كليهما.
خدمة مصاريف محلولة، والطريقتان التي تخسر بهما
خذ خدمة مصاريف: بوابة عامة على 10.60.4.10 تصادق الموظفين وتحوّل الطلبات المعتمدة إلى مستمع تطبيق على المنفذ 8443، ويصل ذلك التطبيق إلى مستمع PostgreSQL واحد على 10.60.4.20:5432 بصفتها الدور expenses_app. لا يُقصد أن يحصل الموظفون على وصول داخلي عام. في التشغيل الطبيعي يقدم التصميم بالفعل مدخلا خاصا بالتطبيق دون نشر مستمع قاعدة البيانات في أي مكان. العناوين مهمة، لأن كل فحص لاحق في هذه المقالة يسميها.
أزل البوابة الآن من المجموعة الموثوقة. ما الوجهات التي يمكن لـ 10.60.4.10 الوصول إليها متى صارت عمليتها ملكا لمهاجم؟ مرشح URL الذي قيّد الزوار لا يقول شيئا عن اتصال يفتحه مضيف البوابة نحو شبكة قاعدة البيانات الفرعية.
أزل عملية التطبيق بدلا من ذلك، فتتغير الصلاحية في شكلها: الدور expenses_app، والخدمات التي يمكن لذلك الخادم الوصول إليها، والملفات التي يستطيع ذلك الحساب قراءتها. في الحالتين يمكن أن يبقى الباب الأمامي شبكيا فقط بينما تكون حدود الواجهة الخلفية غائبة. لذا فإن اللافتة على الباب الأمامي ليست جوابا عن أي من السؤالين.
ارسم خريطة الصلاحية التي يملكها كل طرف فعلا
العقد المكتوب كأذونات مقصودة يميل إلى تكرار التصميم عليك. اكتبه كصلاحية مملوكة، والفحص الذي يبطل الزيادة، ومالك ذلك الفحص، فيصبح كل صف قابلا للاختبار. هذا الجدول اقتراح للمثال أعلاه، وليس ادعاء منتج:
| Component | Authority it actually holds | Check that proves the denial | Owner of the check |
|---|---|---|---|
| Identity provider | Issues assertions and session cookies, and holds no network path of its own | A request to the application URL without a session is redirected to the login page | Identity team |
| Public gateway host | TCP reachability to whatever its routing table and egress rules permit | An egress rule drops 10.60.4.20:5432 and the probe reports the port filtered | Network platform team |
| Application role | SQL privileges granted to expenses_app inside the expenses database | A privilege query shows no ownership or create right on any other schema | Application team |
| Database listener | Accepts connections only from the source ranges named in its host-based rules | A connection from an unlisted address is refused before authentication | Database administrator |
| Management path | Administrative access reserved for patching, monitoring and recovery | A staff workstation cannot reach the administrative port or jump through it | Platform owner |
الملكية تتبع الصلاحية. فريق الهوية يملك التأكيدات، وفريق منصة الشبكة يملك المسارات، وفريق التطبيق يملك دور قاعدة البيانات، ومسؤول قاعدة البيانات يملك المستمع وقواعده القائمة على المضيف، ومالك المنصة يملك مستوى الإدارة. الرفض بلا مالك جملة في وثيقة لا ضابط.
كما يمنع التقسيم العد المزدوج. لا يمكن لقيد منفذ أن يعبر عن امتياز جدول، ولا يمكن لدور قاعدة بيانات أن يمنع مضيفا من فتح مقبس نحو شبكة فرعية غير ذات صلة.
عدّد ما يمكن للبوابة الوصول إليه بدلا من تأكيده
لا يكون ادعاء الحدود أفضل من التعداد الذي يقوم عليه. على مضيف البوابة تغطي ثلاثة أوامر اختيار المسار وفحصا حيا وسياسة الخروج:
ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter outputاقرأ الخرج بهذا الترتيب. يقول المسار هل يُختار 10.60.4.20 أصلا من ذلك المضيف؛ ويقول الفحص هل يستجيب المستمع؛ ويعرض سرد القواعد هل توقف السياسة الحزمة أم أنه لم يكن هناك شيء في مسارها قط.
كرر التعداد من مضيف التطبيق. من هناك يكون جانب قاعدة البيانات استعلاما واحدا يُنفذ بدور التطبيق:
psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'الاتصال الناجح بدور لا يستطيع قراءة مخطط آخر نتيجة مختلفة عن الاتصال الناجح بدور مالك. الثانية وحدها هي اكتشاف.
سجّل حالات الرفض ثم أرّخ المراجعة
تُكتب القبول كنتائج لا نوايا: جلسة الموظف لا تستطيع الوصول إلى المستمع، ومضيف البوابة لا يستطيع الوصول إلى شبكة فرعية غير ذات صلة، ودور التطبيق لا يستطيع إنشاء قاعدة بيانات. كل واحد فحص منفصل بمالك مسمى وتاريخ.
أبقِ المراقبة والترقيع والاستعادة قابلة للوصول عبر مسار الإدارة المصمم لها. الحد الذي يعطل مالكه أيضا يصبح انقطاعا، والاستجابة الأولى المعتادة لذلك الانقطاع هي توسيع القاعدة مرة أخرى. يطلب إرشادات CISA للمحيط تقييد الوصول الوارد والصادر بالمنافذ والبروتوكولات المبررة، بما في ذلك الحركة بين الشبكات الداخلية، وهي الاتجاه الذي تبدأه الواجهة الخلفية وتغفله معظم المخططات.
أرّخ المراجعة وسمِّ مالكها. أعد تشغيل التعداد واستعلام الامتيازات بعد أي تغيير في صورة البوابة أو جدول المسارات أو دور التطبيق.