في عام 2019 ، تم اكتشاف ثغرة CPDoS Cache Poisoned Denial of Service) على شبكة CDN ، مما يسمح بتسمم ذاكرة التخزين المؤقت HTTP لموفر CDN والتسبب في رفض الخدمة. لم تجمع الثغرة الكثير من الضجيج ، حيث لم تتم رؤيتها في الهجمات الحقيقية. لكني أريد التحدث عن إحدى طرق التسمم في ذاكرة التخزين المؤقت بشكل منفصل. تجاوز أسلوب HTTP.إذا كانت المتغيرات الأخرى لاستغلال الثغرة بطريقة أو بأخرى تعتمد على الأخطاء أو ميزات تعديل الطلب بواسطة وسيط ، فإن متغير Method Override يعتمد على تكتيك يحمل نفس الاسم ، وهو ليس جزءًا من معيار HTTP ، يحمل معه مشاكل إضافية ، والتي نشأت وانتشرت بسبب الإهمال العلاقة بالأمن. سننظر هنا.قصيرة حول CPDoS إذا فاتك, URI method .
, , , , - . — - - -, , - , . , .
, . , ,
-. - , , .
حد العميل ، أقل يمكن - أقل ينكسر
نشأت الحاجة إلى تجاوز الطريقة في الطلب بسبب حقيقة أن بعض جدران حماية تطبيق الويب وتطبيقات عميل HTTP كانت محدودة للغاية ولم تسمح بتنفيذ طرق أخرى غير GET و POST. لا تكمن المشكلة في أنها كانت قيودًا على التنفيذ ، ولكنها كانت قيودًا مقصودة على عملاء HTTP من خلال سياسة الأمان.من الواضح أن كل شيء تم تنفيذه بحسن نية لقطع حركة المرور الضيقة وغير القياسية لعملاء HTTP العاديين. ولكن سعيا وراء الأمن ، تم قطع جميع الطرق باستثناء GET و POST. ربما لأن هذه هي الطرق الوحيدة غير الاختيارية والمطلوبة لخوادم الأغراض العامة.لماذا كان مطلوبا لإدخال مثل هذا التقييد الصارم غير واضح. نعم ، إن الهجمات بإدخال شخصيات مختلفة من أجل إرباك المحلل اللغوي ليست سوى هواية البروتوكولات النصية. ولكن يمكنك أن تسمح بمزيد من الأساليب ، على سبيل المثال ، خذ على الأقل تلك الموضحة في المعيار نفسه أو المسجلة في IANA . لم يكن الأمر يستحق إزالة فحص الطريقة تمامًا ، ولكن يمكنك طلب عدد من الطرق الأكثر شيوعًا واستبعاد منها تلك التي تغير بروتوكول التفاعل وتقطع العمل مع الاتصالات على الخادم الوكيل (CONNECT). ولكن لا ، فقد تحولت إلى سياسة أمنية أدخلت قيودًا وحظرًا غير ضروري للعملاء.والعملاء يقتصرون على العملاء الخطأ. لقد أرادوا الحد من تنوع الرسائل من عملاء HTTP ، وحصروا العملاء الذين تحميهم WAFs وخوادم التطبيقات النهائية ومطوريها. الآن ، تم ترك المطورين مع طريقتين فقط لم تكن دائمًا كافية لوصف منطق عميل HTTP.يتم إنشاء القيود للتغلب عليها.
كان من المتوقع أن هذا التقييد المفرط سيبدأ عاجلاً أم آجلاً في التدخل مع مطوري الويب. المفارقة هي أنه من السهل جدًا عدم التخلص من مثل هذه WAFs. خاصة عندما يكونون مع العملاء أو مقدمي الخدمات. إن تحدي السياسات الأمنية للآخرين أمر كارثي.نظرًا لمرونة HTTP ، ليس من الصعب التحايل على هذا القيد ؛ فقط أضف شيئًا إلى الطلب حيث يمكنك تجاوز الطريقة. ستتحقق Wict الصارمة من الطريقة فقط في سطر الطلب (السطر الأول من الطلب) وستسعدها رؤية GET أو POST المعتمدين هناك. وستكون الواجهة الخلفية قادرة على تحليل العنصر المضاف واستخراج الطريقة الحقيقية منه.يمكنك جوجل مجموعة من المقالات ، حقا مجموعةحول كيفية قيام الوكلاء السيئين باختراق تطبيقات REST ، وكيف كان على المؤلفين تمرير الطريقة الحقيقية في عنوان منفصل. في كل منها ، يقترحون إدخال نفس الرأس تقريبًا (X-HTTP-Method أو X-HTTP-Method-Override أو X-Method-Override - يختلف التهجئة إلى حد ما) للإشارة إلى طريقة تم تجاوزها. نادرًا جدًا ما يمكن للمرء العثور على مراجع يمكن استخدامها لنفس الغرض من مكون الاستعلام URI.ما هو مفقود من هذه المقالات هو قسم اعتبارات الأمان. وهم فقط.هي طريقة تجاوز آمنة؟
في بعض الأحيان ينسى مطورو تطبيقات الويب أنه بين العميل والخادم قد يكون هناك مشاركين وسيطين يتفاعلون عبر بروتوكول HTTP: الوكلاء ، ومخازن الويب المؤقتة لمزودي الخدمة ، و CDN و WAF. يقلل تكاثر TLS بشكل كبير من فرصة وجود مشارك وسيط بين العميل والخادم. على الأرجح سيكون الوكيل الوحيد بين العميل والواجهة الخلفية هو خادمه الخاص مع Nginx. ومثل هذا التكوين سهل بما يكفي لاختباره على السيناريوهات النموذجية قبل الإصدار.ولكننا ننتقل إلى عصر CDN ، وسوف يختبئ المزيد والمزيد من التطبيقات وراء شبكات CDN التي تقرأ وتعالج حركة مرور المستخدم. لا تخدم الخلفية بشكل مباشر تقريبًا المستخدمين ، وتختفي وراء الوكلاء العكسيين لزيادة الاستجابة والأداء. لذلك ، سيتعين عليك أن تتذكر كيف يمكن لإلغاء طريقة أن يؤثر على معالجة الطلب على خادم التوسط.الهجمات التي أريد التحدث عنها قابلة للتطبيق بشكل أساسي على HTTP / 1.1. يرث HTTP / 2 بطريقة أو بأخرى سلوك المعيار القديم ، وفي بعض الطرق يسير على طريقته الخاصة ، لذلك سيتم النظر في إمكانية تطبيق كل هجوم على المعيار الجديد بشكل منفصل.هجمات التخزين المؤقت
في معظم الأحيان ، لا تأخذ الخوادم الوسيطة في الاعتبار تجاوزات الطريقة ، ولا تتحقق من رؤوس عائلة X-HTTP-Method-Override ، وتعمل مع الطلب باستخدام طريقتها الرئيسية من خط الطلب. وبما أن الطريقة التي تم تجاوزها لم يتم تضمينها في مفتاح البحث عن طلب في ذاكرة التخزين المؤقت (أسلوب + URI) ، فلا يمكن لهذه الخوادم تمييز POST عن POST + X-HTTP-Method-Override: DELETE. هذا يعني أنه لا يمكنك السماح بالتخزين المؤقت لأي طلبات إلى URI معين إذا كان بإمكان الواجهة الخلفية مراقبة وتنفيذ الأساليب التي تم تجاوزها.يحتوي مستند CPDoS على مثال جيد لما يحدث إذا قمت بتخزين مثل هذا الطلب في ذاكرة التخزين المؤقت. عندما يخفي مهاجم طلب POST كطلب GET ، لا يتعرف الوكيل على البدائل ويتعامل مع الطلب كطلب GET شرعي. ومع ذلك ، فإن الواجهة الخلفية تتعرف على الطريقة التي تم تجاوزها وتنفذ الفعل الموصوف في رأس X-HTTP-Method-Override - POST. نظرًا لعدم تحديد طريقة POST لـ URI الوجهة ، يقوم الخادم بإنشاء خطأ. علاوة على ذلك ، يتم تخزين استجابة الواجهة الخلفية في ذاكرة التخزين المؤقت كاستجابة للطريقة الأصلية - GET. الآن أي طلب GET تالي لنفس URI سيعرض خطأ مخبأ.
POST /some-uri HTTP/1.1
X-HTTP-Method-Override: DELETE
↓ ↓ ↓
POST /some-uri?method=DELETE HTTP/1.1
الآن تبدو الطلبات بطرق مختلفة مختلفة عن ذاكرة التخزين المؤقت ، حيث تحصل على مفاتيح مختلفة. تفضل بعض الوكلاء عدم تخزين الاستجابات مؤقتًا للطلبات التي تحتوي على مكون الاستعلام في URI. ولكن هذا لن يؤثر إلا على كفاءة التخزين المؤقت. تحل هذه الطريقة دائمًا مشاكل التخزين المؤقت غير الصحيح.هناك طريقة أخرى تتمثل في ترك الأسلوب يتجاوز في رأس منفصل ، ولكن أدخل مفتاحًا ثانويًا للعثور على الإجابة في ذاكرة التخزين المؤقت. هذا ممكن مع رأس Vary. عند خدمة الطلب ، سيعيد الخادم الرأس مع تجاوز الطريقة ويعكس اسم هذا الرأس في رأس Vary. بعد ذلك ، في الطلبات التالية ، سيستخدم خادم ذاكرة التخزين المؤقت قيمة الطريقة التي تم تجاوزها كمفتاح ثانوي عند البحث عن طلب في ذاكرة التخزين المؤقت.تعمل هذه الطريقة إذا كان الخادم الوسيط يمكنه العمل مع المفاتيح الثانوية. هذا هو الحال عادة ، ولكن مستوى ثقة الوكيل ، الذي يقطع جميع الطرق باستثناء GET و POST ، عادة ما يكون أقل ومن الأفضل التحقق من ذلك.تجاوز الطريقة من خلال أي كيان داخل نص الطلب له نفس العوائق تمامًا مثل التجاوز من خلال رأس إضافي - فهو خارج رؤية ذاكرة التخزين المؤقت.هجمات وضع الرسائل في قائمة انتظار
حتى إذا تم إغلاق هجمات ذاكرة التخزين المؤقت ، فهذا ليس كل شيء. قد يحاول المهاجم عن طريق تجاوز طريقة تغيير تأطير الاستجابة وبالتالي ينتهك مراسلات أزواج الطلب والاستجابة للعملاء الآخرين. أو إجبار جانب الخادم من التطبيق على معالجة نفس الطلب عدة مرات.أهم شيء مطلوب لذلك هو خادم وسيط يعمل في وضع الوكيل العكسي. أي ، أي ذاكرة تخزين مؤقت أو خادم CDN. يدعم هذا الوكيل عددًا صغيرًا نسبيًا من الاتصالات بالخلفية ، ويضاعف الطلبات من العديد من العملاء في كل واحد منهم. يعد ذلك ضروريًا لأخذ حمل دعم عدد كبير من اتصالات العملاء من الخلفية إلى الخادم الوكيل ، ولموازنة الحمل بين الخلفية. يحدث إنهاء اتصالات TLS أيضًا على الوكيل ، ولا يتم توصيل اتصالات العميل مباشرةً بالخلفية.نظرًا لأن الطلبات الواردة من عملاء مختلفين ستكون الآن في نفس الاتصال بين الواجهة الخلفية والوكيل ، فمن الضروري الحفاظ على مراسلات واضحة بين أزواج الاستجابة للطلب. معظم وكلاء لا خط أنابيب(خطوط الأنابيب) تطلب إلى الواجهة الخلفية وتعمل معها في وضع الاستجابة للطلب. وضع الطلب والاستجابة أبسط وعرضة لتهديد واحد فعليًا - حظر الاتصال. إذا جعلت الاتصال معلقًا على زوج واحد من طلبات الاستجابة ، فيمكنك التسبب في تأخير أو حتى رفض معالجة الطلبات التالية (على سبيل المثال ، إذا نجحت في تجاوز قوائم انتظار الطلبات الخاصة بالبروكسيات).المزيد من طلبات وكلاء البروتوكولات الأكثر إنتاجية إلى الواجهة الخلفية - يتيح لك هذا إرسال حزمة من الطلبات إلى الخادم على الفور وانتظار تنفيذها. الأداء أعلى ، ولكن هناك المزيد من التهديدات. أولاً ، لا تختفي مشكلة حظر خط الرأس في أي مكان - حتى لو كان بإمكان الواجهة الخلفية تشغيل خط الاستعلام وتنفيذها بالتوازي ، فلا يمكن إرسالها إذا تم تعليق أولها. ثانيًا ، إذا قمت بكسر إطار الاستجابة ، يمكنك إرباك الوكيل وكسر مراسلات أزواج الطلب والاستجابة ، ثم قد يتلقى بعض العملاء إجابات أشخاص آخرين ، أو على الأقل تحقيق إغلاق اتصال فوري مع الواجهة الخلفية.
إعادة تشغيل البريد العشوائي تلقائيًا
قلت أعلاه أن طلبات النموذج GET + X-HTTP-Method-Override: PATCH من العملاء المحترمين سيئة. وهذا أمر سيء لأن الطرق لها خاصيتين: الأمن و idempotency . الأمان يعني أن الطريقة لا تغير حالة الخادم (للقراءة فقط) ، ولا تهمنا في سياق هذه المقالة. يضمن idempotency الأسلوب أن الطلب المتكرر له نفس تأثير طلب واحد. يمكنك رسم القياس: (a = 5)- طلب عاجل ، و (a += 2) - غير عاجل.هذا العقار هو ما يهمنا. إذا انقطع الاتصال بين العميل والخادم فجأة ، يمكن للعميل ، مع العلم أن الطريقة معاكسة ، إعادة إرسال الطلب تلقائيًا. تتصرف الوكلاء بنفس الطريقة. لا يتم تكرار الطلبات غير المصنفة تلقائيًا لأنه من غير المعروف كيف تؤثر على الخادم وما سيحصل عليه العميل في النهاية. أعتقد أن الجميع يعرف النوافذ المنبثقة في المتصفح: "هل أنت متأكد من رغبتك في تكرار الطلب؟"إذا قمت بإخفاء طريقة غير idempotent باعتبارها idempotent ، فلن يتم تجاهلها في حالة حدوث أخطاء ، ولكن سيتم إعادة توجيهها إلى الخادم مرة أخرى. حتى إذا كان العميل سيأخذ في الاعتبار طريقة الطلب الحقيقية قبل إعادة إرسال الطلب ، فإن هذا لن يساعد كثيرًا ، لأن الخادم الوكيل ليس على دراية بتجاوز الطريقة وسيكرر مثل هذه الطلبات.إذا كان المهاجم قادرًا على فرض قطع الاتصال بين الواجهة الخلفية والعملاء ، فيمكنه أن يتسبب في قيام الخادم بتنفيذ طلبات غير متطابقة عدة مرات وتقليل موثوقية التطبيق وإمكانية التنبؤ به. في القسم السابق ، وجدنا للتو طريقة يمكنك من خلالها قطع فواصل الاتصال بنفس الطريقة التي تم تجاوزها. على الرغم من أنه يجب أن نتذكر أن الإنترنت هي شبكة غير موثوقة ، من حيث التعريف ، والتطبيق نفسه في خطر.للحماية من هذا الهجوم ، يجب عليك استخدام الطرق التي لا تضيف خصائص جديدة إلى الطلب كنقل. POST هو مرشح جيد ، لأنه بشكل افتراضي ليس آمنًا ولا عديم القوة.أن HTTP / 1.1 القديم ، كما هو الحال مع HTTP / 2؟
قام HTTP / 2 بتغيير طريقة نقل الطلبات بين العقد ، ولكنه لم يغير معناها المعجمى. لذلك ، في تلك الهجمات التي تتعلق بقيمة الطلب ، يتصرف HTTP / 2 بالطريقة نفسها. لكن هجمات "النقل" لا يتم استنساخها ، حيث يتم أخذها بالفعل في الاعتبار في المعيار.يتم تكرار الهجمات على ذاكرة التخزين المؤقت بطريقة مماثلة لبروتوكول HTTP / 1 ، والحماية متشابهة. لا تنطبقهجمات خدمة وضع الرسائل في قائمة انتظار على HTTP / 2. تنقسم رسائل HTTP الموجودة بها إلى إطارات منفصلة ، مع رؤوس إطارات منفصلة تحدد بوضوح طول ونهاية الرسالة. كما لو أن المهاجم لن يقوم بتغيير الطريقة وتعديل رؤوس HTTP ، فلن يؤثر ذلك على إطار الرسالة. ستفشل سرقة الإجابة.الهجمات على تكرار الرسائل غير المتشددة قابلة للتطبيق حتى مع الأخذ في الاعتبار حقيقة أنه في HTTP / 2 هناكآلية الإخطار لآخر طلب تمت معالجته . في HTTP / 2 ، يتم ضرب الطلبات المتعددة في نفس TCP وبالتالي إنشاء التدفقات . كل خيط له رقمه الخاص. إذا انقطع اتصال خادم HTTP / 2 ، فيمكن أن يشير إلى رقم آخر طلب تمت معالجته في GOAWAY. دائمًا ما تكون الطلبات ذات الرقم الأعلى آمنة لإعادة التوجيه ؛ أما الطلبات ذات الرقم الأقل ، فلا تتم إعادة توجيهها إلا إذا كانت عاطفة. إذا كان الطلب باستخدام طريقة تم تجاوزها يبدو وكأنه غير صالح لخادم وكيل ، فسيقوم الوكيل بإعادة توجيهه إلى الخادم.كيفية تجاوز الطريقة بأمان
الجواب القصير ليس بأي حال من الأحوال. من الأفضل عدم استخدام تجاوزات الطريقة على الإطلاق. وتعطيل الدعم تمامًا في الخلفية ، إن وجد. حظر عملاء HTTP أساليب تجاوز. رفض الوكيل / WAF ، الذي يقطع الطرق "الإضافية".إذا كان عليك العيش بطريقة ما مع إعادة تعريف الطريقة ، فعندئذٍ لمنع ما يكفي من التعديلات على الواجهة الخلفية. أولاً ، من المستحسن تجاوز الطريقة فقط من خلال مكون الاستعلام الخاص بـ URI.ثانياً ، يجب أن تكون هناك قائمة بيضاء لتغيير الأساليب: مقبولة ك "نقل" والتي هي الناتجة. لا ينبغي أن تكون هناك وظائف تحويل معممة عندما يمكن تجاوز أي طريقة من قبل أي. لا يجب أن تحتوي طريقة "النقل" على خصائص الأمان والضعف إذا لم تكن الطريقة الناتجة. يجب حظر التحولات الخطيرة ، نفس الاستبدال GET -> HEAD.هل أحتاج إلى تصحيح مشكلة وكيل / WAF؟
إذا قام الوكيل بتنفيذ طريقتين GET و POST فقط ، وحظر الآخرين لسبب أو لآخر ، فبالتأكيد نعم. يمكنك تحسينها بشكل أساسي لـ GET و POST ، ولكن حظر الطرق الأخرى فكرة سيئة. ما الذي لا يزال يخلق فجوة من عدم الثقة في المنتج: إذا تم حظر الأشياء الأساسية ، فماذا تتوقع من تنفيذ مشاكل أكثر تعقيدًا؟إذا كنت قلقًا بشأن أمان تطبيقات الويب المحمية ، فقد يكون من المفيد تأمين التطبيقات من سياسات إلغاء الطريقة غير الآمنة. بالطبع ، في الحالة العامة ، من دون معرفة تفاصيل تطبيق تطبيق الويب ، من المستحيل حماية التطبيق بالكامل من تجاوزات غير صحيحة ، ولكن يمكنك جزئيًا تغطية المستخدمين الذين لا يعرفون ببساطة المشكلة. من الضروري ليس فقط الحماية من التسمم في ذاكرة التخزين المؤقت الخاصة بك ، ولكن أيضًا لتمكين تمكين أو تعطيل التجاوز لكل تطبيق محمي. للقيام بذلك ، تتبع الرؤوس المستخدمة بشكل شائع.X-HTTP-Method و X-HTTP-Method-Override و X-Method-Override. تتبع إعادة التعريف في مكون الاستعلام في URI لا معنى له: ذاكرة التخزين المؤقت لا تسمم مثل هذا الطلب ، ويمكن أن يكون الاستعلام طويلًا جدًا ولديه تنسيق عشوائي تمامًا.?
مطورو الأمان ، لا تقصر مطوري التطبيقات على سياسات الأمان. سيجدون كيفية الالتفاف حولهم ، وكلما كان البروتوكول أكثر مرونة ، كان من الأسهل القيام بذلك. من المحتمل جدًا أنهم لن يركلوك وينتظروا حتى تجعل القيود أكثر منطقية ، ولكن ببساطة تجاوزها.إذا اكتشفت كيفية تنفيذ شيء ما في البروتوكول ، ولكنه يتخطى أو يتعارض مع أحد المفاهيم الأساسية للمعيار ، فستظهر بالتأكيد مشكلات التوافق والأمن. ويجب تغطيتها في نفس وقت القرار. كل مره. إذا قابلت هذه النصيحة ولم تشاهد تحذيرات أمنية ، فلا تكرر النصيحة في جميع أنحاء الإنترنت. انتقد القرار دائمًا واكتشف الأخطاء التي قد تحدث .بدلا من كلمة ختامية
ما مشاكل الخادم الوكيل التي واجهتها؟ ما الذي يجب التحايل عليه وكيف؟