it-swarm.dev

ما الهدف من رأس X-Requested-With؟

تضيف JQuery والأطر الأخرى العنوان التالي:

س المطلوب مع: XMLHttpRequest

لماذا هذا مطلوب؟ لماذا يريد الخادم معالجة AJAX الطلبات بشكل مختلف عن الطلبات العادية؟

UPDATE: لقد وجدت مثالًا واقعًا حقيقيًا باستخدام هذا الرأس: https://core.spreedly.com/manual/payment-methods/adding-with-js . إذا تم طلب معالج الدفع بدون AJAX ، فإنه يعيد التوجيه إلى الموقع الأصلي عند الانتهاء. عندما يتم طلب ذلك مع AJAX ، لن تتم إعادة التوجيه.

182
Gili

سبب وجيه للأمان - هذا يمكن أن يمنع CSRF / الهجمات لأنه لا يمكن إضافة هذا الرأس إلى AJAX طلب عبر المجال دون موافقة الخادم عبر CORS .

يسمح فقط للرؤوس التالية بالمجال المتداخل:

  • قبول
  • قبول اللغة
  • محتوى اللغة
  • نشاط-الحدث-ID
  • نوع المحتوى

أي أشخاص آخرين يتسببون في إصدار طلب "قبل الرحلة" في متصفحات CORS المدعومة.

بدون CORS ، لا يمكن إضافة X-Requested-With إلى طلب XHR عبر النطاق.

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

اكتشاف فلاش جديد اكتشف

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

يوصي OWASP بدمج هذا مع التحقق من الأصل والإحالة :

تمت مناقشة تقنية الدفاع هذه بشكل خاص في القسم 4.3 من دفاعات قوية لتزوير الطلبات عبر المواقع. ومع ذلك ، تم توثيق تجاوزات هذا الدفاع باستخدام Flash في وقت مبكر من عام 2008 ومرة ​​أخرى حتى عام 2015 من قبل Mathias Karlsson لاستغلال عيب CSRF في Vimeo. ولكننا نعتقد أن هجوم Flash لا يمكن أن يفسد رؤوس الأصل أو المرجع ، لذا فمن خلال التحقق من كلاهما ، نعتقد أن هذه المجموعة من الاختبارات يجب أن تمنع هجمات تجاوز فلاش CSRF. (ملاحظة: إذا تمكن أي شخص من تأكيد هذا الاعتقاد أو دحضه ، فيرجى إخبارنا حتى نتمكن من تحديث هذه المقالة)

ومع ذلك ، للأسباب التي تمت مناقشتها بالفعل ، قد يكون التحقق من Origin أمرًا صعبًا.

تحديث

مكتوبة بشكل أكثر تعمقا نشر بلوق على CORS ، CSRF و X- مطلوب - هنا .

218
SilverlightFox

تأكد من قراءة إجابة SilverlightFox. ويسلط الضوء على سبب أكثر أهمية.

السبب في الغالب هو أنه إذا كنت تعرف مصدر الطلب ، فقد ترغب في تخصيصه قليلاً.

على سبيل المثال ، لنفترض أن لديك موقع ويب به العديد من الوصفات. وأنت تستخدم إطار عمل مسج مخصصًا لإزاحة الوصفات في حاوية استنادًا إلى ارتباط ينقر فوقه. قد يكون الرابط www.example.com/recipe/Apple_pie

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

الآن يمكنك فقط كتابة نقطة نهاية ثانوية للبيانات مثل www.example.com/recipe_only/Apple_pie ولكن يصعب الحفاظ عليها ومشاركتها مع أشخاص آخرين.

لكن من الأسهل فقط اكتشاف أنه طلب آجاكس يقدم الطلب ثم يعيد جزءًا فقط من البيانات. بهذه الطريقة يضيع المستخدم نطاقًا تردديًا أقل ويبدو الموقع أكثر استجابة.

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

انها في الواقع نوع من تشبه رأس Accept-Language. يمكن للمتصفح طلب موقع على شبكة الإنترنت ، يرجى إطلاعي على النسخة الروسية من هذا الموقع دون الحاجة إلى إدراج/ru/أو ما شابه ذلك في عنوان URL.

21
EWit

تستخدم بعض الأُطر هذا الرأس للكشف عن طلبات xhr على سبيل المثال يستخدم grails spring security هذا الرأس لتحديد طلب xhr وإعطاء استجابة json أو استجابة html كاستجابة.

تشتمل معظم مكتبات Ajax (Prototype و JQuery و Dojo اعتبارًا من الإصدار 2.1) على رأس X-Requested-With الذي يشير إلى أن الطلب تم تقديمه بواسطة XMLHttpRequest بدلاً من تشغيله بالنقر فوق ارتباط تشعبي عادي أو زر إرسال نموذج.

المصدر: http://grails-plugins.github.io/grails-spring-security-core/guide/helperClasses.html

7
Koray Güclü