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

Обзор изменений 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 Bad Request .
  3. Некоторые заголовки, которые ранее принимались Nginx, но вызывали сбои в дальнейшем в обработчике сообщений, теперь отклоняются напрямую Nginx. Хотя эти заголовки по-прежнему приводят к сбоям API, сообщения об ошибках HTTP изменятся.

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

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

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

Сценарий Примеры названий заголовков
Управляющий символ в начале, конце или между именем заголовка. { '\u0001'Заголовок0, Значение0 }
{ Заголовок6'\u0002', Значение6 }
{ Заголовок'\u0005'4, Значение4 }
Ведущие и конечные пробелы в имени заголовка {"Заголовок2", "Значение2"}
{" Заголовок3", "Значение3"}
{"Заголовок4", "Значение4"}
Начальный и конечный HTAB в имени заголовка {"\tHeader11", "Value11"}
{"Заголовок12\t", "Значение12"}
{"\tHeader13\t", "Value13"}
Начальная и конечная комбинация HTAB и WS в имени заголовка. {"\t Заголовок24", "Значение24"}
{" \tHeader25", "Value25"}
{"Заголовок26\t", "Значение26"}
{"Заголовок27\t", "Значение27"}
NewLine (\n) между именем заголовка, за которым сразу следует WS или серия WS. {"Заголовок\n 57Mutiline", "Value57"}
{"Заголовок\n 58Mutiline", "Value58"}
Новая строка (\n) между именем заголовка, за которой сразу следует HTAB или серия HTAB. {"Заголовок\n\t73", "Значение73"}
{"Заголовок\n\t\t74", "Значение74"}
Возврат каретки (\r) Новая строка (\n) между именем заголовка, за которым сразу следует HTAB или серия HTAB. {"Заголовок\r\n\t69", "Значение69"}
{"Заголовок\r\n\t\t70", "Значение70"}
Возврат каретки (\r) Новая строка (\n) между именем заголовка, за которым сразу следует WS или серия WS {"Заголовок\r\n 71", "Значение71"}
{"Заголовок\r\n 72", "Значение72"}

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

В этом разделе показаны различные значения заголовков, которые были разрешены в 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"},
{"Заголовок65", "Значение\n\t65"},
{"Заголовок66", "Значение\n\t\t66"},
{"Заголовок67", "Значение\n 67"},
{"Заголовок68", "Значение\n 68"}

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

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

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

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

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

 {"Заголовок 5", "Значение5"},
{"Заголовок\t14", "Значение14"},
{"Заголовок\t 32", "Значение32"},
{"Заголовок \t33", "Значение33"},
{"Заголовок-36", "Значение36"},
{"Заголовок-\t40", "Значение40"},
{"Заголовок 4а", "Значение4а"},
{"Заголовок\t 59", "Значение59"},
{"Заголовок\t 60", "Значение60"}