Starlette의 BadHost 인증 우회로 인한 AI Agent 노출 위험

Originally published on CoreProse KB-incidents

Starlette 앱이 인증(authentication) 또는 테넌트 라우팅(tenant routing)을 위해 Host 헤더를 신뢰할 때, 기본적인 웹 버그는 에이전트 제어 평면(agentic control-plane) 취약점으로 변질됩니다. 만약 해당 서비스가 도구 접근 권한을 가진 AI 에이전트(AI agents)의 전면에 있다면, BadHost는 자율적인 코드 실행(autonomous code execution), 데이터 유출(data exfiltration), 그리고 대규모 프롬프트 주입(prompt injection)에 대한 원격 제어 권한을 부여할 수 있습니다.[5][6]

💡 핵심 요약: Starlette에서의 Host 처리를 단순한 미적 라우팅 세부 사항이 아닌, AI 에이전트(AI agents)를 위한 보안 경계(security boundary)로 취급하십시오.[6]

1. 위협 모델: Starlette의 BadHost에서 AI 에이전트의 완전한 침해까지

“BadHost”란 신뢰할 수 없는 Host 또는 X-Forwarded-Host 헤더로부터 인증, 테넌트 선택, 또는 콜백 URL(callback URLs)을 도출하는 모든 Starlette 로직을 의미합니다.[5][6] DNS 또는 헤더 스푸핑(spoofing)을 통해 공격자는 다음과 같은 행위를 할 수 있습니다:

• 테넌트 사칭 (Impersonate tenants)
• 액세스 체크 우회 (Bypass access checks)
• 공격자가 제어하는 인프라를 통해 트래픽 라우팅 (Route traffic through attacker‑controlled infrastructure)[5][6]

많은 배포 환경에서 하나의 Starlette 앱은 동시에 다음 역할을 수행합니다:

• 사용자 세션 종료 (Terminates user sessions)
• 테넌트별 에이전트 백엔드로 라우팅 (Routes to per‑tenant agent backends)
• 도구 또는 웹훅(webhooks)을 위한 콜백 URL 생성 (Builds callback URLs for tools or webhooks)

만약 이러한 결정들이 Host에 의존한다면, 단 한 번의 프록시 설정 오류(proxy misconfig)로 인해 다음과 같은 상황이 발생할 수 있습니다:

• 테넌트 격리 붕괴 (Collapse tenant isolation)
• 많은 테넌트의 에이전트 트래픽을 악성 도메인으로 리다이렉트 (Redirect many tenants’ agent traffic to a malicious domain)
• 하나의 침해된 엔트리포인트(entrypoint)로 공격 표면을 집중화 (Centralize attack surface on one compromised entrypoint)

트래픽이 해당 경로에 놓이게 되면 위험은 의미론적(semantic) 단계로 넘어갑니다. 프롬프트 주입(Prompt injection)은 이미 시스템 프롬프트를 무시하거나 민감한 컨텍스트를 유출하는 데 일상적으로 사용되고 있습니다.[1][2] BadHost와 결합될 경우, 공격자는 전송 중인 프롬프트를 주입하거나 수정하여 다음과 같은 행위를 할 수 있습니다:

• 안전 지침 제거 또는 약화 (Strip or weaken safety instructions)
• 승인되지 않은 도구 호출 트리거 (Trigger unauthorized tool calls)
• 검색된 문서 또는 내부 로그 유출 (Exfiltrate retrieved documents or internal logs)[1][2]

📊 데이터 포인트 (Data point): 기업 연구에 따르면 2025년까지 프롬프트 인젝션 (Prompt injection)이 AI 취약점 중 가장 흔하게 악용되는 요소로 식별되었습니다.[2]

OpenClaw 사고는 취약한 세션 및 채널 격리가 공개 채팅 앱으로부터 사용자 세션 및 권한이 있는 도구로의 측면 이동 (Lateral movement)을 어떻게 허용했는지 보여주었습니다.[3][10] BadHost는 이와 유사한 깔때기 효과를 만들 수 있습니다. 즉, 많은 테넌트 (Tenant)의 에이전트가 하나의 적대적인 도메인을 통해 집중되고, 공격자가 모든 대화에 명령을 주입하는 방식입니다.

