تغييرات Nginx 1.30 في الإصدار 4.54.00 من Apigee Edge

نظرة عامة على تغييرات Nginx

يتضمّن Apigee Edge for Private Cloud 4.54.00 ترقية إلزامية إلى الإصدار 1.30 من Nginx على أجهزة توجيه Edge.

مع إصدار Nginx 1.26، تم تقديم العديد من التغييرات المهمة لتعزيز الأمان وضمان الامتثال لمعايير HTTP. في ما يلي التحديثات الرئيسية:

التعامل مع المسافات البيضاء في أسماء العناوين وقيمها

لتحسين الأمان، تم تعزيز الالتزام بالمواصفة RFC 7230، لا سيما ما يتعلّق بالتعامل مع المسافات البيضاء في العناوين. يمكنك الاطّلاع على مزيد من التفاصيل حول هذه التغييرات في الملحق.

التعامل مع عنوانَي Content-Length وTransfer-Encoding

إحدى التقنيات الشائعة المستخدَمة في هجمات تهريب الطلبات تتضمّن إرسال طلبات HTTP تتضمّن عنوانَي Content-Length وTransfer-Encoding. على الرغم من أنّ Apigee Edge كان محصّنًا من قبل ضدّ هذه الهجمات، يحظر Nginx الآن بشكلٍ صريح الطلبات التي تتضمّن كلا العنوانَين. في حال إرسال مثل هذا الطلب، سيردّ Nginx برسالة خطأ 400: طلب غير صالح.

الخوارزميات المشفّرة المتاحة

قد تتغيّر قائمة الخوارزميات المشفّرة المتاحة للطلبات الواردة مع هذا الإصدار. يمكنك الاطّلاع على الخوارزميات المشفّرة التي يتيحها OpenSSL على مضيف جهاز التوجيه للحصول على القائمة المعدَّلة للخوارزميات المشفّرة المتاحة.

أحجام المفاتيح المتاحة

في السابق، كان يتم قبول مفاتيح RSA وDSA وDH التي يقل حجمها عن 2048 بت ومفاتيح ECC التي يقل حجمها عن 224 بت تلقائيًا. ومع ذلك، لن يُسمح بعد الآن باستخدام هذه المفاتيح لاتصالات بروتوكول أمان طبقة النقل (TLS) أحادية الاتجاه وثنائية الاتجاه للطلبات الواردة.

الملحق

المسافات البيضاء في العناوين

هناك ثلاثة تغييرات أساسية:

  1. يحظر الإصدار 1.26 من Nginx الآن بعض أسماء العناوين التي كانت مسموحًا بها سابقًا. وستؤدي الطلبات التي تتضمّن هذه العناوين إلى ظهور رسالة الخطأ 400: طلب غير صالح.
  2. يحظر الإصدار 1.26 من Nginx الآن بعض قيم العناوين التي كانت مسموحًا بها سابقًا. وستؤدي الطلبات التي تتضمّن هذه العناوين أيضًا إلى ظهور رسالة الخطأ 400: طلب غير صالح.
  3. يرفض Nginx الآن بشكلٍ مباشر بعض العناوين التي كان يقبلها سابقًا ولكنها كانت تؤدي إلى حدوث حالات فشل في معالج الرسائل في المراحل اللاحقة. على الرغم من أنّ هذه العناوين لا تزال تؤدي إلى حدوث حالات فشل في واجهة برمجة التطبيقات، ستتغيّر رسائل الخطأ في HTTP.

يقدّم القسم أدناه أمثلة على أسماء العناوين وقيمها المختلفة غير المسموح بها. هذه مجرد أمثلة وقد لا تكون قائمة شاملة. يُنصح بالالتزام بإرشادات المواصفة RFC 7230 للعناوين.

التغييرات في أسماء العناوين

يسرد هذا القسم أسماء العناوين المختلفة التي كانت مسموحًا بها في الإصدار 1.20.1 من Nginx ولكنها غير مسموح بها الآن في الإصدار 1.26 من Nginx.

