부적절한 출력 처리

부적절한 출력 처리 (LLM05:2025) — 모델 출력이 아래 시스템까지 새는 경로

LLM이 만든 출력은 그 자체로 '다운스트림 컴포넌트로 전달되기 전에 검증·정화·처리'가 되어야 하는 데이터예요. 이런 처리가 부실하면 모델 출력이 브라우저에서는 XSS·CSRF로, 백엔드에서는 SSRF, 권한 상승, 원격 코드 실행(RCE)으로 이어질 수 있어요. LLM 생성 콘텐츠는 프롬프트 입력으로 조종될 수 있으니, 사실상 사용자에게 간접적인 추가 기능 접근을 주는 셈이죠. OWASP가 정리한 LLM05:2025 정의와 완화 전략을 강사 목소리로 풀어볼게요.

출처: OWASP GenAI Security Project — LLM05:2025 Improper Output Handling

어떤 상황에서 더 위험해지나요

부적절한 출력 처리가 무서운 이유는, 취약점 하나로 여러 계층이 동시에 뚫릴 수 있기 때문이에요. 위험을 키우는 조건이 몇 가지 있어요.

애플리케이션이 LLM에 최종 사용자보다 더 넓은 권한을 줘서, 권한 상승이나 원격 코드 실행이 가능한 경우.
간접 프롬프트 인젝션에 취약해서 공격자가 대상 사용자 환경에 상승된 접근을 얻을 수 있는 경우.
써드파티 확장이 입력을 제대로 검증하지 않는 경우.
HTML, JavaScript, SQL 등 문맥별 출력 인코딩이 없는 경우.
LLM 출력에 대한 모니터링과 로깅이 부족한 경우.
LLM 사용에 대한 비율 제한(rate limiting)이나 이상 탐지가 없는 경우.

실제로 어떤 타격이 생기나요

LLM 출력을 시스템 셸이나 exec, eval 같은 함수에 그대로 넣으면 원격 코드 실행이 돼요.
LLM이 만든 JavaScript나 Markdown을 브라우저가 해석하면 XSS가 발생해요.
파라미터화 없이 LLM 생성 SQL을 실행하면 SQL 인젝션이 돼요.
LLM 출력으로 파일 경로를 만들 때 정화가 없으면 경로 탐색(Path Traversal) 취약점이 생겨요.
이메일 템플릿에 LLM 콘텐츠를 이스케이프 없이 넣으면 피싱 공격으로 이어질 수 있어요.

완화 전략

모델을 그냥 '다른 사용자'로 취급 — 제로 트러스트 관점에서 모델 응답도 백엔드 함수로 들어가기 전에 입력 검증을 적용해요.
OWASP ASVS 가이드라인 준수 — 검증·정화·인코딩 규칙을 따르고, HTML 인코딩(웹), SQL 이스케이프(DB)처럼 문맥 인지 출력 인코딩을 적용해요.
파라미터화 쿼리 — LLM 출력이 들어가는 모든 DB 연산은 파라미터화 쿼리나 prepared statement를 사용해요.
엄격한 CSP — LLM 생성 콘텐츠로 인한 XSS 위험을 줄이기 위해 Content Security Policy(CSP)를 적용해요.
로깅과 모니터링 — LLM 출력의 이상 패턴을 감지해 착취 시도를 조기에 확인해요.

예시 공격 시나리오

챗봇용 LLM 확장이 관리 기능을 가진 다른 권한 높은 LLM에 응답을 그대로 넘기는데, 출력 검증이 없어 공격자가 확장을 유지보수 모드로 강제 종료시키는 경우.
웹사이트 요약 도구가, 페이지에 숨겨진 프롬프트 인젝션이 시키는 대로 민감 데이터를 공격자 서버로 내보내는 경우.
LLM이 SQL을 만들어주는 채팅형 기능에서, '모든 테이블 삭제' 쿼리를 검증 없이 실행해 데이터를 날리는 경우.
사용자 프롬프트로 LLM이 정화되지 않은 JavaScript 페이로드를 반환하게 만들어, 피해자 브라우저에서 XSS로 이어지는 경우.
코드 생성 도구가 존재하지 않는 소프트웨어 패키지를 환각으로 추천해, 개발자가 악성 패키지를 받아오게 만드는 경우 — 철저한 코드 리뷰와 패키지 검증이 필요해요.