Apigee Edge 4.53.01의 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"}
{" 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"}
헤더 이름과 WS 또는 WS 시리즈 사이에 있는 NewLine (\n) {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
헤더 이름과 HTAB 또는 HTAB 시리즈 사이에 NewLine (\n)이 있습니다. {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
헤더 이름과 HTAB 또는 HTAB 시리즈 사이에 캐리지 리턴 (\r) NewLine (\n)이 있습니다. {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
헤더 이름과 WS 또는 WS 시리즈 사이에 캐리지 리턴 (\r) NewLine (\n)이 있습니다. {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

헤더 값 변경

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

시나리오 예
HEADERVALUE 사이에 \r\n 또는 \r\n과 WS 또는 HTAB의 조합이 허용됩니다. {"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"}