Apigee Edge 4.53.00'daki Nginx 1.26 değişiklikleri

Nginx 1.26 değişikliklerine genel bakış

Nginx 1.26'nın yayınlanmasıyla birlikte, güvenliği artırmak ve HTTP standartlarına uygunluğu sağlamak için çeşitli önemli değişiklikler yapıldı. Önemli güncellemeler şunlardır:

Başlık adları ve değerlerinde boşluk kullanımı

Güvenlik iyileştirmesi kapsamında, özellikle üstbilgilerdeki boşlukların işlenmesi konusunda RFC 7230'a uyma durumu güçlendirildi. Bu değişikliklerle ilgili daha fazla bilgiyi Ek'te bulabilirsiniz.

Content-Length ve Transfer-Encoding başlıklarının işlenmesi

İstek kaçakçılığı saldırılarında kullanılan yaygın tekniklerden biri, hem Content-Length hem de Transfer-Encoding üstbilgileriyle HTTP istekleri göndermeyi içerir. Apigee Edge bu tür saldırılara karşı zaten güçlendirilmiş olsa da Nginx artık her iki başlığı da içeren istekleri açıkça engelliyor. Bu tür bir istek gönderilirse Nginx, 400 Hatalı İstek hatasıyla yanıt verir.

Desteklenen şifreler

Kuzeye doğru istekler için desteklenen şifrelerin listesi bu sürümle birlikte değişebilir. Mevcut şifrelerin güncel listesini almak için yönlendirici ana makinenizde OpenSSL tarafından desteklenen şifreleri kontrol edebilirsiniz.

Desteklenen anahtar boyutları

Daha önce 2048 bitten küçük RSA, DSA ve DH anahtarları ve 224 bitten küçük ECC anahtarları varsayılan olarak kabul ediliyordu. Ancak bu güncellemeyle birlikte, kuzeye giden istekler için hem tek yönlü hem de iki yönlü TLS bağlantılarında bu tür anahtarlara artık izin verilmeyecektir.

Ek

Başlıklarda boşluk

Üç temel değişiklik vardır:

  1. Daha önce izin verilen belirli üstbilgi adlarına Nginx 1.26'da artık izin verilmiyor. Bu üstbilgilerin yer aldığı istekler 400 Hatalı İstek hatasıyla sonuçlanır.
  2. Daha önce izin verilen belirli başlık değerlerine Nginx 1.26'da artık izin verilmiyor. Bu üstbilgilerin yer aldığı istekler de 400 Hatalı İstek hatasına neden olur.
  3. Daha önce Nginx tarafından kabul edilen ancak ileti işleyicide aşağı akışta hatalara neden olan bazı üstbilgiler artık doğrudan Nginx tarafından reddediliyor. Bu üstbilgiler API hatalarına neden olmaya devam etse de HTTP hata mesajları değişecek.

Aşağıdaki bölümde, izin verilmeyen çeşitli başlık adları ve başlık değerlerine örnekler verilmiştir. Bunlar yalnızca örnek niteliğindedir ve kapsamlı bir liste olmayabilir. Üstbilgilerle ilgili olarak RFC 7230 kurallarına uymanız önerilir.

Üstbilgi adlarında yapılan değişiklikler

Bu bölümde, Nginx 1.20.1'de izin verilen ancak artık Nginx 1.26'da izin verilmeyen çeşitli üstbilgi adları listelenmiştir.

Senaryo Üstbilgi adı örnekleri
Başlıkta, sonda veya başlığın ortasında kontrol karakteri { '\u0001'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ Header'\u0005'4, Value4 }
Üstbilgi adında başta ve sonda boşluk {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
Üstbilgi adında başta ve sonda HTAB olması {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
Üstbilgi adında HTAB ve WS'nin baş ve sona eklenmiş hali {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
Başlık adı ile hemen ardından gelen WS veya bir dizi WS arasında yeni satır ("NewLine" (\n)) {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
Başlık adı ile hemen ardından gelen HTAB veya bir dizi HTAB arasında yeni satır ("newLine" (\n)) {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
Üstbilgi adı ile hemen ardından gelen HTAB veya bir dizi HTAB arasında satır başı karakteri (\r) ve yeni satır karakteri (\n) {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
Üstbilgi adı ile hemen ardından gelen WS veya bir dizi WS arasında satır başı karakteri (\r) yeni satır (\n) {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

Üstbilgi değerlerinde yapılan değişiklikler

Bu bölümde, Nginx 1.20.1'de izin verilen ancak Nginx 1.26'da izin verilmeyen çeşitli başlık değerleri gösterilmektedir.

Senaryo Örnekler
HEADERVALUE arasında \r\n veya \r\n ile WS veya HTAB kombinasyonuna izin verilir. {"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"}
HEADERVALUE arasında \n veya \n ile WS veya HTAB kombinasyonuna izin verilir {"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 hata yanıtında değişiklik

Bu bölümde, eski Nginx tarafından izin verilen ancak yayın öncesi mesaj işleyicisi tarafından reddedilen ve 400 durum koduyla sonuçlanan başlıklar ele alınmaktadır. Ancak Nginx 1.26'da bu tür üstbilgiler doğrudan Nginx'te hatalara neden olarak isteğin mesaj işleyiciye yönlendirilmesini engeller.

Bu tür üstbilgileri gönderen istemciler için HTTP durum kodu 400 olarak kalır. Ancak hata artık mesaj işleyici yerine Nginx tarafından oluşturulacağından HTTP yanıt gövdesi değişebilir.

Senaryo Örnekler
HEADERNAME arasında HTAB veya WS

Mesaj İşleyici bu tür istekleri reddeder. Nginx 1.26'da bu istekler Nginx tarafından reddedilir. API tüketicisi, gövdesinde Nginx hata mesajı bulunan bir 400 hata yanıtı alır.

 {"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"}