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 bağlılık güçlendirildi. Bu değişikliklerle ilgili daha ayrıntılı bilgiyi Ek bölümünde bulabilirsiniz.

Content-Length ve Transfer-Encoding üstbilgilerinin kullanımı

İ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. Böyle 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üncellenmiş 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 söz konusudur:

  1. Önceden izin verilen belirli üst bilgi adlarına artık Nginx 1.26 tarafından izin verilmemektedir. Bu üstbilgilerin yer aldığı istekler 400 Hatalı İstek hatasıyla sonuçlanır.
  2. Daha önce izin verilen belirli üstbilgi değerlerine artık Nginx 1.26 tarafından izin verilmemektedir. Bu üstbilgilere sahip 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şir.

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. Üstbilgiler için 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 başlık adları listelenmektedir.

Senaryo Üstbilgi adı örnekleri
Baştaki, sondaki veya başlık adının arasındaki kontrol karakteri { '\u0001'Başlık0, Değer0 }
{ Başlık6'\u0002', Değer6 }
{ Başlık'\u0005'4, Değer4 }
Öncü ve başlık adının sonunda boşluk var {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
Öncü ve başlık adının sondaki HTAB {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
Öncü ve başlık adında sondaki HTAB, WS kombinasyonu {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
Başlık adı arasında NewLine (\n) ve ardından WS veya bir dizi WS hemen ardından {"Header\n 57Mutiline", "Value57"}
{"Başlık\n 58 Çok Kanallı", "Değer58"}
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"}
Başlık adı ile hemen ardından gelen HTAB veya bir dizi HTAB arasında satır başı karakteri (\r) ve yeni satır (\n) {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
Başlık 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
\r\n veya WS veya HTAB ile olan \r\n kombinasyonuna HEADLINEVALUE arasında 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"}
\n veya WS ya da HTAB içeren \n kombinasyonuna HEADLINEVALUE arasında izin verilir {"Header61", "Değer\n 61Multiline"},
{"Header62", "Değer\n 63Multiline"},
{"Header65", "Değer\n\t65"},
{"Header66", "Değer\n\t\t66"},
{"Header67", "Değer\n 67"},
{"Header68", "Değer\n 68"}

HTTP hatası yanıtında değişiklik

Bu bölüm, eski Nginx tarafından izin verilen ancak yukarı akış ileti işlemcisi tarafından reddedilen ve 400 durum koduyla sonuçlanan üstbilgileri kapsar. 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 ileti işlemcisi 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 ile bu istekler Nginx tarafından reddedilecektir. API tüketicisi, gövdesinde bir Nginx hata mesajı bulunan 400 hata yanıtı alır.

 {"Başlık 5", "Değer5"},
{"Başlık\t14", "Değer14"},
{"Başlık\t 32", "Değer32"},
{"Başlık \t33", "Değer33"},
{"Başlık- 36", "Değer36"},
{"Başlık-\t40", "Değer40"},
{"Başlık 4a", "Value4a"},
{"Başlık\t 59", "Value59"},
{"Header\t 60", "Value60"}