전자금융 보안: 서버 사이드 템플릿 인젝션(SSTI)

💡 쉽게 말하면
빈칸에 적은 글이 그대로 출력될 줄 알았는데, 서버가 {{7*7}}을 보고 진짜로 49를 계산해 버립니다. 입력은 항상 글자(값)로만 다루고 수식으로 계산하지 못하게 막아야 합니다.

🔓 공격 시뮬레이션 (Red Team)

🛡️ 대응 방안 (Blue Team)

템플릿 입력 처리🔒 Secured Channel

사용자 입력이 서버 템플릿 엔진에 그대로 합쳐져 평가되면, 공격자가 {{7*7}} 같은 표현식을 주입했을 때 서버가 이를 49로 계산합니다. 이를 발판으로 원격 코드 실행(RCE)·내부 정보 노출까지 이어집니다.

⚡ 템플릿 표현식 주입(SSTI)
{{7*7}}→49 확인 후 RCE 페이로드

OFF

📡 거래/인증 요청 (가로채어 변조 가능)

🖥️ 금융 시스템 처리 로그

[SYSTEM] Core Banking Channel ready.

[INFO] 거래 요청 대기 중...

⚖️ 컴플라이언스 위반 분석

공격 실행 후 분석 결과가 표시됩니다.

[심각] 전자금융 보안 기준 위반 감지

평가기준 [전자금융] 서버 사이드 템플릿 인젝션 방지(위험도 5)
입력값 검증 부재 / 코드 인젝션(IN)
신뢰할 수 없는 데이터의 동적 코드 평가

🛡️ 대응 코드/설정 실습

사용자 입력을 템플릿 소스로 합치지 말고, 미리 정의된 템플릿에 데이터 모델(변수)로만 바인딩하고 샌드박스/이스케이프를 적용해야 합니다. 템플릿 처리 로직을 보완하세요.

// [취약] 사용자 입력을 템플릿 소스로 직접 평가
public String render(String name) {
    // 입력이 그대로 템플릿 문법으로 해석됨
    Template t = engine.parse("안녕하세요, " + name + "님");
    return t.evaluate();
}

📚 금융보안원 평가기준 / 조치 가이드

1. 점검 항목

입력값 검증 > 서버 사이드 템플릿 인젝션(SSTI) 방지

2. 위험 분석

표현식 평가로 원격 코드 실행(RCE)
서버 내부 객체·환경변수 등 정보 노출

3. 조치 방법

사용자 입력을 템플릿 소스로 결합 금지
고정 템플릿에 데이터 모델 바인딩만 사용
템플릿 샌드박스·이스케이프 적용

🏗️ 현대 금융 IT 환경에서의 변형

샌드박스 템플릿서버리스LLM 프롬프트

어디가 달라졌나

SSTI 는 서버리스에서 더 위험합니다 — 함수 실행 역할의 권한을 그대로 얻기 때문에 템플릿 주입 하나가 클라우드 자격증명 탈취로 직결됩니다(IMDS·환경변수 접근). 그리고 LLM 프롬프트 템플릿이라는 새로운 주입 표면이 생겼습니다.

현대 스택에서의 조치

템플릿은 샌드박스 모드로 실행합니다(Jinja2 SandboxedEnvironment, Freemarker TemplateClassResolver.SAFE_RESOLVER).
사용자 입력으로 템플릿을 구성하지 않습니다. 입력은 렌더링 컨텍스트의 값으로만 전달합니다.
서버리스 함수는 최소 권한 역할을 부여합니다 — 주입되어도 얻을 것이 없게 만듭니다.

# 위험: 사용자 입력이 템플릿 문자열 자체가 된다
Template(f"안녕하세요 {user_input}님").render()

# 안전: 템플릿은 고정, 입력은 값으로
Template("안녕하세요 {{ name }}님").render(name=user_input)   # 샌드박스 환경에서

앞을 내다본다면 — LLM 연동 기능(상담 요약·문서 생성)에서 사용자 입력을 프롬프트 템플릿에 문자열 결합하면 같은 부류의 취약점이 됩니다. 출력을 그대로 실행·렌더링하지 않는 것이 원칙입니다.

🧨 전자금융 보안 모의해킹 · 서버 사이드 템플릿 인젝션(SSTI)

1. 점검 항목

2. 위험 분석

3. 조치 방법

어디가 달라졌나

현대 스택에서의 조치