Web14: مشكلات أمنية في بروتوكول HTTP

تعرض هذه المقالة بعض مشكلات الأمان في بروتوكول HTTP ، والتي تم طرحها في وثيقتين RFC 7230 وRFC 7231. تمت الإشارة إلى الأمثلة الموجودة في المقالة حول أخطاء محددة من OWASP.

1. المخاطر من العوامل الوسيطة

يسمح HTTP باستخدام الوسطاء للرد على الطلبات من خلال سلسلة من الاتصالات. هناك ثلاثة عناصر وسيطة مشتركة: الوكيل والبوابة والنفق.

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

يجب على مطوري ومطوري النظام مراعاة عوامل الخصوصية والأمان أثناء عملية تصميم النظام وترميزه ونشره.

يجب أن يكون المستخدمون على دراية بمخاطر استخدام وكلاء أو بوابات غير موثوقة.

2. تقسيم الاستجابة

يعد تقسيم الاستجابة (المعروف أيضًا باسم حقن CRLF) أحد أساليب استغلال الويب الشائعة. يرسل المهاجم بيانات مشفرة، في بعض معلمات الطلب، والتي يتم بعد ذلك فك تشفيرها وتكرارها في حقل معين من رأس الاستجابة.

إذا كانت هذه البيانات عبارة عن رمز يمثل نهاية الاستجابة، وتم بدء استجابة لاحقة، فسيتم تقسيم الاستجابة الأصلية إلى قسمين وسيتحكم المهاجم في محتوى الاستجابة الثانية. يمكن للمهاجم بعد ذلك تقديم طلب آخر ضمن نفس الاتصال المستمر، وخداع المستلم (بما في ذلك الوسطاء) للاعتقاد بأن هذا الرد الثاني هو استجابة للطلب الثاني.

3. طلب ​​التهريب

تهريب الطلبات هو أسلوب يستغل الاختلافات في معالجة الطلبات بواسطة أنواع مختلفة من الخوادم لإخفاء الطلبات التي تبدو غير ضارة والملحقة بالطلب الأصلي.

لنتأمل المثال التالي:

لنفترض أن طلب POST يحتوي على حقلين "لطول المحتوى" في الرأس بقيمتين مختلفتين. سترفض بعض الخوادم هذا الطلب (IIS وApache)، لكن لن تفعل ذلك خوادم أخرى. على سبيل المثال، يستخدم SunONE W/S 6.1 حقل طول المحتوى أولاً، بينما يستخدم sunONE Proxy 3.6 حقل طول المحتوى ثانيًا.

بافتراض أن SITE هو DNS الخاص بـ SunONE W/S، الموجود خلف وكيل SunONE، يوجد ملف pom.html موجود على SunONE W/S. فيما يلي كيفية استغلال اقتراح طلب HTTP استنادًا إلى حالات عدم الاتساق في المعالجة بين خادمين:

[لاحظ أن كل سطر ينتهي بـ CRLF ("")، باستثناء السطر 10]

دعونا نفكر فيما يحدث عند إرسال طلب إلى W/S عبر الخادم الوكيل. أولاً، سيقوم الوكيل بتحليل الطلب من الأسطر 1 إلى 7 (الأزرق) ويواجه حقلين لطول المحتوى. كما ذكر أعلاه، فإنه سيتجاهل الحقل الأول ويفهم أن نص الطلب يبلغ طوله 44 بايت. ولذلك، فإنه يعامل البيانات من الأسطر 8 إلى 10 كنص الطلب الأول (من الأسطر 8 إلى 10، يبلغ طول البيانات 44 بايت بالضبط). سيقوم الوكيل بعد ذلك بتحليل الأسطر من 11 إلى 14 (باللون الأحمر) كالطلب الثاني للعميل.

الآن دعونا نرى كيف يفسر W/S البيانات أعلاه، حيث يتم إعادة توجيهها من الوكيل. على عكس الوكلاء، سيستخدم W/S حقل طول المحتوى الأول ويفسره على النحو التالي: الطلب الأول لا يحتوي على نص، ويبدأ الطلب الثاني من السطر 8 (لاحظ أن W/S سيتم تحليله من السطر 11 فصاعدًا كقيمة من حقل بلا).

بعد ذلك، دعونا نرى كيف يتم إرجاع الاستجابة إلى العميل. الطلب الذي تفهمه W/S هو "POST /foobar.html" (من السطر 1) و"GET /poison.html" (من السطر 8)، لذلك سيرسل للعميل استجابتين مع محتوى صفحة foobar. أتش تي أم أل و السم.أتش تي أم أل. يدرك الوكيل أن هاتين الاستجابتين تتوافقان مع طلبين: "POST /foobar.html" (من السطر 1) و"GET /page_to_poison.html" (السطر 11). سيقوم الوكيل بتخزين محتوى صفحة Poison.html المقابلة لعنوان URL "page_to_poison.html" (إفساد ذاكرة التخزين المؤقت). ومن هناك، عندما يطلب العميل "page_to_poison.html"، فإنه سيتلقى محتوى صفحة Poison.html.

4. الهجوم على أساس مسار الملف

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

على سبيل المثال، تستخدم UNIX وMicrosoft Windows والعديد من أنظمة التشغيل الأخرى ".." كعنصر مسار لتمثيل الدليل بمستوى أعلى من الملف/الدليل الحالي. بدون التحكم المناسب في الإدخال والترخيص، يمكن الوصول إلى الملفات/المجلدات الحساسة للنظام عن طريق إدخال مسارات تشير إلى هذه الملفات/المجلدات.

5. أنواع الهجمات: حقن الأوامر، حقن التعليمات البرمجية، حقن الاستعلام

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

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

6. الكشف عن المعلومات الشخصية

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

7. الكشف عن المعلومات الحساسة في URI

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

تجنب استخدام طريقة GET لإرسال معلومات شخصية إلى الخادم، حيث سيتم عرضها في URI. استخدم طريقة POST بدلاً من ذلك.

8. الكشف عن المعلومات البرمجية المستخدمة

عادةً ما توفر حقول وكيل المستخدم، عبر، الخادم الموجودة في الرأس معلومات حول البرنامج الذي يستخدمه المرسل. ومن الناحية النظرية، يسمح ذلك للمهاجمين باستغلال نقاط الضعف المعروفة في هذه البرامج بسهولة أكبر.