Apigee Edge 4.54.00'deki Nginx 1.30 değişiklikleri

Nginx değişikliklerine genel bakış

Apigee Edge for Private Cloud 4.54.00, Edge yönlendiricilerde Nginx 1.30 sürümüne zorunlu bir yükseltme içerir.

Nginx 1.26'nın kullanıma sunulmasıyla birlikte, güvenliği artırmak ve HTTP standartlarına uygunluğu sağlamak için birkaç önemli değişiklik yapıldı. Başlıca güncellemeler şunlardır:

Başlık adlarında ve değerlerinde boşluk işleme

Güvenliği artırmak için RFC 7230'a uyum, özellikle üstbilgilerdeki boşlukların işlenmesiyle ilgili olarak güçlendirildi. 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 başlıklarıyla 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 (400 Hatalı İstek) hatasıyla yanıt verir.

Desteklenen şifreler

Kuzey yönlü 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üncellemeyle birlikte, kuzeye giden istekler için hem tek yönlü hem de çift yönlü TLS bağlantılarında bu tür anahtarlara artık izin verilmeyecek.

Ek

Üstbilgilerdeki boşluklar

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

  1. Daha önce izin verilen belirli üstbilgi adlarına artık Nginx 1.26 tarafından izin verilmiyor. Bu başlıklara sahip 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 başlıklara sahip istekler de 400 Bad Request (Hatalı İstek) hatasına neden olur.
  3. Daha önce Nginx tarafından kabul edilen ancak Mesaj İşleyici'de 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şecektir.

Aşağıdaki bölümde, izin verilmeyen çeşitli üstbilgi adları ve üstbilgi değerleri örnekleri verilmiştir. Bunlar yalnızca örnek niteliğindedir ve olası her durumu içermeyebilir. Üstbilgiler için RFC 7230 yönergelerine uymanız önerilir.

Başlık adlarında 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 adları listelenmiştir.

Senaryo Üstbilgi adı örnekleri
Başlık adının başında, sonunda veya ortasında kontrol karakteri { '\u0001'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ Header'\u0005'4, Value4 }
Üstbilgi adının başında ve sonunda boşluk {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
Üstbilgi adının başında ve sonunda HTAB var {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
Üstbilgi adının başında ve sonunda HTAB, WS 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 geliyorsa araya NewLine (\n) eklenir. {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
Başlık adının hemen ardından HTAB veya bir dizi HTAB ile ayrılmış NewLine (\n) {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
Üstbilgi adından hemen sonra satır başı karakteri (\r) ve yeni satır (\n) karakteri, ardından HTAB veya bir dizi HTAB {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
Üstbilgi adının hemen ardından gelen satır başı karakteri (\r) yeni satır (\n) ve ardından gelen boşluk veya bir dizi boşluk {"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 \r\n ile WS ya da 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"}
\n veya HEADERVALUE arasında \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 üstbilgiler doğrudan Nginx'te hatalara neden olarak isteğin mesaj işleyiciye yönlendirilmesini 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şleyici yerine Nginx tarafından oluşturulacağı için 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ö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"}