에이전트형 AI (Agentic AI) 보안 조사에서는 단일 거점이 계획 및 도구 체인을 통해 확산되는 연쇄 실패 (Cascading failures), 메모리 오염 (Memory poisoning), 그리고 감독 회피 (Oversight evasion)를 강조합니다.[6][8] BadHost는 바로 그 거점입니다. 즉, 영향력이 큰 시맨틱 공격 (Semantic attacks)을 가능하게 하는 저렴한 네트워크 버그입니다.[6][8]

⚠️ 핵심 사항 (Key point): 만약 공격자가 Host 헤더에 영향을 미칠 수 있다면, 공격자가 테넌트를 사칭하고 경계가 지정된 모든 에이전트 세션에 대해 프롬프트 인젝션 (Prompt injection)을 시도할 수 있다고 가정해야 합니다.[1][5]

2. 보안 아키텍처: BadHost에 대응하는 Starlette 및 에이전트 라우팅 강화

더 안전한 기본 설정:

• 공용 에지 (Public edge)에서 Nginx 또는 Envoy를 사용하여 Starlette 앞단에 배치합니다.
• 프록시에서 TLS를 종료(Terminate)하고, Starlette은 프라이빗하게 유지합니다.
• Host를 표준 내부 이름으로 재작성(Rewrite)하고, X-Forwarded-Host를 제거합니다.
• 인증 및 테넌트 ID는 JWT 또는 mTLS ID를 통해 구동하며, 도메인 이름으로부터 절대 가져오지 않습니다.[6][10]

Starlette에서 명시적인 Host 검증을 추가합니다:

ALLOWED_HOSTS = {"agents.internal", "agents.prod.svc"}

class HostValidationMiddleware:
...

주변 권한 (Ambient authority)을 제거하기 위해 에이전트 세션 컨텍스트를 Host가 아닌 암호학적으로 검증 가능한 ID (JWT subject, SPIFFE ID)에 바인딩합니다.[10]

💼 운영 팁 (Operational tip): 정규화된 Host 값과 원래의 Host 값을 모두 로그로 남기고, 불일치가 발생하면 경고를 보냅니다.[10]

Starlette과 대규모 언어 모델 (Large language models) 사이에 가드레일 계층 (LLM Guard, NeMo Guardrails)을 삽입하여 프롬프트와 응답에서 프롬프트 인젝션 (Prompt injection), 비밀 정보, 그리고 안전하지 않은 도구를 스캔합니다.[2][4] 운영 환경 보고에 따르면 요청당 약 50ms의 오버헤드가 발생합니다.[4]

최악의 경우 발생할 수 있는 침해를 방지하려면 Parallax 방식의 인지-실행 분리 (cognitive-executive separation)를 사용하십시오:

• LLM: 구조화된 행동 계획 (action plans)만 출력합니다.
• Executor (실행기): 네트워크/파일 시스템 작업이 수행되기 전에 정책을 강제합니다.[7]

평가 결과에 따르면, 추론 과정이 완전히 침해된 상황에서도 이러한 방식은 적대적 실행 (adversarial executions)의 약 98.9%를 차단할 수 있습니다.[7]

Executor (실행기)의 검사 항목에는 다음이 포함되어야 합니다:

• 허용된 도메인/IP 범위
• 테넌트별(per-tenant), 도구별(per-tool) 속도 제한 (rate limits)
• 데이터 민감도 레이블 및 흐름 제어 (flow controls)[6][7]

📊 데이터 포인트: 177,436개의 MCP 도구를 분석한 결과, 행동 도구 (action tools)의 사용 비중이 27%에서 65%로 증가했으며, 이는 종종 결제 및 파일 편집을 처리하는 것으로 나타났습니다.[9] Starlette 라우팅은 도구별 및 테넌트별 스코프 (scopes)를 강제하여, 하나의 BadHost 취약점 공격이 여러 테넌트에 걸쳐 높은 위험도를 가진 도구들을 제어할 수 없도록 해야 합니다.[6][9]

⚠️ 핵심 사항: 에이전트의 모든 턴 (turn)이 침해될 수 있다고 가정하십시오. 부작용 (side effects)에 대한 최종 결정권자는 LLM이 아닌 Executor (실행기)여야 합니다.[7][10]

3. 테스트, 모니터링 및 운영 (Production Operations)

