هل EnableHeaderChecking=صحيح بما يكفي لمنع هجمات حقن رأس Http؟

https://stackoverflow.com/questions/869361

22-08-2019
|

سؤال

هل يكفي أن يكون [System.Web.Configuration.HttpRuntimeSection.EnableHeaderChecking](http://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.enableheaderchecking(VS.85).aspx) ضبط ل true (افتراضي) لمنع هجمات حقن رأس Http بشكل كامل مثل تقسيم الاستجابة وما إلى ذلك؟

أنا أسأل لأن أداة اختبار اختراق الصندوق الأبيض (التحصين) تبلغ عن مشكلات في حقن رأس http قابلة للاستغلال HttpResponse.Redirect وملفات تعريف الارتباط ولكني لم أجد طريقة لتنفيذ الهجوم بنجاح.(يحرر:..ولقد قمنا بتشغيل EnableHeaderChecking..)

المحلول

لقد كنت أنظر إلى هذا منذ بعض الوقت وأستنتج أن هذا الإعداد تمكينHeaderChecking ل true هو في الواقع جيد بما يكفي لمنع هجمات حقن رأس http.

بالنظر إلى كود ASP.NET "المنعكس"، وجدت أن:

هناك طريقة واحدة فقط لإضافة رؤوس HTTP مخصصة إلى استجابة HTTP، وهي استخدام HttpResponse.AppendHeader طريقة
HttpResponse.AppendHeader أيضاً
- يخلق مثيلات HttpResponseHeader (داخلي)
- أو المكالمات HttpResponseHeader.MaybeEncodeHeader (ل IIS7WorkerRequests)
- أو يعين خصائصه الخاصة (للرؤوس المعروفة مثل إعادة توجيه الموقع أو نوع المحتوى)
HttpResponseHeader يتم إنشاء المثيلات قبل الرؤوس المعروفة مثل إعادة توجيه الموقع أو نوع المحتوى يتم إرسال (HttpResponse.GenerateResponseHeaders)
ال HttpResponseHeader يتحقق المنشئ من تمكين HeaderChecking الإعداد والمكالمات HttpResponseHeader.MaybeEncodeHeader عند التعيين على true
HttpResponseHeader.MaybeEncodeHeader يقوم بترميز أحرف السطر الجديد بشكل صحيح مما يجعل هجمات حقن رأس HTTP مستحيلة

فيما يلي مقتطف يوضح تقريبًا كيفية اختباري:

// simple http response splitting attack
Response.AddHeader("foo", "bar\n" + 
    // injected http response, bad if user provided
    "HTTP/1.1 200 OK\n" + 
    "Content-Length: 19\n" +
    "Content-Type: text/html\n\n" +
    "<html>danger</html>"
);

ما سبق لا يعمل إلا إذا قمت بتشغيل صراحة تمكينHeaderChecking عن:

<httpRuntime enableHeaderChecking="false"/>

Fortify ببساطة لا يأخذ التكوين في الاعتبار (setting تمكينHeaderChecking صراحة لم يكن لها أي تأثير) وبالتالي دائماً تقارير هذا النوع من القضايا.

نصائح أخرى

AFAIK يكفي ويجب تشغيله افتراضيًا.

أعتقد أن Fortify يفكر فقط في الدفاع بعمق كما لو قمت بتغيير التكوين في النشر وما إلى ذلك.

أفترض أنك لم تقم بتعيينه بشكل صارم في التكوين الخاص بك، إذا كان لديك، فربما لا يكون Fortify ذكيًا في معرفة ذلك.

أفضل طريقة للتأكيد هي استغلالها :)

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

وEnableHeaderChecking فقط للبيانات غير موثوق بها. إذا كنت تمرير البيانات مباشرة من الكعكة إلى إعادة توجيه، ربما تعتبر رؤوس الناتجة ثقة و\ ص \ ن لا يتم نجا القيم.

وجوزيف، HttpResponse.AppendHeader () ليست هي المكان الوحيد الذي يمكن للبيانات غير موثوق بها دخول HTTP رؤوس استجابة.

وأي بيانات من المهاجم الذي ينتهي في الكوكيز أو الموجهات HTTP يمكن أن يكتب رؤوس جديدة إذا البيانات تحتوي على إرجاع (أو أي شيء يفسر على أنه حرف إرجاع).

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

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow