كيف تخاطر أرصدة الأحمال وعلاقة IP الحقيقية بأمنك؟

تتمثل إحدى مزايا كونك متخصصًا في الأمان في العمل مع العديد من الفرق. بعد التدقيق ، ستتاح الفرصة لمتخصصي الأمن للعمل مع مسؤولي ومحللي قواعد البيانات. لكي يعمل التطبيق بشكل صحيح وآمن ، تحاول هذه الفرق التعامل مع الثغرات الأمنية التي لها أساس مشترك. تثير الحوارات بين هذه الفرق بعض القضايا مع IP الحقيقي.

مفاهيم الوكيل والملكية الفكرية الحقيقية

تعمل تطبيقات الويب الحالية على العديد من خوادم التطبيقات وأنظمة قواعد البيانات. تخيل اثنين من خوادم التطبيقات التي تشترك في نفس شفرة المصدر. الطلبات المقدمة من المستخدم جاهزة للوفاء بها بواسطة أي من هذه الخوادم حسب حالة التحميل. تحدد آلية موازنة التحميل ، التي تتعامل مع طلبات HTTP أمام خوادم التطبيق ، الطلب الذي سيتم إعادة التوجيه إليه. يطرح هذا سؤالًا كبيرًا لمديري أنظمة البرامج الوسيطة ومطوري البرامج: ما هو عنوان IP الحقيقي للمستخدم؟

الوكلاء هم المسؤولون عن نقل البيانات بين نظامين. موازن التحميل هو الآلية المسؤولة عن الوكيل. بمعنى آخر ، يتواصل نظام واحد فقط مع كل من المستخدم وخادم التطبيق. فيما يتعلق بحركة مرور الشبكة ، تتصل خوادم الويب A أو الويب دائمًا بعنوان IP الخاص بموازنة التحميل. يمكن قول الشيء نفسه للمستخدمين. بالنسبة لمتخصصي الأمان ، تتسبب موازنات التحميل في حدوث مشكلات خطيرة في هجمات حقن SQL المستندة إلى الوقت. لكن ال

التركيز الرئيسي هنا هو انتحال IP.

X-Forwarded-For وعلاقة IP

ضع في اعتبارك العلاقة بين X-Forwarded-For والمطور والبرمجيات الوسيطة. على سبيل المثال ، لنفترض أن مهمة مطور التطبيق هي تسجيل جميع الأنشطة ، مثل محاولات كلمة المرور غير الصحيحة من قبل المستخدمين ، باستخدام عناوين IP الخاصة بهم. في البداية ، سيحدد المطور عنوان IP الخاص بالمستخدم عند تلبية طلب HTTP بامتداد الفرصة التي توفرها لغة البرمجة التي يستخدمها وسيحاول الاستمرار في استخدام هذه البيانات في طلب.

نظرًا لأنه سيتم إصلاح عنوان IP الخاص به طوال عملية التطوير ، فسيشاهد دائمًا نفس العنوان أثناء الاختبارات لأنه بشكل عام ، تكون أجهزة كمبيوتر المستخدم في تعمل شبكات الشركات مع IP ثابت عبر عنوان MAC. ستجري الوحدة بعض اختبارات القبول ؛ ومع ذلك ، ستكون هناك مشاكل مع هذه. ستقوم وحدة الاختبار بإعادة توجيه هذه المشكلة إلى مطور البرامج.

في هذه المرحلة ، قد يكتب المطور وحدة تحكم في بيئة التطوير ويرى طلب HTTP الذي تم إرساله إلى التطبيق في شكل أولي ، حيث أن كل شخص لديه نفس عنوان IP. سينتج عن ذلك العمل مع X-Forwarded-For.

معلومات الرأس سيتم إرسال يسمى X-Forwarded-For إلى خادم التطبيق. في هذه المرحلة ، سيرى مطور البرامج عنوان IP الخاص به ، والذي يتحكم فيه باستخدام ipconfig ، وليس موازن التحميل الذي يراه في السجلات. يعتقد العديد من المبرمجين أنه يمكنهم حل هذه المشكلة باستخدام كتلة التعليمات البرمجية مثل هذا:

وظيفةgetIPaddress() {
 $ ipKeys = مجموعة مصفوفة(
"HTTP_CLIENT_IP", 
"HTTP_X_FORWARDED_FOR", 
"HTTP_X_FORWARDED", 
"HTTP_X_CLUSTER_CLIENT_IP", 
"HTTP_FORWARDED_FOR", "HTTP_FORWARDED", 
"REMOTE_ADDR"
);
foreach ($ ipKeys مثل مفتاح $) {
لو (array_key_exists ($ key، $ _SERVER) حقيقي) {
foreach (ينفجر(','، $ _SERVER [$ key]) مثل $ ip) {
 $ ip = تقليم ($ ip) ؛
لو (validate_ip ($ ip)) {
يعود $ ip؛
 }
 }
 }
 }
يعودايسيت(_SERVER دولار ["REMOTE_ADDR"])? _SERVER دولار ["REMOTE_ADDR"]: خطأ شنيع;
}

