أمان HTTP
يتم استخدام HTTP للتواصل عبر الإنترنت ، لذلك يجب أن يكون المستخدمون وموفرو المعلومات ومطورو التطبيقات على دراية بحدود الأمان في HTTP / 1.1. لا يقدم هذا القسم حلاً نهائيًا للمشكلات المذكورة هنا. يوفر بعض الاقتراحات لتقليل مخاطر الأمان.
معلومات شخصية (Personal information)
في HTTP ، غالبًا ما يكون العملاء مطلعين على قدر كبير من المعلومات الشخصية مثل: اسم المستخدم ، وعنوان البريد الإلكتروني ، وكلمات المرور ، والموقع ، ومفتاح التشفير ، وما إلى ذلك. يجب أن نكون حريصين على منع التسرب غير المقصود لهذه المعلومات الشخصية للعميل عبر بروتوكول HTTP لمصادر أخرى.
1. إساءة استخدام معلومات سجل الخادم
في هذا ، يجب تخزين جميع البيانات الشخصية للمستخدم على الخادم في شكل مشفر.
2. نقل المعلومات الحساسة
لا يمكن لـ HTTP تنظيم محتوى البيانات التي يتم نقلها. لا يمكن أن يكون لدى HTTP أي طريقة سابقة لتحديد حساسية أي جزء معين من المعلومات في سياق أي طلب.
قد يؤدي الكشف عن أي إصدار برنامج معين من الخادم إلى السماح لجهاز الخادم بأن يصبح أكثر عرضة للهجمات ضد البرامج التي تحتوي على ثغرات أمنية.
يجب أن تتخذ البروكسيات التي تعمل كبوابة عبر جدار الحماية للشبكة احتياطات خاصة بشأن نقل معلومات الرأس المستخدمة لتحديد المضيفين وراء جدار الحماية.
3. ترميز المعلومات الحساسة في URI's
يمكن أن يكون مصدر الارتباط معلومات خاصة ، لذلك يوصى بشدة أن يكون المستخدم قادرًا على تحديد إرسال حقل المرجع أم لا.
إذا تم نقل الصفحة التي نشير إليها باستخدام بروتوكول المصدر ، فيجب ألا يقوم العملاء بتضمين حقل مرجع في طلب HTTP.
4. مشكلات الخصوصية مرتبطة ب Accept Headers
يمكن قبول رؤوس الطلبات الكشف عن معلومات العميل لجميع الخوادم التي يتم الوصول إليها.
الهجمات على أساس أسماء الملفات والمسار (Attacks Based On File and Path Names)
يجب أن يكون تنفيذ الخادم الأصلي لـ HTTP حذرًا لتقييد المستند ، والذي يتم إرجاعه بواسطة طلبات HTTP ليكون فقط المقصود من قِبل مسؤولي الخادم.
على سبيل المثال ، تستخدم أنظمة التشغيل Microsoft Windows و UNIX وأنظمة التشغيل الأخرى "-" كمكوِّن مسار يُظهر مستوى دليل أعلى من المستوى الحالي. في هذا النوع من النظام ، يجب أن يرفض خادم HTTP أي بناء من هذا القبيل في Request-URI إذا كان الأمر كذلك ، وإلا فإن خادم HTTP لا يسمح بالوصول إلى مورد من المفترض أن يكون الوصول إليه من خلال خادم HTTP.
انتحال DNS (DNS Spoofing)
يعتمد عملاء HTTP بشكل كبير على DNS (خدمة اسم المجال) ، وبالتالي يكونون عرضة بشكل عام لهجمات الأمان ، والتي تستند إلى الربط الخاطئ المتعمد لعناوين IP واسم DNS. لذلك يجب أن يكون العميل حريصًا في افتراض استمرار صلاحية عنوان IP ورابط اسم DNS.
إذا قام عملاء HTTP بتخزين نتائج عمليات بحث اسم المضيف مؤقتًا لتحسين الأداء ، فيجب عليهم ملاحظة معلومات TTL ، التي تم الإبلاغ عنها بواسطة DNS. عندما يتم تغيير عنوان IP للخادم الذي تم الوصول إليه سابقًا ، فقد يتم انتحال عملاء HTTP إذا لم يلتزموا بهذه القاعدة.
(Location Headers and Spoofing)
إذا كانت المؤسسات المتعددة مدعومة من خادم واحد ، ولم تكن أي من المؤسسات تثق في بعضها البعض ، فيجب أن تتحقق من قيمة الموقع ورؤوس موقع المحتوى في الاستجابة التي يتم إنشاؤها تحت سيطرة المؤسسات المذكورة. تُستخدم هذه المنظمات للتأكد من أنها تحاول إبطال الموارد التي ليس لديها سلطة عليها.
بيانات اعتماد المصادقة والعملاء الخاملون (Authentication Credentials and Idle Clients)
عادةً ما يحتفظ وكيل المستخدم وعملاء HTTP الحاليين بمعلومات المصادقة إلى أجل غير مسمى. لا يوفر HTTP / 1.1 أي طريقة للخادم لتوجيه العملاء لتجاهل بيانات الاعتماد المخزنة مؤقتًا هذه.
لحل هذه المشكلة ، يمكننا تشجيع استخدام مهلة الخمول وحماية كلمة المرور والطرق الأخرى التي تقلل من مشاكل الأمان الكامنة في هذه المشكلة.