Apigee Edge 4.53.00의 Nginx 1.26 변경사항

Nginx 1.26 변경사항 개요

Nginx 1.26 출시와 함께 보안을 강화하고 HTTP 표준을 준수하기 위한 몇 가지 중요한 변경사항이 도입되었습니다. 주요 업데이트는 다음과 같습니다.

헤더 이름 및 값의 공백 처리

보안을 개선하기 위해 특히 헤더의 공백 처리와 관련하여 RFC 7230 준수가 강화되었습니다. 이러한 변경사항에 대한 자세한 내용은 부록에서 확인할 수 있습니다.

Content-Length 및 Transfer-Encoding 헤더 처리

요청 스머글링 공격에 사용되는 일반적인 기법 중 하나는 Content-Length 및 Transfer-Encoding 헤더가 모두 포함된 HTTP 요청을 전송하는 것입니다. Apigee Edge는 이러한 공격에 대응하도록 이미 강화되었지만, 이제 Nginx는 두 헤더가 모두 포함된 요청을 명시적으로 차단합니다. 이러한 요청이 전송되면 Nginx는 400 Bad Request 오류로 응답합니다.

지원되는 암호화

노스바운드 요청에 지원되는 암호화 목록은 이번 출시에서 변경될 수 있습니다. 라우터 호스트에서 OpenSSL에서 지원하는 암호화를 확인하여 사용 가능한 암호화의 업데이트된 목록을 가져올 수 있습니다.

지원되는 키 크기

이전에는 2048비트 미만의 RSA, DSA, DH 키와 224비트 미만의 ECC 키가 기본적으로 허용되었습니다. 그러나 이번 업데이트로 인해 상위 요청의 단방향 및 양방향 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'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ Header'\u0005'4, Value4 }
선도 및 헤더 이름의 후행 공백 {"Header2 ", "Value2"}
{" 헤더3", "Value3"}
{" 헤더4 ", "Value4"}
선도 및 헤더 이름 후행 HTAB {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
헤더 이름에서 HTAB, WS의 선행 및 후행 조합 {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
헤더 이름 사이에 NewLine(\n)이 있고 그 뒤에 WS 또는 일련의 WS가 바로 이어짐 {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
헤더 이름 사이에 NewLine(\n)이 있고 그 뒤에 HTAB 또는 일련의 HTAB이 바로 이어짐 {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
헤더 이름 사이의 캐리지 리턴(R) 줄바꿈 (\n) 다음에 HTAB 또는 일련의 HTAB이 오는 경우 {"헤더\r\n\t69", "Value69"}
{"헤더\r\n\t70", "Value70"}
헤더 이름 사이에 캐리지 리턴(\r) NewLine(\n)이 있고 그 뒤에 WS 또는 일련의 WS가 바로 이어짐 {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

헤더 값 변경사항

이 섹션에서는 Nginx 1.20.1에서는 허용되지만 Nginx 1.26에서는 허용되지 않는 다양한 헤더 값을 보여줍니다.

시나리오 예
\r\n 또는 HEADERVALUE 사이에서 WS 또는 HTAB과 함께 \r\n의 조합이 허용됩니다. {"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"}
HEADERVALUE 사이에 \n 또는 \n과 WS 또는 HTAB의 조합이 허용됨 {"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으로 유지됩니다. 하지만 이제 메시지 프로세서 대신 Nginx에서 실패가 생성되므로 HTTP 응답 본문이 변경될 수 있습니다.

시나리오 예
HEADERNAME 사이에 HTAB 또는 WS 사용

메시지 프로세서는 이러한 요청을 거부합니다. Nginx 1.26에서는 이러한 요청이 Nginx 자체에서 거부됩니다. API 소비자는 본문에 Nginx 오류 메시지가 포함된 400 오류 응답을 받습니다.

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