لن يكون هذا كافيًا — يحتاج المطور إلى التحقق مما إذا كانت القيمة الواردة هي عنوان IP صالح.

كل شيء أعلاه ينتمي إلى الجزء الذي يتعامل معه المطور. ولكن لكي يعمل التطبيق بشكل صحيح وآمن ، تعمل الفرق معًا نظريًا ، ولكن في في الواقع ، في نقاط متطرفة من بعضها البعض — حاول التعامل مع الثغرات الأمنية التي تحتوي على أساس مشترك. حاول الآن النظر إلى المشكلة من منظور الشخص المسؤول عن تكوين موازن التحميل.

قد يعتقد مسؤولو النظام أن المطورين يسجلون معلومات مثل X-Forwarded-For لأنه لا يمكن الوثوق بالبيانات الموجودة في طلب HTTP. غالبًا ما يقوم هؤلاء المسؤولون بإرسال X-Forwarded-For ؛ ومع ذلك ، فإنها ترسل أيضًا عنوان مصدر TCP للنظام الذي أرسل الطلب كقيمة رأس ثانية. تعد بنية True-Client-IP مثالاً جيدًا على ذلك.

عندما تجمع كل هذه الأشياء معًا ، تتبع وحدتان مختلفتان مسارات مختلفة لنفس المشكلة ، تُعرف باسم انتحال عنوان IP الخاص بالعميل. والنتيجة هي مشكلة حرجة حيث لن يعمل أي تسجيل IP والترخيص المستند إلى IP.

كيف يتم الكشف عن انتحال عنوان IP للعميل في اختبارات الاختراق؟

يستخدم معظم مختبري الاختراق Firefox لإجراء فحوصات الأمان الخاصة بهم. قاموا بتكوين Firefox مع إضافة بسيطة ، X-Forwarded-For: 127.0.0.1 لجميع طلبات HTTP. وبالتالي ، تزداد إمكانية اكتشاف مثل هذه الثغرات في جميع اختبارات الاختراق. إجراء تدقيق وفقًا لـ قائمة مراجعة OWASP يضمن لك التحقق من مثل هذه الثغرات الأمنية. ومع ذلك ، لاكتشاف ثغرة X-Forwarded-For ، فأنت بحاجة إلى وحدة نمطية في التطبيق تعرض عنوان IP الخاص بك أو الإجراءات المتخذة.

كيفية حل ثغرة X-Forwarded-For

تحتاج المؤسسات إلى مستند تطوير تطبيق آمن إلزامي لجميع فرق البرامج وشركات التعهيد. على سبيل المثال ، إذا كنت بحاجة إلى عنوان IP للمستخدم ، فيجب على الشركة التخطيط مسبقًا وجعله قاعدة حول معلومات الرأس التي ستستخدمها هنا. خلاف ذلك ، ستنتج الفرق المختلفة حلولًا مختلفة. إذا لم يكن من الممكن التعامل مع مثل هذا الموقف ، فسيتم تفعيل تطبيقات الاستعانة بمصادر خارجية ، مما يجعل من الصعب قياس رموز المصدر. بشكل عام ، لا تريد الشركات اتباع هذا المسار.

ولكن لحل هذه المشكلة ، يمكنك استخدام قاعدة F5 التالية:

عندما HTTP_REQUEST {
 HTTP:: إزالة رأس X-Forwarded-ل
 HTTP:: إدراج رأس X-Forwarded-ل [IP:: remote_addr]
}

يؤدي هذا إلى إزالة الحقل X-Forwarded-For في طلب HTTP من العالم الخارجي. ثم ينقل الطلب عن طريق إضافة عنوان IP للنظام الذي أرسل الطلب إليه. بهذه الطريقة ، يتم إنشاء قائمة موثوقة للبرامج التي تعمل وفقًا لـ X-Forwarded-For.

للتلخيص ، الهدف الأكبر هنا هو إجراء بعض الفحوصات على طلبات HTTP وإنشاء بيئة موثوقة. تعد كتلة التعليمات البرمجية أعلاه مثالًا جيدًا يمكنك استخدامه لهذا الغرض.

أطر الأمن السيبراني والتوثيق للمؤسسات

الوحدات التي تبدو مستقلة عن بعضها البعض هي في الواقع أجزاء من الكل. لهذا السبب يجب أن يعمل كل شيء بشكل منهجي. يجب تطبيق القواعد المحددة مسبقًا بين كل وحدة. إذا لم يتم اعتماد نظام العمل هذا ، فقد تحدث العديد من المشكلات مثل ثغرة X-Forwarded-For. لهذا ، يجب النظر في كل شيء مسبقًا ويجب استخدام التوثيق على أكمل وجه ممكن.

وكل وحدة في هذا النظام الكبير تحتاج إلى اعتماد وتنفيذ أطر عمل للأمن السيبراني. يجب أن تكون نقطة البداية الخاصة بك هي البحث ومعرفة منطق العمل لهذه الأطر.