Perubahan Nginx 1.26 di Apigee Edge 4.53.01

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 dalam 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 diperkuat untuk mencegah serangan semacam itu, Nginx kini secara eksplisit memblokir permintaan yang berisi kedua header tersebut. Jika permintaan tersebut dikirim, Nginx akan merespons dengan error 400 Bad Request.

Cipher yang didukung

Daftar cipher yang didukung untuk permintaan ke utara dapat berubah dengan rilis ini. Anda dapat memeriksa sandi yang didukung oleh OpenSSL di host router untuk mendapatkan daftar sandi yang tersedia yang telah diupdate.

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 lagi diizinkan untuk koneksi TLS satu arah dan dua arah untuk permintaan ke utara.

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 400 Bad Request.
  2. Nilai header tertentu yang sebelumnya diizinkan kini tidak diizinkan oleh Nginx 1.26. Permintaan dengan header ini juga akan menghasilkan error 400 Bad Request.
  3. Beberapa header yang sebelumnya diterima oleh Nginx, tetapi menyebabkan kegagalan di hilir dalam pemroses pesan, kini ditolak 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. Ini hanyalah contoh dan mungkin bukan daftar lengkap. Sebaiknya ikuti panduan RFC 7230 untuk header.

Perubahan nama header

Bagian ini mencantumkan berbagai nama header yang diizinkan di Nginx 1.20.1, tetapi kini tidak diizinkan di Nginx 1.26.

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

Perubahan nilai header

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

Skenario Contoh
\r\n atau kombinasi \r\n dengan WS atau HTAB diizinkan di antara HEADERVALUE {"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 mencakup header yang diizinkan oleh Nginx lama, tetapi ditolak oleh pemroses pesan upstream, sehingga menghasilkan kode status 400. Namun, di Nginx 1.26, header tersebut menyebabkan kegagalan 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

Prosesor Pesan menolak permintaan tersebut. Dengan Nginx 1.26, permintaan ini akan ditolak oleh Nginx itu sendiri. Konsumen API akan menerima respons error 400 dengan pesan error Nginx di 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"},
{"Header\t 60", "Value60"}