← 메인으로

🕵️ 전자금융 보안 모의해킹 · 시스템 운영정보 노출 방지

Target: 웹 서버 응답/에러 페이지
평가기준: 위험도 4 WEB-SER 시스템 운영정보 노출(031)
💡 쉽게 말하면
우리 집 현관에 금고 모델명과 비밀번호 힌트를 붙여두면, 도둑이 그 모델 약점만 골라 노려옵니다. 서버도 종류·버전·내부 경로를 숨기고 손님에겐 깔끔한 안내문만 보여줘야 합니다.
🔓 공격 시뮬레이션 (Red Team)
🛡️ 대응 방안 (Blue Team)
서버 응답 정보 수집🔒 Secured Channel
에러 페이지·응답 헤더(Server, X-Powered-By)·스택트레이스로 서버 종류·버전·내부 경로가 그대로 노출되면, 공격자가 해당 버전의 알려진 취약점을 골라 표적 공격에 활용할 수 있습니다.
⚡ 운영정보 핑거프린팅
헤더·에러페이지로 서버 종류·버전·경로 수집
OFF
🖥️ 금융 시스템 처리 로그
[SYSTEM] Core Banking Channel ready.
[INFO] 거래 요청 대기 중...
⚖️ 컴플라이언스 위반 분석
공격 실행 후 분석 결과가 표시됩니다.
[심각] 전자금융 보안 기준 위반 감지
  • 평가기준 [전자금융] 시스템 운영정보 노출 방지(위험도 4)
  • 정보 노출(Information Exposure) / 불충분한 오류 처리(IN)
  • 전자금융감독규정 제15조: 시스템 정보 보호 미흡
🛡️ 대응 코드/설정 실습

서버 종류·버전 헤더를 숨기고, 상세 오류를 사용자에게 노출하지 말고 커스텀 에러 페이지로 표준 메시지만 반환해야 합니다. 스택트레이스·내부 경로는 로그에만 기록합니다. 설정을 보완하세요.

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

1. 점검 항목

서버 보안 > 시스템 운영정보 노출 방지

2. 위험 분석

  • 헤더·에러로 서버 종류·버전 식별
  • 버전 기반 알려진 취약점 표적 공격
  • 스택트레이스로 내부 경로 노출

3. 조치 방법

  • 서버/프레임워크 버전 헤더 숨김
  • 커스텀 에러 페이지로 표준 메시지만 반환
  • 스택트레이스·상세 오류는 로그에만 기록
🏗️ 현대 금융 IT 환경에서의 변형
구조화 로깅APM에러 핸들러

어디가 달라졌나

스택트레이스가 브라우저가 아니라 로그 수집기·APM 으로 갑니다. 화면에는 안 보여도 Sentry·Datadog 대시보드에 요청 본문과 함께 그대로 남고, 그 대시보드는 대개 조직 전체에 열려 있습니다 — 노출 대상이 바뀐 것뿐입니다.

현대 스택에서의 조치

  • 사용자에게는 추적 ID 만 보여 줍니다(traceId: 7f3a...). 상세는 서버 로그에서 그 ID 로 찾습니다.
  • APM·로그 수집기에 마스킹 규칙을 설정합니다 — 계좌번호·주민번호·토큰·인증코드.
  • 프레임워크 기본 에러 페이지를 반드시 교체합니다(Spring server.error.include-stacktrace=never).
// 사용자 응답과 내부 로그를 분리한다
log.error("txn failed userId={} traceId={}", userId, traceId, e);   // 내부
return ResponseEntity.status(500)
        .body(Map.of("message", "처리 중 오류", "traceId", traceId)); // 외부
놓치기 쉬운 곳 — 응답 헤더도 정보원입니다. Server: Apache/2.4.41 (Ubuntu), X-Powered-By, 상세 WWW-Authenticate 는 제거하세요.