تغييرات Nginx 1.26 في Apigee Edge 4.53.01

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

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

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

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

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

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

الشفرات المتوافقة

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

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

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

الملحق

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

في ما يلي التغييرات الأساسية الثلاثة:

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

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

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

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

السيناريو أمثلة على أسماء العناوين
حرف تحكّم في البداية أو النهاية أو بين اسم العنوان { '\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"‎}
NewLine (\n) بين اسم العنوان متبوعًا مباشرةً بمسافة بيضاء أو سلسلة من المسافات البيضاء {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
NewLine (\n) بين اسم العنوان يليه HTAB مباشرةً أو سلسلة من HTAB {‎"Header\n\t73", "Value73"‎}
{‎"Header\n\t\t74", "Value74"‎}
يجب أن يكون هناك فاصل بين اسم العنوان وNewline (\n) أو Carriage return (\r) يليه مباشرةً HTAB أو سلسلة من HTAB {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
يجب أن يكون هناك حرف إرجاع السطر (\r) وحرف سطر جديد (\n) بين اسم العنوان متبوعًا مباشرةً بمسافة بيضاء أو سلسلة من المسافات البيضاء. {‎"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

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

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

السيناريو أمثلة
\r\n أو مزيج من \r\n مع WS أو HTAB مسموح به بين 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 مع WS أو HTAB بين 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. ومع ذلك، في Nginx 1.26، تتسبّب هذه العناوين في حدوث أعطال مباشرةً في Nginx، ما يمنع إعادة توجيه الطلب إلى معالج الرسائل.

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

السيناريو أمثلة
HTAB أو WS بين 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"‎}