← 메인으로

🔐 전자금융 보안 모의해킹 · 인증수단 소유자 검증

Target: 이체 인증 API
평가기준: 위험도 5 WEB-SER 인증수단 소유자 검증(049)
💡 쉽게 말하면
내 이름표를 보지 않고 아무 도장이나 찍어 주는 셈입니다. 도장이 내 것인지 먼저 확인해야 합니다.
🔓 공격 시뮬레이션 (Red Team)
🛡️ 대응 방안 (Blue Team)
타인 인증수단으로 거래🔒 Secured Channel
OTP·보안카드·인증서가 거래 요청자 본인 소유인지 서버가 확인하지 않으면, 타인의(혹은 공유된) 인증수단으로 거래가 가능합니다.
⚡ 소유자 미검증 인증
다른 사람 OTP 시리얼로 본인 거래 승인
OFF
🖥️ 금융 시스템 처리 로그
[SYSTEM] Core Banking Channel ready.
[INFO] 거래 요청 대기 중...
⚖️ 컴플라이언스 위반 분석
공격 실행 후 분석 결과가 표시됩니다.
[심각] 전자금융 보안 기준 위반 감지
  • 평가기준 [전자금융] 인증수단 소유자 검증(049)(위험도 5)
  • 인증수단 소유 매핑 검증 위반
  • 전자금융감독규정 제34조 미흡
🛡️ 대응 코드/설정 실습

서버는 인증수단이 거래 주체의 소유인지 소유 매핑을 검증해야 합니다. 아래 코드를 보완하세요.

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

1. 점검 항목

인증 처리 > 인증수단 소유자 검증

2. 위험 분석

  • 소유자 미검증으로 타인 인증수단 거래
  • 공유 인증수단 악용

3. 조치 방법

  • 인증수단과 거래 주체(계정·CI)의 소유 매핑 검증
  • 불일치 시 거래 차단
🏗️ 현대 금융 IT 환경에서의 변형
오픈뱅킹마이데이터MSA

어디가 달라졌나

인증수단이 기관 경계를 넘습니다. 핀테크 앱이 오픈뱅킹으로 여러 은행 계좌를 다루고, 마이데이터 사업자가 타 기관 정보를 모읍니다. “이 인증수단이 이 사람 것인가”를 내 시스템 안에서만 확인할 수 없는 구조가 되었습니다.

현대 스택에서의 조치

  • 사용자 ↔ 인증수단 ↔ 계좌 목록의 매핑을 서버가 보관하고, 거래 요청마다 세 가지가 모두 일치하는지 확인합니다.
  • 오픈뱅킹은 access token 의 사용자와 요청 핀테크 이용번호가 일치하는지 검증합니다. 토큰만 맞으면 통과시키는 구현이 실제 사고 사례입니다.
  • 기기 변경·재설치 시 인증수단을 재등록하게 하고, 이전 기기의 등록은 폐기합니다.
// 세 겹 검증 — 하나라도 빠지면 남의 계좌로 이체된다
assertOwner(session.userId, req.fintechUseNo);      // 인증수단 소유자
assertLinked(req.fintechUseNo, req.withdrawAccount); // 인증수단-계좌 연결
assertScope(token, "transfer");                      // 동의 범위
놓치기 쉬운 곳 — 탈퇴·해지 시 매핑을 지우지 않으면 같은 번호가 재발급될 때 과거 연결이 되살아납니다. 해지 처리에 매핑 정리를 포함하세요.