CSTI

좋은 질문이에요 👍
CSTI(Client-Side Template Injection)와 SSTI(Server-Side Template Injection)는 모두 템플릿 엔진을 통한 코드 실행 취약점이라는 공통점이 있지만, 동작 환경(클라이언트/서버)에 따라 대응 방식이 달라집니다. 보안 전문가 관점에서 기술적 대응 + 운영적 대응을 함께 정리해드릴게요.


✅ CSTI 및 SSTI 보안 취약점 대응방안

  1. 공통 대응방안

템플릿 엔진의 동적 코드 실행 기능 제한

Jinja2, Freemarker, Thymeleaf, Mustache 등 템플릿 엔진이 제공하는 코드 실행 함수(eval, exec, {{7*7}} 같은 표현식)를 차단하거나 최소화.

출력 시 이스케이프(Escape) 처리

사용자 입력값을 템플릿으로 직접 전달하지 않고, 반드시 HTML 이스케이프(<, >, ", ') 또는 JSON 인코딩 처리.

화이트리스트 기반 출력

사용자가 입력한 값 중 UI에 필요한 특정 값만 허용 (예: 정규식으로 허용 문자 한정).

Sandbox 기능 활성화

일부 템플릿 엔진(Jinja2 sandbox, Freemarker TemplateConfiguration)은 샌드박스를 제공 → 시스템 함수 접근 차단.

코드/데이터 분리 원칙 적용

템플릿 문법({{ }}, ${ })이 절대로 사용자 입력에 포함되지 않도록 설계.

보안 테스트 및 코드 리뷰

보안 스캐너나 Fuzzing으로 CSTI/SSTI 취약점 검증.

개발 단계에서 SAST(정적 분석) + DAST(동적 분석) 병행.


  1. CSTI 대응방안 (Client-Side Template Injection)

📌 대상: 프론트엔드 템플릿 엔진(AngularJS, Vue.js, React 초기 버전, Handlebars.js 등)

AngularJS, Vue.js 등에서 동적 바인딩 제한

AngularJS → ng-bind 사용 권장, ng-app 범위 최소화.

Vue.js → v-bind에서 사용자 입력을 직접 사용하지 않음.

템플릿 문법 필터링

{{, }}, ${, <% %> 와 같은 예약 문법을 입력값에서 제거 또는 이스케이프 처리.

CSP(Content Security Policy) 적용

악성 JS 코드 실행 방지. script-src 'self' 정책 적용.

서버에서 HTML Sanitizer 적용

DOMPurify 같은 라이브러리를 이용해 클라이언트로 전달되는 데이터에서 위험한 스크립트 제거.


  1. SSTI 대응방안 (Server-Side Template Injection)

📌 대상: 서버 사이드 템플릿 엔진(Jinja2, Twig, Freemarker, Pug, Thymeleaf 등)

사용자 입력을 템플릿 엔진에 직접 전달하지 않음

❌ 잘못된 예시:

template = Template(user_input)
template.render()

✅ 올바른 예시:

template = Template("Hello {{ name }}")
template.render({"name": user_input})

템플릿 엔진 보안 모드 사용

Jinja2 → SandboxedEnvironment

Freemarker → Configuration.setAPIBuiltinEnabled(false)

템플릿 구문 차단

{{, {%, ${, <% %> 등의 패턴을 입력값에서 필터링.

로깅/모니터링 강화

SSTI 공격 시도 흔적({{77}}, ${77} 등)을 WAF/로그에서 탐지.

WAF(Web Application Firewall) 적용

ModSecurity, AWS WAF 등에서 SSTI 패턴 차단 룰 적용.


  1. 운영적 대응

보안 가이드라인 제정

개발팀에 "사용자 입력을 절대 템플릿 엔진에 직접 연결하지 않는다"는 규칙 문서화.

주기적 취약점 점검

모의해킹/보안 진단 시 SSTI, CSTI 케이스 포함.

최신 버전 유지

템플릿 엔진의 보안 패치 주기적 반영.


📌 정리:

CSTI는 프론트엔드에서 JS 실행 차단과 템플릿 문법 이스케이프가 핵심.

SSTI는 서버에서 입력값을 템플릿에 직접 연결하지 않도록 구조 변경이 핵심.

두 경우 모두 화이트리스트 검증, 보안 모드, WAF, 정기 진단을 병행해야 안전하게 방어 가능.


혹시 제가 보안 보고서 형식(예: 개요 → 원인 → 영향 → 대응방안)으로 정리해드릴까요? 아니면 개발 가이드라인 형태(예: 개발팀이 바로 적용할 수 있는 코드 예시 위주)로 드릴까요?