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

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

Với bản phát hành Nginx 1.26, một số thay đổi quan trọng đã được đưa ra để 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 nội dung cập nhật quan trọng:

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

Để tăng cường tính bảo mật, chúng tôi tăng cường tuân thủ RFC 7230, đặc biệt là liên quan đến việc xử lý khoảng trắng trong các 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 tuỳ chỉnh yêu cầu là gửi 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 giờ đây, Nginx sẽ chặn rõ ràng các yêu cầu chứa cả hai tiêu đề. Nếu bạn gửi yêu cầu như vậy, Nginx sẽ phản hồi bằng lỗi 400 Yêu cầu không hợp lệ.

Thuật toán mật mã được hỗ trợ

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

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

Trước đây, các khoá RSA, DSA và DH nhỏ hơn 2048 bit và khoá ECC nhỏ hơn 224 bit được chấp nhận theo mặc định. 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 cho cả kết nối TLS một chiều và hai chiều đối với các yêu cầu đi về 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 đề nhất định trước đây được cho phép, nhưng 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 Bad Request (Yêu cầu không hợp lệ).
  2. Một số giá trị tiêu đề nhất định trước đây được cho phép, nhưng hiện không được Nginx 1.26 cho phép. Những yêu cầu có những tiêu đề này cũng sẽ dẫn đến lỗi 400 Bad Request (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 trình xử lý thư giờ đã bị Nginx trực tiếp từ chối. Mặc dù những tiêu đề này vẫn gây ra lỗi API, nhưng các 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 về 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 tên tiêu đề {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
Dẫn đầu và HTAB ở cuối trong tên tiêu đề {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
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ấu xuống dòng (\n) nằm giữa tên tiêu đề, theo sau là WS hoặc một loạt WS {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
NewLine (\n) ở giữa tên tiêu đề, theo sau là HTAB hoặc một loạt HTAB {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
Dấu xuống dòng (\r) Dấu xuống dòng mới (\n) ở giữa tên tiêu đề, theo sau là HTAB hoặc một loạt HTAB {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
Dấu xuống dòng (\r) Dấu xuống dòng mới (\n) ở giữa tên tiêu đề, theo sau 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 hiển thị nhiều giá trị tiêu đề khác nhau đượ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 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 tổ hợp \n với WS hoặc HTAB được phép nằm giữa HEADERVALUE {"Header61", "Value\n 61Multiline"},
{"Header62", "Value\n 63Multiline"},
{"Header65", "Giá trị\n\t65"},
{"Header66", "Giá trị\n\t\t66"},
{"Header67", "Giá trị\n 67"},
{"Header68", "Giá trị\n 68"}

Thay đổi về 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 trình xử lý thông báo 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 không cho yêu cầu được chuyển tiếp đến bộ xử lý thư.

Đố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 phản hồi HTTP có thể thay đổi vì lỗi hiện sẽ do Nginx tạo ra thay vì trình xử lý thông báo.

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

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