Perubahan Nginx 1.26 di Apigee Edge 4.53.00

Ringkasan perubahan Nginx 1.26

Dengan rilis Nginx 1.26, beberapa perubahan penting telah diperkenalkan untuk meningkatkan keamanan dan memastikan kepatuhan terhadap standar HTTP. Berikut adalah pembaruan utamanya:

Penanganan spasi kosong pada nama dan nilai header

Untuk meningkatkan keamanan, kepatuhan terhadap RFC 7230 telah diperkuat, terutama terkait penanganan spasi kosong di header. Detail selengkapnya tentang perubahan ini dapat ditemukan di Lampiran.

Penanganan header Content-Length dan Transfer-Encoding

Salah satu teknik umum yang digunakan dalam serangan penyelundupan permintaan melibatkan pengiriman permintaan HTTP dengan header Content-Length dan Transfer-Encoding. Meskipun Apigee Edge sudah dipertahankan terhadap serangan tersebut, Nginx kini secara eksplisit memblokir permintaan yang berisi kedua header. Jika permintaan semacam itu dikirim, Nginx akan merespons dengan pesan error 400 Bad Request.

Cipher yang didukung

Daftar penyandian yang didukung untuk permintaan menuju utara dapat berubah dengan rilis ini. Anda dapat memeriksa cipher yang didukung oleh OpenSSL di host router untuk mendapatkan daftar terbaru cipher yang tersedia.

Ukuran kunci yang didukung

Sebelumnya, kunci RSA, DSA, dan DH yang lebih kecil dari 2048 bit, serta kunci ECC yang lebih kecil dari 224 bit, diterima secara default. Namun, dengan pembaruan ini, kunci tersebut tidak akan lagi diizinkan untuk koneksi TLS satu arah dan dua arah untuk permintaan northbound.

Lampiran

Spasi kosong di header

Ada tiga perubahan utama:

  1. Nama header tertentu yang sebelumnya diizinkan kini tidak diizinkan oleh Nginx 1.26. Permintaan dengan header ini akan menghasilkan error Permintaan Buruk 400.
  2. Nilai header tertentu yang sebelumnya diizinkan kini tidak diizinkan oleh Nginx 1.26. Permintaan dengan header ini juga akan menghasilkan error 400 Permintaan Tidak Valid.
  3. Beberapa header yang sebelumnya diterima oleh Nginx, tetapi menyebabkan kegagalan di downstream dalam prosesor pesan, kini ditolak secara langsung oleh Nginx. Meskipun header ini masih menyebabkan kegagalan API, pesan kegagalan HTTP akan berubah.

Bagian di bawah ini memberikan contoh berbagai nama header dan nilai header yang tidak diizinkan. Daftar ini hanyalah contoh dan mungkin tidak lengkap. Sebaiknya patuhi pedoman RFC 7230 untuk header.

Perubahan pada nama header

Bagian ini mencantumkan berbagai nama header yang diizinkan dalam Nginx 1.20.1 tetapi sekarang tidak diizinkan di Nginx 1.26.

Skenario Contoh nama {i>header<i}
Karakter kontrol di awal, akhir, atau di antara nama header { '\u0001'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ Header'\u0005'4, Value4 }
Spasi kosong di awal & di akhir nama header {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
HTAB di awal & akhir dalam nama header {&quot;\tHeader11&quot;, &quot;Value11&quot;}
{&quot;Header12\t&quot;, &quot;Value12&quot;}
{&quot;\tHeader13\t&quot;, &quot;Value13&quot;}
Memimpin & kombinasi akhir HTAB, WS di nama header {&quot;\t Header24&quot;, &quot;Value24&quot;}
{&quot; \tHeader25&quot;, &quot;Value25&quot;}
{&quot;Header26 \t&quot;, &quot;Value26&quot;}
{&quot;Header27\t &quot;, &quot;Value27&quot;}
NewLine (\n) di antara nama header yang segera diikuti dengan WS atau serangkaian WS {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
NewLine (\n) di antara nama header yang segera diikuti dengan HTAB atau serangkaian HTAB {&quot;Header\n\t73&quot;, &quot;Value73&quot;}
{&quot;Header\n\t\t74&quot;, &quot;Value74&quot;}
Kembali ke awal baris (\r) NewLine (\n) di antara nama header yang segera diikuti dengan HTAB atau serangkaian HTAB {"Header\\n\t69", "Value69"}
{"Header\t\n\t70", "Value70"}
Enter (\n) NewLine (\n) di antara nama header diikuti langsung oleh WS atau serangkaian WS {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

Perubahan pada nilai header

Bagian ini menampilkan berbagai nilai header yang diizinkan di Nginx 1.20.1, tetapi tidak diizinkan di Nginx 1.26.

Skenario Contoh
{9/} atau kombinasi \r\n dengan WS atau HTAB diizinkan di antara ditunjukkanVALUE {"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 atau kombinasi \n dengan WS atau HTAB diizinkan di antara 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"}

Perubahan pada respons kegagalan HTTP

Bagian ini membahas header yang diizinkan oleh Nginx lama, tetapi ditolak oleh pemroses pesan upstream, sehingga menghasilkan kode status 400. Namun, pada Nginx 1.26, header seperti itu menyebabkan kegagalan secara langsung di Nginx, sehingga mencegah permintaan diteruskan ke pemroses pesan.

Untuk klien yang mengirim header tersebut, kode status HTTP akan tetap 400. Namun, isi respons HTTP dapat berubah karena kegagalan kini akan dihasilkan oleh Nginx, bukan pemroses pesan.

Skenario Contoh
HTAB atau WS di antara HEADERNAME

Pemroses Pesan menolak permintaan tersebut. Dengan Nginx 1.26, permintaan ini akan ditolak oleh Nginx sendiri. Konsumen API akan menerima respons error 400 dengan pesan error Nginx di dalam isi.

 {"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"},
{&quot;Header\t 60&quot;, &quot;Value60&quot;}