تفاصيل هجوم جديد على المواقع التي تستخدم نموذج الواجهة الأمامية والخلفية، مثل تلك التي تعمل عبر شبكات توصيل المحتوى أو موازنات التحميل أو الوكلاء. يسمح الهجوم، عن طريق إرسال طلبات معينة، بالتدخل في محتويات الطلبات الأخرى التي تتم معالجتها في نفس الموضوع بين الواجهة الأمامية والخلفية. وتم استخدام الطريقة المقترحة بنجاح لتنظيم هجوم جعل من الممكن اعتراض معلمات المصادقة لمستخدمي خدمة PayPal، والتي دفعت للباحثين حوالي 40 ألف دولار كجزء من برنامج للإبلاغ عن وجود ثغرات أمنية لم يتم إصلاحها. وينطبق الهجوم أيضًا على المواقع التي تستخدم شبكة توصيل محتوى Akamai.
جوهر المشكلة هو أن الواجهات الأمامية والواجهات الخلفية غالبًا ما توفر مستويات مختلفة من الدعم لبروتوكول HTTP، ولكنها في الوقت نفسه تقوم بتغليف الطلبات الواردة من مستخدمين مختلفين في قناة مشتركة. لتوصيل طلبات استقبال الواجهة الأمامية وطلبات معالجة الواجهة الخلفية، يتم إنشاء اتصال TCP طويل الأمد، والذي يتم من خلاله إرسال طلبات المستخدم، ويتم إرسالها على طول السلسلة الواحدة تلو الأخرى، ويتم فصلها عن طريق بروتوكول HTTP. لفصل الطلبات، الرؤوس ""طول المحتوى"" (تحدد الحجم الإجمالي للبيانات في الطلب) و""(يسمح لك بنقل البيانات في أجزاء، مع تحديد الكتل ذات الأحجام المختلفة بالتنسيق "{size}\r\n{block}\r\n{size}\r\n{block}\r\n0").
تنشأ المشكلة إذا كانت الواجهة الأمامية تدعم فقط "طول المحتوى" ولكنها تتجاهل "ترميز النقل: مقسم" (على سبيل المثال، قام Akamai CDN بذلك) أو العكس. إذا كان ترميز النقل: مقسمًا مدعومًا على كلا الجانبين، فيمكن استخدام ميزات التنفيذ الخاصة بموزعي رأس HTTP للهجوم (على سبيل المثال، عندما تتجاهل الواجهة الأمامية أسطرًا مثل "ترميز النقل: xchunked"، "ترميز النقل: مقسم" "، "ترميز النقل" :[tab]مقسم"، "X: X[\n]ترميز النقل: مقسم"، "ترميز النقل[\n]: مقسم" أو "ترميز النقل: مقسم"، و تقوم الواجهة الخلفية بمعالجتها بنجاح).
في هذه الحالة، يمكن للمهاجم إرسال طلب يحتوي على رأسي "طول المحتوى" و"ترميز النقل: مقسم"، لكن الحجم في "طول المحتوى" لا يتوافق مع حجم السلسلة المقسمة، والتي أصغر من القيمة الفعلية. إذا قامت الواجهة الأمامية بمعالجة الطلب وإعادة توجيهه وفقًا لـ "طول المحتوى" وكانت الواجهة الخلفية تنتظر اكتمال الكتلة بناءً على "ترميز النقل: مقسم"، فستكون نهاية البيانات بناءً على "ترميز النقل: مقسم" سيتم تحديده مسبقًا وسيكون الذيل المتبقي من الطلب للمهاجم في بداية الطلب التالي، أي. سيتمكن المهاجم من إرفاق بيانات عشوائية ببداية طلب شخص آخر يتم إرساله بعد ذلك.
لتحديد المشكلة في مجموعة الواجهة الأمامية والخلفية المستخدمة، يمكنك إرسال طلب مثل هذا عبر الواجهة الأمامية:
نشر /حول HTTP/1.1
المضيف: example.com
نقل الترميز: مكتنزة
طول المحتوى: 4
1
Z
Q
تكون المشكلة موجودة إذا لم تقم الواجهة الخلفية بمعالجة الطلب على الفور وانتظرت وصول الكتلة الصفرية النهائية للبيانات المقسمة. لفحص أكثر اكتمالا أداة مساعدة خاصة تختبر أيضًا الطرق الممكنة لإخفاء رأس "Transfer-Encoding: Chunked" من الواجهة الأمامية.
يعتمد تنفيذ هجوم حقيقي على إمكانيات الموقع الذي تمت مهاجمته، على سبيل المثال، عند مهاجمة تطبيق الويب Trello، يمكنك استبدال بداية الطلب (استبدال البيانات مثل “PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake") وأرسل رسالة تتضمن الطلب الأصلي لمستخدم خارجي وملف تعريف ارتباط المصادقة المحدد فيه. بالنسبة للهجوم على saas-app.com، اتضح أنه من الممكن استبدال كود JavaScript في الاستجابة عن طريق استبداله في إحدى معلمات الطلب. بالنسبة للهجوم على موقع redhat.com، تم استخدام معالج داخلي لإعادة التوجيه إلى موقع المهاجم (طلب بالنموذج "POST /search?dest=../assets/idx?redir=//"[البريد الإلكتروني محمي]/ HTTP/1.1").
باستخدام طريقة شبكات توصيل المحتوى، أصبح من الممكن استبدال الموقع المطلوب ببساطة عن طريق استبدال رأس "المضيف:". يمكن أيضًا استخدام الهجوم لتسميم محتويات أنظمة التخزين المؤقت للمحتوى واستخراج البيانات السرية المخزنة مؤقتًا. كانت ذروة الطريقة هي تنظيم هجوم على PayPal، مما جعل من الممكن اعتراض كلمات المرور المرسلة من قبل المستخدمين أثناء المصادقة (تم تعديل طلب iframe لتنفيذ JavaScript في سياق صفحة paypal.com/us/gifts، من أجل التي لم يتم تطبيق CSP (سياسة أمان المحتوى).
ومن المثير للاهتمام أنه في عام 2005 كان هناك تقنية انتحال طلب مشابهة بشكل أساسي تسمح لك بانتحال البيانات في وكلاء التخزين المؤقت (Tomcat، squid، mod_proxy) أو تجاوز حظر جدار الحماية عن طريق تحديد عدة طلبات "GET" أو "POST" خلال جلسة HTTP واحدة.
المصدر: opennet.ru