تغییرات 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 کوچک‌تر از ۲۰۴۸ بیت و کلیدهای ECC کوچک‌تر از ۲۲۴ بیت به‌طور پیش‌فرض پذیرفته می‌شدند. بااین‌حال، با این به‌روزرسانی، چنین کلیدهایی دیگر برای اتصالات TLS یک‌طرفه و دوطرفه برای درخواست‌های شمالی مجاز نخواهند بود.

ضمیمه

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

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

  1. نام‌های سرایند خاصی که قبلاً مجاز بودند اکنون در Nginx 1.26 مجاز نیستند. درخواست‌های دارای این سرایندها منجر به خطای ۴۰۰ درخواست بد می‌شود.
  2. برخی‌از مقادیر سرایند که قبلاً مجاز بودند اکنون در Nginx 1.26 مجاز نیستند. درخواست‌های دارای این سرایندها نیز منجر به خطای 400 درخواست بد خواهند شد.
  3. برخی‌از سرایندهایی که قبلاً توسط Nginx پذیرفته می‌شدند اما باعث خرابی در پردازنده پیام می‌شدند اکنون مستقیماً توسط Nginx رد می‌شوند. اگرچه این سرایندها همچنان منجر به خطاهای API می‌شوند، پیام‌های خطای 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) 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 روی ۴۰۰ باقی خواهد ماند. بااین‌حال، بدنه پاسخ 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"}