← 메인으로

🔑 전자금융 보안 모의해킹 · 이용자 인증정보 재사용 방지

Target: 전자서명 인증 검증 API
평가기준: 위험도 5 WEB-SER 인증정보 재사용(004)
💡 쉽게 말하면
한 번 쓴 일회용 비밀번호를 또 받아주면 누가 그걸 베껴 쓸 수 있습니다. 서버는 쓴 번호를 기억하고 다시는 받지 말아야 합니다.
🔓 공격 시뮬레이션 (Red Team)
🛡️ 대응 방안 (Blue Team)
인증값 검증 요청🔒 Secured Channel
전자서명값이나 OTP 같은 일회성 인증값을 서버가 한 번만 소비하지 않으면, 중간자가 가로챈 인증값을 재전송해 인증 단계를 그대로 통과할 수 있습니다.
⚡ 인증값 재전송(Replay)
캡처한 전자서명값을 동일하게 재전송
OFF
🖥️ 금융 시스템 처리 로그
[SYSTEM] Core Banking Channel ready.
[INFO] 거래 요청 대기 중...
⚖️ 컴플라이언스 위반 분석
공격 실행 후 분석 결과가 표시됩니다.
[심각] 전자금융 보안 기준 위반 감지
  • 금융보안원 평가기준 WEB-SER 인증정보 재사용(004) (위험도 5)
  • 일회성 인증값 재사용 방지 위반
  • 전자금융감독규정 제34조(전자서명) 미흡
🛡️ 대응 코드/설정 실습

서버는 인증값을 한 번만 소비하고, challenge nonce와 유효시간을 검증해야 합니다. 아래 코드를 보완하세요.

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

1. 점검 항목

인증 검증 > 이용자 인증정보 재사용 방지

2. 위험 분석

  • 가로챈 전자서명값·OTP 재전송으로 인증 단계 우회

3. 조치 방법

  • 인증값 일회성 소비(서버 사용이력)
  • challenge nonce·유효시간 검증
🏗️ 현대 금융 IT 환경에서의 변형
금융인증서Refresh RotationOIDC

어디가 달라졌나

공동인증서(구 공인인증서) 독점이 풀리면서 금융인증서·간편인증·패스키가 병존합니다. 인증 수단은 늘었지만 “한 번 만든 인증 결과를 계속 재사용할 수 있는가”라는 문제는 오히려 커졌습니다 — 특히 OAuth/OIDC 토큰이 새로운 재사용 대상입니다.

현대 스택에서의 조치

  • 전자서명 검증에는 서버가 발급한 일회성 challenge 를 포함시킵니다. 서명값만 캡처해 재사용하지 못하게 합니다.
  • Refresh Token Rotation: 갱신할 때마다 새 refresh 를 발급하고 구 토큰을 무효화합니다. 구 토큰이 다시 쓰이면 탈취로 간주하고 세션 계열 전체를 폐기합니다.
  • access token 수명은 짧게(5~15분), 민감 거래에는 재인증(step-up) 을 요구합니다.
// refresh 재사용 탐지 — 토큰 계열(family) 단위로 폐기
if (tokenStore.isUsed(refreshJti)) {
    tokenStore.revokeFamily(familyId);        // 탈취 신호
    audit.warn("refresh reuse detected", userId);
    throw new SecurityException("re-authentication required");
}
놓치기 쉬운 곳 — 인증서 검증에서 만료·폐기(CRL/OCSP) 확인을 빠뜨리는 구현이 흔합니다. 서명이 수학적으로 맞는 것과 그 인증서가 지금 유효한 것은 다릅니다.