← 메인으로

🔐 전자금융 보안 모의해킹 · 거래 인증수단 검증 (OTP/보안카드 우회)

Target: 이체 2차 인증
평가기준: 위험도 5 WEB-FIN 거래 인증
💡 쉽게 말하면
OTP 검사를 은행(서버)이 아니라 내 폰(클라이언트)이 한다면, 화면의 "성공" 글자만 위조해도 통과됩니다. 인증은 반드시 서버가 확인해야 합니다.
🔓 공격 시뮬레이션 (Red Team)
🛡️ 대응 방안 (Blue Team)
이체 2차 인증🔒 Secured Channel
이체 시 OTP·보안카드 등 거래 인증이 서버에서 강제되지 않고 클라이언트 응답(success=true)만으로 처리되면, 인증 단계를 로직 변조로 우회할 수 있습니다.
⚡ 2차 인증 우회
authResult를 강제로 success로 변조
OFF
🖥️ 금융 시스템 처리 로그
[SYSTEM] Core Banking Channel ready.
[INFO] 거래 요청 대기 중...
⚖️ 컴플라이언스 위반 분석
공격 실행 후 분석 결과가 표시됩니다.
[심각] 전자금융 보안 기준 위반 감지
  • 평가기준 [전자금융] 거래 인증수단 검증(위험도 5)
  • 불충분한 인증 / 폐기된 인증수단 사용 통제 미흡
  • 전자금융감독규정 제37조 추가인증 의무 위반
🛡️ 대응 코드/설정 실습

인증 판단은 반드시 서버에서 수행하고, 클라이언트가 보낸 인증결과를 신뢰하면 안 됩니다. OTP 유효성·유효시간·폐기여부를 서버에서 검증하세요.

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

1. 점검 항목

거래 인증 > 거래 인증수단 검증

2. 위험 분석

  • 잘못된/폐기된 인증정보로 정상 거래 가능
  • 인증 유효시간 미제한으로 탈취 인증정보 재사용

3. 조치 방법

  • 인증 검증은 서버 사이드에서 수행
  • OTP/보안카드 유효시간·폐기여부 확인
  • 클라이언트 스크립트로 인증 처리 금지
🏗️ 현대 금융 IT 환경에서의 변형
FIDO2 / 패스키푸시 승인Transaction Signing

어디가 달라졌나

OTP·보안카드는 공유 비밀 방식이라 피싱·중계 공격에 약합니다. 국내외 금융권은 FIDO2/패스키(공개키 기반) 와 앱 푸시 승인 으로 옮겨 가고 있습니다. 다만 인증 방식이 바뀌어도 취약점의 본질은 그대로입니다 — "2차 인증을 통과했다"는 사실을 누가 서버에 알려 주는가.

현대 스택에서의 조치

  • 클라이언트가 {"otpVerified": true} 를 보내는 구조는 방식과 무관하게 위험합니다. 서버가 인증 상태를 보관해야 합니다.
  • 거래 단위 서명(Transaction Signing): 인증 대상에 수취계좌·금액을 포함시켜 서명받습니다. "로그인 승인"과 "5천만원 이체 승인"이 구분됩니다.
  • FIDO2 라면 challenge 에 거래 해시를 넣고, 응답의 clientDataJSON 에서 그 값을 서버가 대조합니다.
// 푸시 승인 화면에 반드시 거래 내용을 띄운다 — "무엇을 승인하는지" 모르면 의미가 없다
{
  "title": "이체 승인",
  "amount": "50,000,000원",
  "to": "국민 123-45-6789 홍길동",
  "challenge": "sha256(txnId|to|amount|nonce)"
}
놓치기 쉬운 곳 — 승인 화면에 거래 내용을 안 띄우면 중계 공격이 그대로 성립합니다. 공격자가 유도한 이체를 사용자가 "로그인인 줄 알고" 승인합니다. 이를 거래 내용 확인(WYSIWYS) 이라 부릅니다.