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에서 지원하는 암호화 알고리즘을 확인하여 사용 가능한 암호화 알고리즘의 업데이트된 목록을 가져올 수 있습니다.

지원되는 키 크기

이전에는 2,048비트 미만의 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"}
헤더 이름 사이에 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) NewLine (\n)이 있으며 그 뒤에 HTAB 또는 일련의 HTAB이 바로 이어짐 {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
헤더 이름 사이에 캐리지 리턴 (\r) NewLine (\n)이 있고 그 뒤에 WS 또는 일련의 WS가 바로 이어짐 {"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"}