Изменения в Nginx 1.30 в Apigee Edge 4.54.00

Обзор изменений в Nginx

Apigee Edge для Private Cloud 4.54.00 включает обязательное обновление до Nginx версии 1.30 на маршрутизаторах Edge.

В Nginx 1.26 внесены важные изменения, которые повышают безопасность и обеспечивают соответствие стандартам HTTP. Вот основные изменения:

Обработка пробелов в названиях и значениях заголовков

Чтобы повысить безопасность, мы усилили соблюдение RFC 7230, особенно в отношении обработки пробелов в заголовках. Подробную информацию об этих изменениях можно найти в Приложении.

Обработка заголовков Content-Length и Transfer-Encoding

Один из распространенных методов, используемых в атаках с контрабандой запросов, включает отправку HTTP-запросов с заголовками Content-Length и Transfer-Encoding. Хотя Apigee Edge уже был защищен от таких атак, теперь Nginx явно блокирует запросы, содержащие оба заголовка. Если такой запрос будет отправлен, Nginx ответит ошибкой 400 Bad Request.

Поддерживаемые шифры

В этом выпуске может измениться список поддерживаемых шифров для исходящих запросов. Чтобы получить обновленный список доступных шифров, проверьте шифры, поддерживаемые OpenSSL на хосте маршрутизатора.

Поддерживаемые размеры ключей

Ранее по умолчанию принимались ключи RSA, DSA и DH размером менее 2048 бит, а также ключи ECC размером менее 224 бит. Однако после этого обновления такие ключи больше не будут разрешены как для односторонних, так и для двусторонних TLS-подключений для запросов northbound.

Приложение

Пробелы в заголовках

Основные изменения:

  1. Некоторые названия заголовков, которые ранее были разрешены, теперь запрещены в Nginx 1.26. Запросы с такими заголовками будут приводить к ошибке 400 Bad Request.
  2. Некоторые значения заголовков, которые ранее были разрешены, теперь запрещены в Nginx 1.26. Запросы с этими заголовками также будут приводить к ошибке 400 "Недопустимый запрос".
  3. Некоторые заголовки, которые ранее принимались Nginx, но вызывали сбои в обработчике сообщений, теперь отклоняются непосредственно Nginx. Хотя эти заголовки по-прежнему приводят к сбоям API, сообщения об ошибках HTTP изменятся.

Ниже приведены примеры недопустимых названий и значений заголовков. Рекомендации ниже приведены в качестве примера и не являются исчерпывающими. Рекомендуем придерживаться правил RFC 7230 для заголовков.

Изменения в названиях заголовков

В этом разделе перечислены названия заголовков, которые были разрешены в Nginx 1.20.1, но запрещены в Nginx 1.26.

Сценарий Примеры названий заголовков
Управляющий символ в начале, конце или середине названия заголовка. { '\u0001'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ Header'\u0005'4, Value4 }
Пробелы в начале и конце названия заголовка {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
Начальный и конечный символы HTAB в названии заголовка {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
Сочетание символов HTAB и WS в начале и конце названия заголовка {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
Символ новой строки (\n) между названием заголовка и одним или несколькими символами пробела (WS). {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
Символ новой строки (\n) между названием заголовка и символом HTAB или серией символов HTAB. {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
Символ возврата каретки (\r) и символ новой строки (\n) между названием заголовка и символом горизонтальной табуляции (HTAB) или серией таких символов. {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
Символ возврата каретки (\r) и символ новой строки (\n) между названием заголовка и пробелом или серией пробелов. {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

Изменения в значениях заголовков

В этом разделе показаны различные значения заголовков, которые были разрешены в Nginx 1.20.1, но запрещены в Nginx 1.26.

Сценарий Примеры
\r\n или сочетание \r\n с WS или HTAB, разрешенное между 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 или сочетание \n с WS или HTAB, разрешенное между 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"}

Изменение ответа об ошибке HTTP

В этом разделе рассматриваются заголовки, которые были разрешены старым Nginx, но отклонены вышестоящим обработчиком сообщений, что привело к коду статуса 400. Однако в Nginx 1.26 такие заголовки вызывают сбои непосредственно в Nginx, что препятствует пересылке запроса обработчику сообщений.

Для клиентов, которые отправляют такие заголовки, код статуса HTTP останется 400. Однако тело HTTP-ответа может измениться, поскольку теперь сбой будет генерироваться Nginx, а не обработчиком сообщений.

Сценарий Примеры
HTAB или WS между HEADERNAME

Процессор сообщений отклоняет такие запросы. В Nginx 1.26 такие запросы будут отклоняться самим Nginx. Пользователь API получит ответ с ошибкой 400 и сообщением об ошибке Nginx в теле.

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