Apigee Edge 4.53.01'deki 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ı. Başlıca güncellemeler şunlardır:

Başlık adları ve değerlerindeki boşlukların işlenmesi

Güvenliği artırmak için RFC 7230'a uygunluk güçlendirildi. Özellikle üstbilgilerdeki boşlukların işlenmesiyle ilgili iyileştirmeler yapıldı. Bu değişiklikler hakkında daha fazla bilgiyi Ek bölümünde 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 üst bilgileri içeren 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 Bad Request hatasıyla yanıt verir.

Desteklenen şifreler

Kuzeye giden istekler için desteklenen şifrelerin listesi bu sürümle birlikte değişebilir. Kullanılabilir ş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ı ile 224 bitten küçük ECC anahtarları varsayılan olarak kabul ediliyordu. Ancak bu güncelleme ile birlikte, bu tür anahtarlara artık kuzeye giden istekler için hem tek yönlü hem de çift yönlü TLS bağlantılarında izin verilmeyecek.

Ek

Başlıklardaki boşluk

Başlıca üç değişiklik şunlardır:

  1. Daha önce izin verilen belirli üstbilgi adlarına artık Nginx 1.26 tarafından izin verilmiyor. Bu üstbilgileri içeren istekler 400 Bad Request (Hatalı İstek) hatasıyla sonuçlanır.
  2. Daha önce izin verilen belirli başlık değerlerine artık Nginx 1.26 tarafından izin verilmiyor. Bu üstbilgileri içeren istekler de 400 Bad Request (Hatalı İstek) hatasıyla sonuçlanır.
  3. Daha önce Nginx tarafından kabul edilen ancak ileti işlemcisinde aşağı akışta hatalara neden olan bazı üstbilgiler artık doğrudan Nginx tarafından reddediliyor. Bu başlıklar hâlâ API hatalarına yol açsa da HTTP hata mesajları değişecektir.

Aşağıdaki bölümde, izin verilmeyen çeşitli başlık adları ve başlık değerleriyle ilgili örnekler verilmiştir. Bunlar yalnızca örnek niteliğindedir ve kapsamlı bir liste olmayabilir. Üst bilgiler için RFC 7230 yönergelerine uyulması önerilir.

Üstbilgi adlarındaki değişiklikler

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

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

Üstbilgi değerlerindeki 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 WS ya da HTAB ile \r\n 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 içinde \n veya \n ile WS ya da 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 hatası yanıtındaki değişiklik

Bu bölümde, eski Nginx tarafından izin verilen ancak yukarı akış mesajı işlemcisi tarafından reddedilen ve 400 durum koduyla sonuçlanan başlıklar ele alınmaktadır. Ancak Nginx 1.26'da bu tür başlıklar doğrudan Nginx'te hatalara neden olarak isteğin ileti işlemcisine iletilmesini engeller.

Bu tür başlıklar gönderen istemciler için HTTP durum kodu 400 olarak kalır. Ancak, hata artık mesaj 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 reddedilir. API tüketicisi, gövdede bir Nginx hata mesajı içeren 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"}