Starlette 에지 (edge)가 뚫릴 수 있다고 가정하십시오. Parallax는 가정된 침해 평가 (Assume-Compromise Evaluation)를 도입합니다. 이는 모델 수준의 안전 장치를 우회하여 Executor (실행기) 경계를 공격하는 테스트입니다.[7] BadHost에 대해 다음과 같은 레드팀 (red-teaming) 활동을 적용하십시오:

• 위조된 Host 헤더 및 DNS
• 도구 및 데이터 흐름을 겨냥한 적대적 프롬프트 (adversarial prompts)와의 결합[1][7]

실제 파이프라인에서는 이미 LLM을 사용하여 정찰 (reconnaissance)을 자동화하고 설정 오류를 악용하고 있으며, 큐레이션된 제로데이 (one-day) 취약점의 약 87%를 자율적으로 악용하고 있습니다.[5] 에이전트 앞에 위치한 Starlette BadHost 버그는 확장 가능하며 가치가 높은 공격 대상입니다.[5][8]

관측성 (observability) 계층은 다음을 기록해야 합니다:

• 사용자 신원 및 테넌트 ID
• 원본 Host 대 정규화된 (normalized) Host
• 도구 호출 (tool calls), 파라미터 및 결과
• LLM 추론 흔적 (reasoning traces) 또는 요약[3][10]

이는 환각 (hallucinated)된 에이전트의 자가 보고와 실제 행동을 분리하고, 세션 간 유출 (cross-session leaks)을 재구성하는 데 도움을 주어 자율 에이전트의 감사 공백 (auditing gap)을 해결합니다.[3][10]

💡 핵심 요약 (Key takeaway): 자유 형식의 "에이전트 보고서 (agent reports)"보다는 결정론적이고 구조화된 로그 (structured logs)를 선호하십시오. 에이전트를 신뢰할 수 없는 화자 (unreliable narrator)로 취급해야 합니다.[3][10]

지속적인 보안 평가 (Continuous security evaluation)는 다음 항목에 대해 에이전트 전용 테스트 스위트 (agent-specific suites)를 실행해야 합니다:

• 프롬프트 인젝션 (Prompt injection)
• 메모리 포이즈닝 (Memory poisoning)
• 승인되지 않은 도구 시퀀스 (Unauthorized tool sequences)[4][6]

사전 제작 (pre-prod) 및 회귀 테스트 파이프라인 (regression pipelines)에서 의미론적 가드레일 (semantic guardrail) 테스트와 함께 BadHost 방식의 라우팅 체크를 포함하십시오.[4][6]

한 스타트업의 스테이징 (staging) 사고 사례에 따르면, Host를 tenant-a.ai에서 tenant-b.ai로 변경했을 때 에이전트의 데이터 저장소 (data store)가 조용히 전환되는 현상이 나타났습니다. Host 값에 프롬프트 인젝션 (prompt-injection) 페이로드를 결합하여 퍼징 (fuzzing)을 수행한 레드팀 (Red-team) 테스트 결과, 불과 몇 분 만에 테넌트 간 (cross-tenant) 도구 실행이 노출되었습니다.[1][6]

⚡ 실행 지침 (Practice): 모든 주요 릴리스 전에 CI 보안 테스트에 Host 퍼징 (fuzzing)과 적대적 프롬프트 (adversarial prompts)를 추가하십시오.[1][6]

결론: BadHost를 에이전트 제어 평면 (Agentic Control-Plane) 버그로 취급하십시오

Starlette의 BadHost 문제는 단순한 웹 설정 오류가 아닙니다. 이는 프롬프트 인젝션 (prompt injection), 테넌트 간 라우팅 (cross-tenant routing), 그리고 실행기 남용 (executor abuse)을 통해 자율 도구를 하이재킹할 수 있는 진입점입니다.[1][5][6] 방어를 위해서는 다음이 필요합니다:

• 엄격한 Host 정규화 (normalization) 및 강화된 리버스 프록시 (reverse proxies)
• Host 기반의 주변 권한 (ambient authority)이 없는 ID 인식 인가 (Identity-aware authorization)
• 실행기 (executor)가 모든 도구 호출과 데이터 흐름에 대해 정책을 강제하는 Parallax 스타일의 인지-실행 분리 (cognitive-executive separation)[7][10]

CoreProse 소개: 검증된 인용을 포함한 연구 중심의 AI 콘텐츠 생성 서비스입니다. 환각 (hallucinations)이 전혀 없습니다.

🔗 CoreProse 체험하기 | 📚 더 많은 KB 사고 사례 보기