Các thay đổi về Nginx 1.26 trong Apigee Edge 4.53.01

Tổng quan về các thay đổi trong Nginx 1.26

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à những nội dung 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, chúng tôi đã tăng cường việc tuân thủ RFC 7230, đặc biệt là về 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 dùng trong các cuộc tấn công giả mạo yêu cầu là gửi các yêu cầu HTTP có cả tiêu đề Content-Length và Transfer-Encoding. Mặc dù Apigee Edge đã được tăng cường khả năng chống lại các cuộc tấn công như vậy, nhưng giờ đây, Nginx sẽ chặn rõ ràng các yêu cầu chứa cả hai tiêu đề. Nếu 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ệ.

Các mật mã được hỗ trợ

Danh sách các mật mã được hỗ trợ cho các yêu cầu theo 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ã mà OpenSSL hỗ trợ trên máy chủ lưu trữ bộ định tuyến để xem danh sách mật mã hiện có mới 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, cũng như 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 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 theo 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ó những tiêu đề này sẽ dẫn đến lỗi 400 Yêu cầu không hợp lệ.
  2. Nginx 1.26 hiện không cho phép một số giá trị tiêu đề mà trước đây được phép. Các yêu cầu có những 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 đề mà trước đây Nginx chấp nhận nhưng gây ra lỗi ở hạ nguồn trong trình 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 dưới đây 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ể chưa 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 tên tiêu đề

Phần này liệt kê nhiều tên tiêu đề đượ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 trong tên tiêu đề {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
HTAB đầu và cuối trong tên tiêu đề {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
Tổ hợp HTAB, WS ở đầu và cuối trong tên tiêu đề {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
NewLine (\n) ở giữa tên tiêu đề, ngay sau đó là WS hoặc một chuỗi WS {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
NewLine (\n) ở giữa tên tiêu đề, theo sau ngay lập tức là HTAB hoặc một chuỗi HTAB {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
Ký tự trả về đầu dòng (\r) Ký tự xuống dòng (\n) ở giữa tên tiêu đề, theo sau ngay lập tức là HTAB hoặc một chuỗi HTAB {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
Ký tự trả về đầu dòng (\r) Ký tự xuống dòng (\n) ở giữa tên tiêu đề, theo ngay sau đó là WS hoặc một chuỗi 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 đề được cho 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 nằm 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 trong phản hồi lỗi HTTP

Phần này đề cập đến các tiêu đề mà Nginx cũ cho phép nhưng bộ xử lý thông báo nguồn đã 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 sẽ gây ra lỗi ngay tại Nginx, ngăn yêu cầu được chuyển tiếp đến trình xử lý thông báo.

Đối với những ứng dụng 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 của thông báo phản hồi HTTP có thể thay đổi vì lỗi hiện 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

Trình xử lý tin nhắn sẽ từ chối những yêu cầu như vậy. Với Nginx 1.26, những 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 phần 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"}