
Security of HTTP
يتم استخدام HTTP للتواصل عبر الإنترنت ، لذلك يجب أن يكون المستخدمون وموفرو المعلومات ومطورو التطبيقات على دراية بحدود الأمان في HTTP / 1.1.
التاريخ
الدروس
المستوى
اللغة
المشاهدات
المواضيع
Security of HTTP
</> Security of HTTP
يتم استخدام HTTP للتواصل عبر الإنترنت ، لذلك يجب أن يكون المستخدمون وموفرو المعلومات ومطورو التطبيقات على دراية بحدود الأمان في HTTP / 1.1. لا يقدم هذا القسم حلاً نهائيًا للمشكلات المذكورة هنا. يوفر بعض الاقتراحات لتقليل مخاطر الأمان.
Personal information
</> Personal information
في HTTP ، غالبًا ما يكون العملاء مطلعين على قدر كبير من المعلومات الشخصية مثل: اسم المستخدم ، وعنوان البريد الإلكتروني ، وكلمات المرور ، والموقع ، ومفتاح التشفير ، وما إلى ذلك. يجب أن نكون حريصين على منع التسرب غير المقصود لهذه المعلومات الشخصية للعميل عبر بروتوكول HTTP لمصادر أخرى.
</> Transfer of Sensitive Information
لا يمكن لـ HTTP تنظيم محتوى البيانات التي يتم نقلها. لا يمكن أن يكون لدى HTTP أي طريقة سابقة لتحديد حساسية أي جزء معين من المعلومات في سياق أي طلب. قد يؤدي الكشف عن أي إصدار برنامج معين من الخادم إلى السماح لجهاز الخادم بأن يصبح أكثر عرضة للهجمات ضد البرامج التي تحتوي على ثغرات أمنية. يجب أن تتخذ البروكسيات التي تعمل كبوابة عبر جدار الحماية للشبكة احتياطات خاصة بشأن نقل معلومات header المستخدمة لتحديد المضيفين وراء جدار الحماية.
</> Encoding Sensitive Information in URI's
يمكن أن يكون مصدر الارتباط معلومات خاصة ، لذلك يوصى بشدة أن يكون المستخدم قادرًا على تحديد إرسال حقل المرجع أم لا. إذا تم نقل الصفحة التي نشير إليها باستخدام بروتوكول المصدر ، فيجب ألا يقوم العملاء بتضمين حقل مرجع في طلب HTTP.
Attacks Based On File and Path Names
</> Attacks Based On File and Path Names
يجب أن يكون تنفيذ الخادم الأصلي لـ HTTP حذرًا لتقييد المستند ، والذي يتم إرجاعه بواسطة طلبات HTTP ليكون فقط المقصود من قِبل مسؤولي الخادم.
على سبيل المثال ، تستخدم أنظمة التشغيل Microsoft Windows و UNIX وأنظمة التشغيل الأخرى "-" كمكوِّن مسار يُظهر مستوى دليل أعلى من المستوى الحالي. في هذا النوع من النظام ، يجب أن يرفض خادم HTTP أي بنية من هذا القبيل في Request-URI إذا كان الأمر كذلك ، وإلا فإن خادم HTTP لا يسمح بالوصول إلى المورد المقصود الوصول إليه من خلال خادم HTTP.
</> DNS Spoofing
يعتمد عملاء HTTP بشكل كبير على DNS (خدمة اسم المجال) ، وبالتالي يكونون عرضة بشكل عام لهجمات الأمان ، والتي تستند إلى الربط الخاطئ المتعمد لعناوين IP واسم DNS. لذلك يجب أن يكون العميل حريصًا في افتراض استمرار صلاحية عنوان IP ورابط اسم DNS.
</> Location Headers and Spoofing
إذا كان هناك مؤسسات متعددة مدعومة من خادم واحد ، ولم تكن أي من المؤسسات تثق في بعضها البعض ، فيجب أن تتحقق من قيمة الموقع وContent-Location headers في الاستجابة التي يتم إنشاؤها تحت سيطرة المؤسسات المذكورة. تُستخدم هذه المنظمات للتأكد من أنها تحاول إبطال الموارد التي ليس لديها سلطة عليها.
</> Authentication Credentials and Idle Clients
عادةً ما يحتفظ وكيل المستخدم وعملاء HTTP الحاليين بمعلومات المصادقة إلى أجل غير مسمى. لا يوفر HTTP / 1.1 أي دالة للخادم لتوجيه العملاء لتجاهل بيانات الاعتماد المخزنة مؤقتًا هذه. لحل هذه المشكلة ، يمكننا تشجيع استخدام idle time وحماية كلمة المرور والطرق الأخرى التي تقلل من مشاكل الأمان الكامنة في هذه المشكلة.