← 메인으로

🔁 전자금융 보안 모의해킹 · 거래정보 재사용 방지 (리플레이)

Target: 간편결제 승인 API
평가기준: 위험도 5 WEB-SER 거래정보 재사용 방지
💡 쉽게 말하면
결제 영수증을 복사해 10번 다시 내밀면 10번 결제되는 셈입니다. 매번 다른 일회용 번호(nonce)를 붙여야 같은 거래의 재전송을 막습니다.
🔓 공격 시뮬레이션 (Red Team)
🛡️ 대응 방안 (Blue Team)
결제 승인 요청🔒 Secured Channel
정상 결제 전문에 일회성 토큰(nonce)·타임스탬프가 없으면, 가로챈 결제 전문을 그대로 재전송하여 동일 결제를 무한 반복(중복 출금)할 수 있습니다.
⚡ 결제 전문 재전송(Replay)
캡처한 승인 전문을 N회 재전송
OFF
🖥️ 금융 시스템 처리 로그
[SYSTEM] Core Banking Channel ready.
[INFO] 거래 요청 대기 중...
⚖️ 컴플라이언스 위반 분석
공격 실행 후 분석 결과가 표시됩니다.
[심각] 전자금융 보안 기준 위반 감지
  • 평가기준 [전자금융] 거래정보 재사용 방지(위험도 5)
  • 이용자 인증정보 재사용 방지(전자서명/OTP 일회성) 위반
  • 전자금융감독규정 제34조 해킹 방지대책 미흡
🛡️ 대응 코드/설정 실습

서버는 거래마다 일회성 nonce를 발급·소비하고, 사용 이력/타임스탬프로 재전송을 거부해야 합니다. 검증 로직을 보완하세요.

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

1. 점검 항목

거래정보 검증 > 거래정보 재사용 방지

2. 위험 분석

  • 이체/결제 전문 재전송으로 중복 출금
  • OTP·전자서명 등 일회성 값 재사용

3. 조치 방법

  • 거래별 nonce(일회성 토큰) 발급·소비
  • 요청 타임스탬프 유효시간 제한
  • 주문/거래 ID 멱등성(idempotency) 보장
🏗️ 현대 금융 IT 환경에서의 변형
멱등성 키Redis오토스케일링Kafka

어디가 달라졌나

단일 서버에서는 Set<String> usedNonce 같은 인메모리 저장으로도 막혔습니다. 오토스케일링으로 파드가 여러 개면 이 방어는 즉시 무너집니다 — 같은 nonce 가 다른 파드로 가면 "처음 보는 값"이 됩니다. 게다가 Kafka 같은 스트림은 기본이 at-least-once 라 정상 운영 중에도 같은 이벤트가 두 번 옵니다.

현대 스택에서의 조치

  • nonce 저장소를 공유 저장소로: Redis SET key NX EX 300 또는 DB 유니크 제약. 원자적 연산이어야 합니다.
  • API 는 Idempotency-Key 헤더를 받습니다(Stripe·토스페이먼츠 등이 쓰는 표준 방식). 같은 키의 재요청에는 재처리 대신 첫 응답을 그대로 반환합니다.
  • 컨슈머는 멱등하게 설계합니다. "이미 처리된 주문인가"를 원장에서 확인하는 것이 재전송 방어의 최종선입니다.
// Redis 원자적 선점 — 다중 파드에서도 단 한 번만 통과
Boolean first = redis.opsForValue()
        .setIfAbsent("nonce:" + req.getNonce(), "1", Duration.ofMinutes(5));
if (!Boolean.TRUE.equals(first))
    return ledger.findResult(req.getIdempotencyKey());  // 첫 응답 재사용
놓치기 쉬운 곳 — Redis 가 죽으면 어떻게 되는가. 예외를 삼키고 통과시키면 장애 시점이 곧 리플레이 창구가 됩니다. 저장소 장애 시에는 거래를 거절하는 쪽이 안전합니다(fail-closed).