Các thay đổi về Nginx 1.30 trong Apigee Edge 4.54.00

Tổng quan về các thay đổi đối với Nginx

Apigee Edge cho Private Cloud 4.54.00 bao gồm bản nâng cấp bắt buộc lên Nginx phiên bản 1.30 trên Bộ định tuyến Edge.

Với việc phát hành Nginx 1.26, một số thay đổi quan trọng đã được giới thiệu để tăng cường bảo mật và đảm bảo tuân thủ các tiêu chuẩn HTTP. Sau đây là các điểm cập nhật chính:

Xử lý khoảng trắng trong tên và giá trị tiêu đề

Để cải thiện tính bảo mật, việc tuân thủ RFC 7230 đã được tăng cường, đặc biệt là liên quan đến việc xử lý khoảng trắng trong tiêu đề. Bạn có thể xem thêm thông tin chi tiết về những thay đổi này trong Phụ lục.

Xử lý tiêu đề Content-Length và Transfer-Encoding

Một trong những kỹ thuật phổ biến được sử dụng trong các cuộc tấn công buôn lậu yêu cầu liên quan đến việc gửi các yêu cầu HTTP có cả tiêu đề Content-Length và Transfer-Encoding. Mặc dù Apigee Edge đã được củng cố để chống lại các cuộc tấn công như vậy, nhưng Nginx hiện chặn rõ ràng các yêu cầu chứa cả hai tiêu đề. Nếu một yêu cầu như vậy được gửi, Nginx sẽ phản hồi bằng lỗi 400 Yêu cầu không hợp lệ.

Mật mã được hỗ trợ

Danh sách mật mã được hỗ trợ cho các yêu cầu hướng bắc có thể thay đổi trong bản phát hành này. Bạn có thể kiểm tra các mật mã được OpenSSL hỗ trợ trên máy chủ bộ định tuyến để xem danh sách mật mã hiện có được cập nhật.

Kích thước khoá được hỗ trợ

Trước đây, theo mặc định, các khoá RSA, DSA và DH nhỏ hơn 2048 bit và các khoá ECC nhỏ hơn 224 bit đều được chấp nhận. Tuy nhiên, với bản cập nhật này, các khoá như vậy sẽ không còn được phép sử dụng cho cả kết nối TLS một chiều và hai chiều đối với các yêu cầu hướng bắc.

Phụ lục

Khoảng trắng trong tiêu đề

Có 3 thay đổi chính:

  1. Một số tên tiêu đề từng được phép hiện không được Nginx 1.26 cho phép. Các yêu cầu có các tiêu đề này sẽ dẫn đến lỗi 400 Yêu cầu không hợp lệ.
  2. Một số giá trị tiêu đề từng được phép hiện không được Nginx 1.26 cho phép. Các yêu cầu có các tiêu đề này cũng sẽ dẫn đến lỗi 400 Yêu cầu không hợp lệ.
  3. Một số tiêu đề từng được Nginx chấp nhận nhưng gây ra lỗi ở hạ nguồn trong bộ xử lý thông báo hiện bị Nginx từ chối trực tiếp. Mặc dù các tiêu đề này vẫn dẫn đến lỗi API, nhưng thông báo lỗi HTTP sẽ thay đổi.

Phần bên dưới cung cấp ví dụ về nhiều tên tiêu đề và giá trị tiêu đề không được phép. Đây chỉ là một vài ví dụ và có thể không phải là danh sách đầy đủ. Bạn nên tuân thủ các nguyên tắc của RFC 7230 đối với tiêu đề.

Thay đổi về tên tiêu đề

Phần này liệt kê nhiều tên tiêu đề từng được phép trong Nginx 1.20.1 nhưng hiện không được phép trong Nginx 1.26.

Trường hợp Ví dụ về tên tiêu đề
Ký tự điều khiển ở đầu, cuối hoặc ở giữa tên tiêu đề { '\u0001'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ Header'\u0005'4, Value4 }
Khoảng trắng ở đầu và cuối tên tiêu đề {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
HTAB ở đầu và cuối tên tiêu đề {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
Kết hợp HTAB, WS ở đầu và cuối tên tiêu đề {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
Dòng mới (\n) ở giữa tên tiêu đề, tiếp theo là WS hoặc một loạt WS {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
Dòng mới (\n) ở giữa tên tiêu đề, tiếp theo là HTAB hoặc một loạt HTAB {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
Ký tự trả lại vị trí đầu dòng (\r) Dòng mới (\n) ở giữa tên dòng tiêu đề, tiếp theo là HTAB hoặc một loạt HTAB {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
Ký tự trả lại vị trí đầu dòng (\r) Dòng mới (\n) ở giữa tên dòng tiêu đề, tiếp theo là WS hoặc một loạt WS {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

Thay đổi về giá trị tiêu đề

Phần này cho thấy nhiều giá trị tiêu đề từng được phép trong Nginx 1.20.1 nhưng không được phép trong Nginx 1.26.

Trường hợp Ví dụ
\r\n hoặc kết hợp \r\n với WS hoặc HTAB được phép ở giữa 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 hoặc kết hợp \n với WS hoặc HTAB được phép ở giữa 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"}

Thay đổi về phản hồi lỗi HTTP

Phần này đề cập đến các tiêu đề từng được Nginx cũ cho phép nhưng bị bộ xử lý thông báo ở luồng ngược dòng từ chối, dẫn đến mã trạng thái 400. Tuy nhiên, trong Nginx 1.26, các tiêu đề như vậy gây ra lỗi trực tiếp tại Nginx, ngăn yêu cầu được chuyển tiếp đến bộ xử lý thông báo.

Đối với những máy khách gửi các tiêu đề như vậy, mã trạng thái HTTP sẽ vẫn là 400. Tuy nhiên, nội dung phản hồi HTTP có thể thay đổi vì lỗi sẽ do Nginx tạo thay vì bộ xử lý thông báo.

Trường hợp Ví dụ
HTAB hoặc WS ở giữa HEADERNAME

Bộ xử lý thông báo từ chối các yêu cầu như vậy. Với Nginx 1.26, các yêu cầu này sẽ bị chính Nginx từ chối. Người dùng API sẽ nhận được phản hồi lỗi 400 kèm theo thông báo lỗi Nginx trong nội dung.

 {"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"}