تغییرات Nginx 1.30 در Apigee Edge 4.54.00

نمای کلی تغییرات Nginx

Apigee Edge برای Private Cloud نسخه ۴.۵۴.۰۰ شامل ارتقای اجباری به Nginx نسخه ۱.۳۰ در Edge Routers است.

با انتشار Nginx 1.26، چندین تغییر مهم برای بهبود امنیت و اطمینان از رعایت استانداردهای HTTP معرفی شده است. به‌روزرسانی‌های کلیدی در زیر آمده است:

مدیریت فاصله سفید در نام‌ها و مقادیر سرایند

برای بهبود امنیت، پایبندی به RFC 7230 به‌ویژه درخصوص مدیریت فضای سفید در سرایندها تقویت شده است. جزئیات بیشتر درباره این تغییرات را می‌توانید در پیوست پیدا کنید.

مدیریت سرصفحه‌های Content-Length و Transfer-Encoding

یکی از تکنیک‌های رایج مورداستفاده در حملات قاچاق درخواست شامل ارسال درخواست‌های HTTP با هر دو سرایند Content-Length و Transfer-Encoding است. درحالی‌که Apigee Edge ازقبل دربرابر چنین حملاتی تقویت شده بود، Nginx اکنون به‌طور صریح درخواست‌هایی را که حاوی هر دو سرصفحه هستند مسدود می‌کند. اگر چنین درخواستی ارسال شود، Nginx با خطای 400 Bad Request پاسخ خواهد داد.

رمزهای پشتیبانی‌شده

فهرست رمزهای پشتیبانی‌شده برای درخواست‌های northbound ممکن است با این نسخه تغییر کند. می‌توانید رمزهای پشتیبانی‌شده توسط OpenSSL را در میزبان روتر خود بررسی کنید تا فهرست به‌روزشده رمزهای دردسترس را دریافت کنید.

اندازه‌های کلید پشتیبانی‌شده

قبلاً، کلیدهای RSA،‏ DSA، و DH کوچک‌تر از ۲۰۴۸ بیت و کلیدهای ECC کوچک‌تر از ۲۲۴ بیت به‌طور پیش‌فرض پذیرفته می‌شدند. اما با این به‌روزرسانی، چنین کلیدهایی دیگر برای اتصال‌های TLS یک‌طرفه و دوطرفه برای درخواست‌های شمال‌گرا مجاز نخواهند بود.

ضمیمه

فاصله سفید در سرایندها

سه تغییر اصلی وجود دارد:

  1. برخی‌از نام‌های سرایند که قبلاً مجاز بودند اکنون توسط Nginx 1.26 غیرمجاز شده‌اند. درخواست‌های دارای این سرایندها منجر به خطای ۴۰۰ درخواست بد می‌شود.
  2. برخی‌از مقادیر سرصفحه که قبلاً مجاز بودند، اکنون توسط Nginx 1.26 غیرمجاز شده‌اند. درخواست‌های دارای این سرصفحه‌ها نیز منجر به خطای ۴۰۰ درخواست بد می‌شود.
  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"}
خط جدید (\n) بین نام سرصفحه که بلافاصله WS یا مجموعه‌ای از WS به‌دنبال آن می‌آید {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
خط جدید (\n) بین نام سرایند که بلافاصله پس‌از آن HTAB یا مجموعه‌ای از HTAB آمده است {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
بازگشت نورد (\r) NewLine (\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 قدیمی مجاز شده‌اند اما توسط پردازشگر پیام بالادستی رد شده‌اند و منجر به رمز وضعیت ۴۰۰ شده‌اند. بااین‌حال، در Nginx 1.26، چنین سرایندهایی مستقیماً باعث خرابی در Nginx می‌شوند و از بازارسال درخواست به پردازشگر پیام جلوگیری می‌کنند.

برای مشتریانی که چنین سرصفحه‌هایی ارسال می‌کنند، رمز وضعیت اچ‌تی‌تی‌پی‌اس همچنان ۴۰۰ خواهد بود. بااین‌حال، بدنه پاسخ‌های HTTP ممکن است تغییر کند زیرا اکنون خرابی به‌جای پردازشگر پیام توسط Nginx ایجاد می‌شود.

سناریو مثال‌ها
‫HTAB یا WS بین HEADERNAME

«پردازشگر پیام» چنین درخواست‌هایی را رد می‌کند. با Nginx 1.26، این درخواست‌ها توسط خود Nginx رد خواهند شد. مصرف‌کننده API پاسخ خطای ۴۰۰ را با پیام خطای 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"}