تغییرات 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 Bad Request پاسخ خواهد داد.

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

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

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

قبلاً کلیدهای RSA، DSA و DH کوچکتر از 2048 بیت و کلیدهای ECC کوچکتر از 224 بیت به طور پیش فرض پذیرفته می شدند. با این حال، با این به روز رسانی، چنین کلیدهایی دیگر برای اتصالات TLS یک طرفه و دو طرفه برای درخواست های شمال مجاز نخواهند بود.

ضمیمه

فضای خالی در سرصفحه ها

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

  1. برخی از نام‌های هدر که قبلا مجاز بودند، اکنون توسط Nginx 1.26 غیرمجاز هستند. درخواست هایی با این سربرگ ها منجر به خطای 400 Bad Request می شود.
  2. برخی از مقادیر هدر که قبلا مجاز بودند اکنون توسط Nginx 1.26 غیرمجاز هستند. درخواست هایی با این هدرها نیز منجر به خطای 400 Bad Request می شود.
  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) NewLine (\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\nچند خط"}،
{"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

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