التغييرات في Nginx 1.26 في Apigee Edge 4.53.00

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

مع إصدار 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. بعض أسماء العناوين التي تم السماح بها سابقًا لا يسمح بها Nginx 1.26 الآن. ستؤدي الطلبات التي تحتوي على هذه العناوين إلى ظهور الخطأ 400 طلب غير صالح.
  2. لا يسمح إصدار Nginx 1.26 الآن ببعض قيم الرأس التي كانت مسموحًا بها في السابق. وستؤدي الطلبات التي تحتوي على هذه العناوين أيضًا إلى ظهور الخطأ 400 طلب غير صالح.
  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"}
{" الرأس3"، "القيمة3"}
{" Header4 "، "القيمة4"}
القيادة علامة HTAB اللاحقة في اسم العنوان {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
مجموعة HTAB وWS في بداية اسم الرأس وآخره {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
خط جديد (\n) بين اسم العنوان متبوعًا بـ WS أو سلسلة من WS {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
فاصل سطر (\n) بين اسم العنوان متبوعًا مباشرةً بـ HTAB أو سلسلة من HTAB {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
أحرف الرجوع إلى بداية السطر (\r) خط جديد (\n) بين اسم العنوان متبوعًا بـ 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 مسموح بها بين معرفVALUE {"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"، "القيمة\n 61 Multiline"}،
{"Header62"، "القيمة\n 63Multiline"}،
{"Header65"، "القيمة\n\t65"}،
{"Header66"، "القيمة\n\t\t66"}،
{"Header67"، "القيمة\n 67"}،
{"Header68"، "القيمة\n 68"}

تغيير في استجابة فشل HTTP

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

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

السيناريو أمثلة
HTAB أو WS بين HEADERNAME

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

 {"العنوان 5"، "القيمة5"}،
{"Header\t14", "القيمة14"},
{"Header\t 32", "Value32"},
{"Header\t33", "Value33"},
{"Header- 36", "Value36"},
{"Header-\t40", "قيمة40"},
{"Header 4a", "Value4a"},
{"Header\t 59", "Value59"},
{"Header\t 60", "Value60"}