프록시와 Starlette가 같은 요청을 다르게 읽을 때 — 경계면에서 갈라지는 한 건의 HTTP

이미지 출처: CISA KEV

사내 API 게이트웨이 로그를 보다가 이상한 걸 발견하는 순간이 있음. 프록시 액세스 로그에는 요청이 한 건인데, 뒤에 있는 애플리케이션 로그에는 두 건이 찍혀 있는 경우 말입니다. 이게 바로 HTTP 요청 스머글링이 남기는 가장 전형적인 흔적이고, 이번에 Starlette에 붙은 CVE-2026-48710도 정확히 이 계열의 문제임.

핵심 요약

• Kludex/Starlette에서 HTTP 요청·응답 스머글링(Request/Response Smuggling) 취약점이 보고됨 — 프록시와 앱이 같은 바이트 스트림을 다르게 해석하는 경계면 불일치 문제.
• 실질 위험은 인증·WAF·라우팅 우회, 캐시 오염, 다른 사용자 응답 탈취까지 이어질 수 있다는 점.
• 대응은 세 겹 — Starlette·ASGI 서버 최신화, 프록시 단에서 모호한 요청 차단, 그리고 "프록시 로그 대 앱 로그" 건수 대조 탐지.

1. Starlette가 어디에 서 있는 물건인지부터

Starlette는 파이썬 ASGI 기반의 경량 웹 프레임워크임. 그 자체로 쓰이기도 하지만, 진짜 무서운 건 FastAPI가 Starlette 위에 얹혀 있다는 사실임. 요즘 사내에 돌아다니는 AI 추론 API, 내부 백오피스, 마이크로서비스 게이트웨이 상당수가 FastAPI로 짜여 있다보니, Starlette 하나에 구멍이 나면 조직도상 전혀 다른 팀들이 동시에 영향권에 들어감. 자산 목록에 "Starlette"라고 적혀 있는 서버가 없더라도 안심할 수 없는 이유가 이것.

2. 요청 스머글링, 개념만 짚고 넘어감

HTTP는 "요청이 어디서 끝나는가"를 두 가지 방식으로 알림. 하나는 Content-Length, 다른 하나는 Transfer-Encoding: chunked임. 문제는 이 둘이 동시에 들어오거나, 헤더 값이 애매하게 쓰였을 때 발생함. 앞단 프록시는 A 기준으로 요청 경계를 자르고, 뒷단 애플리케이션은 B 기준으로 자름. 그러면 프록시가 "요청 하나"라고 믿고 넘긴 바이트 뭉치의 뒷부분이, 앱 입장에서는 다음 요청의 앞머리가 되어버림.

• 그렇게 밀어넣은 조각은 프록시를 통과한 적이 없으니 WAF·인증 필터를 건너뜀.
• 연결이 재사용되는 구간이라면, 그 조각이 다른 사용자의 요청 앞에 붙어 응답이 뒤섞임.
• 응답 쪽 경계가 어긋나는 경우(응답 스머글링)에는 A 사용자에게 갈 응답이 B 사용자 브라우저에 도착하는 상황도 성립함.

구체적인 페이로드 문법은 여기서 다루지 않음. 방어자 입장에서 필요한 건 "어떤 문자를 어디에 넣느냐"가 아니라, 내 구간에 해석이 갈라지는 지점이 존재하는가이기 때문임.

3. 왜 프레임워크 레벨 파싱이 중요한가

많은 팀이 "우리는 nginx 뒤에 있으니 괜찮다"고 생각함. 과연 그럴까? 스머글링은 단독 소프트웨어의 버그가 아니라 두 파서 사이의 의견 차이임. 즉 프록시가 아무리 엄격해도, 뒷단 프레임워크가 관대하면 그 관대함이 곧 틈이 됨. 반대로 프레임워크가 엄격해도 앞단이 헐거우면 마찬가지고. 그래서 Starlette 같은 프레임워크·ASGI 서버(uvicorn, hypercorn 등)의 헤더 파싱 규약이 얼마나 RFC에 붙어 있느냐가 실제 보안 경계를 결정함.

4. 지금 당장 해볼 점검 순서

• 자산 식별: requirements.txt·poetry.lock·pip freeze를 전수 조사해 starlette, fastapi, uvicorn 버전을 뽑음. 컨테이너 이미지 안쪽까지 봐야 함. 자산 인벤토리에서 빠지는 건 대개 "누가 급하게 띄운 내부용" 서비스임.
• 버전 최신화: Starlette 및 함께 쓰는 ASGI 서버를 패치 반영된 최신 버전으로 올림. FastAPI를 쓴다면 FastAPI만 올리는 게 아니라 하위 의존성인 Starlette가 실제로 올라갔는지 확인해야 함.
• 경계면 축소: 프록시에서 Content-Length와 Transfer-Encoding이 동시에 존재하는 요청, 중복 헤더, 비정상 chunked 인코딩을 정규화하지 말고 그냥 거절하도록 설정. "고쳐서 전달"이 스머글링의 최고 조력자임.
• 연결 정책 조정: 프록시와 백엔드 사이 구간을 HTTP/2로 정리하거나, 리스크가 큰 구간은 keep-alive 재사용을 제한. 백엔드 연결이 공유되지 않으면 피해가 요청 하나에서 멈춤.

5. 탐지 — 로그 두 벌을 나란히 놓는 것부터

개인적으로는 패턴 시그니처보다 건수 대조를 먼저 추천함. 방법은 단순함.

• 같은 시간대에 프록시 액세스 로그의 요청 수와 애플리케이션 로그의 처리 요청 수를 비교. 앱 쪽이 꾸준히 더 많으면 그건 경계가 갈라지고 있다는 신호임.
• 앱 로그에는 있는데 프록시 로그에는 대응 항목이 없는 경로가 있는지 확인. 특히 /admin, /internal 같은 관리 경로가 프록시 기록 없이 등장하면 즉시 조사 대상임.
• 요청 ID를 프록시 단에서 발급해 헤더로 심고, 앱 로그에 그대로 남기도록 함. ID 없는 요청 = 프록시를 거치지 않은 요청.
• 동일 소스에서 400/408 같은 파싱 오류가 짧은 간격으로 반복되는 패턴도 좋은 조기 지표임. 스머글링은 성공 전에 항상 탐색 단계를 거침.

WAF 룰 하나 추가하는 것보다 이 요청 ID 파이프라인 하나 깔아두는 게 장기적으로 훨씬 값어치가 있는 것 같음. 이번 CVE뿐 아니라 앞으로 나올 같은 계열 이슈 전부를 같은 방식으로 볼 수 있게 되니까.

6. 마무리하며

스머글링 계열 취약점을 볼 때마다 드는 생각은, 결국 보안 사고 상당수가 소프트웨어 안이 아니라 소프트웨어와 소프트웨어 사이에서 터진다는 것임. 각각은 다 정상 동작인데, 이어붙이는 순간 해석이 갈라짐. 그래서 이런 건 패치만으로 끝내지 말고, 내 구간의 경계면 지도를 한 번 그려두는 게 좋다고 봄. 클라이언트 → CDN → 로드밸런서 → 프록시 → ASGI 서버 → 앱, 이 사슬에서 HTTP를 다시 파싱하는 지점이 몇 개인지 세어보는 것만으로도 감이 확 옴.

이번 주말에 각자 서비스 의존성 목록부터 한번 훑어보는 건 어떨까요. 혹시 사내에서 요청 ID 대조 탐지를 다르게 구현해서 재미를 본 사례가 있다면 댓글로 공유해 주세요. 차차 정리해서 다음 글에 반영해 보겠음. 같이 해보아요!