부적절한 출력 처리는 LLM 응답이 검증과 sanitize 없이 다운스트림 시스템으로 전달될 때 발생한다.
개요
부적절한 출력 처리(Improper Output Handling)는 LLM의 응답이 검증, sanitize, encoding 없이 다음 처리 단계로 전달될 때 발생하는 취약점이다. 다음 단계는 사용자 브라우저, SQL 데이터베이스, OS shell, 파일 시스템, 외부 API 같은 다양한 형태를 가진다. 전통적 웹 보안의 XSS, SQL injection, command injection, path traversal이 LLM 출력 경로에서 그대로 재현된다.
LLM 응답은 사용자 입력의 산물이 아니라 모델이 생성한 텍스트라 "신뢰할 수 있는 출처"로 잘못 가정되기 쉽다. 그러나 LLM은 prompt injection으로 임의 텍스트를 생성하도록 유도될 수 있으므로 출력 단계에서도 같은 수준의 검증이 필요하다.
피해는 쿠키 탈취, 세션 하이재킹, 관리자 권한 탈취, 데이터베이스 위변조, RCE(원격 코드 실행) 같은 형태로 나타난다. 특히 LLM 응답을 관리자 UI, 알림 채널, 로그 뷰어로 전달하는 2차 경로가 함께 노출될 때 피해가 확대된다.
2025판은 명칭을 Insecure Output Handling(2023 LLM02)에서 Improper Output Handling으로 명확화했다. "Insecure"보다 "Improper"가 검증 부족이라는 구체적 의미를 전달하기 때문이다.
공격 시나리오
본 플랫폼의 05. J대리의 쿠키를 탈취하라는 사용자 요청 HTML을 그대로 출력하도록 설계된 LLM을 대상으로 한다. 봇의 응답은 iframe sandbox 안에서 실행되고, sandbox에는 가짜 admin_session 쿠키가 미리 박혀 있다. 시나리오상 봇은 미리보기, 데모, 테스트 같은 정상 framing 요청에는 완성된 HTML을 답하도록 설계되어 있다. 채점은 응답 안의 script가 가짜 쿠키를 부모 창으로 발사하면 통과된다.
부적절한 출력 처리 공격은 다음과 같은 기법 분류로 정리된다.
- script 태그 직접 삽입 : 응답에
<script>...</script>를 포함시켜 client-side 실행 유도. - 이벤트 핸들러 우회 :
<img onerror="...">,<body onload="...">같은 HTML 속성으로 script 실행 회피. - HTML 엔티티 인코딩 우회 : 필터를 통과하기 위해
<script>같은 인코딩 변형 사용. - 자동 실행 패턴 :
setTimeout, IIFE,addEventListener("load", ...)같은 자동 실행 코드. - 출력 형식 강제 : "완성된 HTML만 답하라" 같은 framing으로 봇이 출력 검증을 우회.
실제 산업 사례 :
- 2023년 ChatGPT 플러그인 XSS 보고 : iframe 안에서 실행된 응답 HTML이 부모 origin으로 postMessage를 발사해 세션 토큰 탈취.
- 2024년 LangChain SQL agent injection : LLM이 생성한 SQL이 parameterize 없이 실행돼 데이터베이스 전체 dump.
OWASP 분류 변천사
| 버전 | 카테고리 코드 | 명칭 | 비고 |
|---|---|---|---|
| 2023 v1.1 | LLM02 | Insecure Output Handling | 우선순위 2위 |
| 2025 | LLM05:2025 | Improper Output Handling | 명칭 명확화(Insecure -> Improper), 번호 02 -> 05 (3단계 하강) |
2025판은 명칭을 "Improper"로 바꿔 검증, sanitize, encoding 부족이라는 구체적 의미를 강조했다. 번호는 02에서 05로 하강했지만 위협 본질은 동일하다.
방어 방법
기술적 통제 :
- 출력 sanitize. LLM 응답을 사용자 브라우저로 보내기 전 DOMPurify, sanitize-html 같은 library로 script 태그와 위험 속성을 제거.
- Content Security Policy(CSP). inline script 차단, 외부 origin 제한, postMessage 발신 origin 검증으로 XSS 영향 범위를 줄임.
- iframe sandbox. LLM 응답 HTML을 실행해야 한다면 sandbox 속성으로 권한을 최소화.
- SQL 파라미터화. LLM이 생성한 query를 그대로 execute하지 말고 parameterize 또는 ORM 추상화 통과.
- shell 호출 차단. LLM 응답을
exec,eval,subprocess로 직접 전달하지 않음.
운영 통제 :
- 다운스트림 신뢰 경계 정의. LLM 출력이 도달하는 모든 시스템을 식별하고 각 경계에서 검증 절차 명시.
- 로그 검색 UI 점검. 관리자 도구에서 응답을 표시할 때 HTML escape 적용.
- 정기 침투 테스트. LLM 출력 경로의 XSS, SQL injection 같은 OWASP Top 10 항목을 정기 점검.
한계 :
- LLM은 출력 형식을 자유롭게 만들 수 있어 모든 변형을 정적 규칙으로 차단하기 어렵다.
- sanitize library도 새 우회 벡터에 지속적으로 대응해야 한다.
- 다층 방어(sanitize + CSP + sandbox + parameterize)와 OWASP Top 10 웹 보안 기본 통제를 결합하는 것이 현실적이다.
더 읽을 거리
- OWASP Top 10 for LLM 2025 LLM05 Improper Output Handling : https://genai.owasp.org/llmrisk/llm05-improper-output-handling/
- OWASP Top 10 for LLM 2023 v1.1 : https://owasp.org/www-project-top-10-for-large-language-model-applications/
- 본 플랫폼 관련 문제 : 05. J대리의 쿠키를 탈취하라