Perubahan Nginx 1.30 di Apigee Edge 4.54.00

Ringkasan perubahan Nginx

Apigee Edge untuk Private Cloud 4.54.00 mencakup upgrade wajib ke Nginx versi 1.30 di Edge Router.

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 terhadap 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 northbound dapat berubah dengan rilis ini. Anda dapat memeriksa cipher yang didukung oleh OpenSSL di host router untuk mendapatkan daftar cipher yang tersedia dan terbaru.

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 update 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 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 downstream di Message Processor 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 segera diikuti oleh WS atau serangkaian WS {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
NewLine (\n) di antara nama header yang segera 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 segera diikuti 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 segera diikuti oleh WS atau serangkaian WS {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

Perubahan nilai header

Bagian ini menunjukkan 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 yang 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 yang 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 dalam respons kegagalan HTTP

Bagian ini membahas header yang diizinkan oleh Nginx lama tetapi ditolak oleh Message Processor upstream, sehingga menghasilkan kode status 400. Namun, di Nginx 1.26, header tersebut menyebabkan kegagalan langsung di Nginx, sehingga mencegah permintaan diteruskan ke Message Processor.

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 Message Processor.

Skenario Contoh
HTAB atau WS di antara HEADERNAME

Message Processor 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"}