نظرة عامة على التغييرات في 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) أحادية الاتجاه وثنائية الاتجاه لطلبات التوجيه من الشمال إلى الجنوب.
الملحق
المسافة البيضاء في العناوين
هناك ثلاثة تغييرات أساسية:
- لا يسمح إصدار Nginx 1.26 الآن بأسماء عناوين معيّنة كانت مسموحًا بها في السابق. ستؤدي الطلبات التي تتضمّن هذه العناوين إلى ظهور خطأ 400 (الخطأ "الطلب غير صالح").
- لا يسمح إصدار Nginx 1.26 الآن ببعض قيم الرأس التي كانت مسموحًا بها في السابق. ستؤدي الطلبات التي تتضمّن هذه العناوين أيضًا إلى ظهور خطأ 400 (طلب غير صالح).
- يرفض 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) بين اسم العنوان متبوعًا مباشرةً بعنصر 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) بين اسم العنوان وعلامة WS أو سلسلة من علامات WS. | {"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. ومع ذلك، في الإصدار 1.26 من Nginx، تؤدي هذه الرؤوس إلى حدوث أعطال في 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"} |