🪪 전자금융 보안 모의해킹 · 세션정보 재사용 제한
Target: 인터넷 뱅킹 세션
평가기준: 위험도 5 WEB-SER 세션정보 재사용(048)
평가기준: 위험도 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");
놓치기 쉬운 곳 — 동시 접속 제한은 무상태 구조에서 저절로 사라집니다.
전자금융 환경에서 요구된다면 서버측 세션 레지스트리를 따로 두어야 합니다.