← 메인으로

🪪 전자금융 보안 모의해킹 · 세션정보 재사용 제한

Target: 인터넷 뱅킹 세션
평가기준: 위험도 5 WEB-SER 세션정보 재사용(048)
💡 쉽게 말하면
로그아웃했는데 옛 출입증이 계속 통하는 셈입니다. 반납한 출입증은 즉시 정지시켜야 합니다.
🔓 공격 시뮬레이션 (Red Team)
🛡️ 대응 방안 (Blue Team)
만료된 세션으로 거래 요청🔒 Secured Channel
로그아웃·만료 후에도 서버 세션ID·토큰이 유효하면, 탈취된 세션을 재사용해 거래를 일으킬 수 있습니다.
⚡ 폐기된 세션 재사용
로그아웃 후 옛 세션 쿠키로 이체 요청
OFF
🖥️ 금융 시스템 처리 로그
[SYSTEM] Core Banking Channel ready.
[INFO] 거래 요청 대기 중...
⚖️ 컴플라이언스 위반 분석
공격 실행 후 분석 결과가 표시됩니다.
[심각] 전자금융 보안 기준 위반 감지
  • 평가기준 [전자금융] 세션정보 재사용(048)(위험도 5)
  • 세션 무효화·재사용 방지 위반
  • 전자금융감독규정 제34조 미흡
🛡️ 대응 코드/설정 실습

서버는 로그아웃·만료 시 세션을 무효화(invalidate)해야 합니다. 아래 코드를 보완하세요.

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

1. 점검 항목

세션 관리 > 세션정보 재사용 제한

2. 위험 분석

  • 로그아웃·만료 후 세션 유효로 재사용 거래
  • 탈취 세션으로 부정 이체

3. 조치 방법

  • 로그아웃 시 서버 세션 무효화(invalidate)
  • 세션 만료·재발급 적용
  • 토큰 블랙리스트 관리
🏗️ 현대 금융 IT 환경에서의 변형
JWTRedis Deny ListSPA

어디가 달라졌나

세션 쿠키에서 무상태 JWT 로 옮겨 가면서 새 문제가 생겼습니다 — JWT 는 서버가 취소할 수 없습니다. 로그아웃해도 만료 전까지 유효하고, 권한을 회수해도 토큰 안의 roles 는 그대로입니다. “세션 무효화”라는 평가항목이 그냥 사라진 것처럼 보이지만, 실제로는 더 어려워진 것입니다.

현대 스택에서의 조치

  • access token 은 짧게(5~15분), 취소는 refresh 폐기 + Redis deny list(jti 기준, 남은 수명만큼만 보관)로 구현합니다.
  • 중요 변경(비밀번호 변경·권한 회수·기기 해제) 시 사용자 단위 토큰 무효화 시각을 저장하고, 그보다 오래된 iat 토큰을 거부합니다.
  • SPA 는 토큰을 localStorage 에 두지 말고 HttpOnly·Secure·SameSite 쿠키 로. XSS 실습을 같은 출처에서 제공하는 서비스라면 더욱 그렇습니다.
// 사용자 단위 일괄 무효화 — deny list 보다 가볍다
long cutoff = userRepo.getTokensInvalidAfter(userId);   // 비밀번호 변경 시각 등
if (claims.getIssuedAt().toEpochMilli() < cutoff)
    throw new SecurityException("session invalidated");
놓치기 쉬운 곳 — 동시 접속 제한은 무상태 구조에서 저절로 사라집니다. 전자금융 환경에서 요구된다면 서버측 세션 레지스트리를 따로 두어야 합니다.