Изменения в Nginx 1.26 в Apigee Edge 4.53.01

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

В версии 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-подключений для запросов к серверу.

Приложение

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

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

  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"}
В начале и конце названия заголовка есть символ табуляции {"\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) или серией символов табуляции. {"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"}