السيناريو أمثلة على أسماء العناوين
حرف تحكّم في بداية اسم العنوان أو نهايته أو بينهما { '\u0001'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ Header'\u0005'4, Value4 }
مسافة بيضاء بادئة ولاحقة في اسم العنوان {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
علامة جدولة أفقية (HTAB) بادئة ولاحقة في اسم العنوان {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
مزيج من علامة جدولة أفقية (HTAB) ومسافة بيضاء (WS) بادئة ولاحقة في اسم العنوان {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
سطر جديد (\n) بين اسم العنوان يليه مباشرةً مسافة بيضاء أو سلسلة من المسافات البيضاء {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
سطر جديد (\n) بين اسم العنوان يليه مباشرةً علامة جدولة أفقية (HTAB) أو سلسلة من علامات الجدولة الأفقية {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
رجوع إلى أول السطر (\r) سطر جديد (\n) بين اسم العنوان يليه مباشرةً علامة جدولة أفقية (HTAB) أو سلسلة من علامات الجدولة الأفقية {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
رجوع إلى أول السطر ( ) سطر جديد ( ) بين اسم العنوان يليه مباشرةً مسافة بيضاء أو سلسلة من المسافات البيضاء {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

التغييرات في قيم العناوين

يعرض هذا القسم قيم العناوين المختلفة التي كانت مسموحًا بها في الإصدار 1.20.1 من Nginx ولكنها غير مسموح بها في الإصدار 1.26 من Nginx.

السيناريو أمثلة
يُسمح باستخدام ‎\r\n أو مزيج من ‎\r\n مع مسافة بيضاء أو علامة جدولة أفقية بين HEADERVALUE {"Header47", "Value47\r\n MultiLine"},
{"Header48", "Value48\r\n MultiLine"},
{"Header49b", "Value49b\r\n \r\nMultiLine"},
{"Header50", "Value50 \r\n MultiLine"},
{"Header51", "Value51\r\n\tMultiLine"},
{"Header52", "Value52\r\n\t\tMultiLine"},
{"Header53", "Value53\t\r\n\tMultiLine"}
يُسمح باستخدام ‎\n أو مزيج من ‎\n مع مسافة بيضاء أو علامة جدولة أفقية بين HEADERVALUE {"Header61", "Value\n 61Multiline"},
{"Header62", "Value\n 63Multiline"},
{"Header65", "Value\n\t65"},
{"Header66", "Value\n\t\t66"},
{"Header67", "Value\n 67"},
{"Header68", "Value\n 68"}

التغيير في استجابة الخطأ في HTTP

يتناول هذا القسم العناوين التي كان يسمح بها الإصدار القديم من Nginx ولكن كان يرفضها معالج الرسائل في المراحل اللاحقة، ما يؤدي إلى ظهور رمز الحالة 400. ومع ذلك، في الإصدار 1.26 من Nginx، تؤدي هذه العناوين إلى حدوث حالات فشل مباشرةً في Nginx، ما يمنع إعادة توجيه الطلب إلى معالج الرسائل.

بالنسبة إلى العملاء الذين يرسلون هذه العناوين، سيظل رمز حالة HTTP هو 400. ومع ذلك، قد يتغيّر نص استجابة HTTP لأنّ Nginx هو الذي سينشئ الآن حالة الفشل بدلاً من معالج الرسائل.

السيناريو أمثلة
علامة جدولة أفقية أو مسافة بيضاء بين HEADERNAME

يرفض معالج الرسائل هذه الطلبات. مع الإصدار 1.26 من Nginx، سيرفض Nginx نفسه هذه الطلبات. سيتلقّى مستهلك واجهة برمجة التطبيقات استجابة خطأ 400 تتضمّن رسالة خطأ من Nginx في النص.

 {"Header 5", "Value5"},
{"Header\t14", "Value14"},
{"Header\t 32", "Value32"},
{"Header \t33", "Value33"},
{"Header- 36", "Value36"},
{"Header-\t40", "Value40"},
{"Header 4a", "Value4a"},
{"Header\t 59", "Value59"},
{"Header\t 60", "Value60"}