← 메인으로

🚪 전자금융 보안 모의해킹 · 화면 강제실행 인증단계 우회

Target: 모바일뱅킹 내부 화면
평가기준: 위험도 5 MOB-SER 인증단계 우회
💡 쉽게 말하면
은행 건물에 입구 검문을 안 하면, 옆문으로 들어가 곧장 금고방까지 가버립니다. 모든 방 앞에서 출입증을 확인하면 검문을 건너뛸 수 없습니다.
🔓 공격 시뮬레이션 (Red Team)
🛡️ 대응 방안 (Blue Team)
화면 강제 호출🔒 Secured Channel
로그인·추가인증을 거치지 않고 내부 화면 URL/액티비티를 직접 강제 호출하면, 각 화면이 자체적으로 인증 상태를 확인하지 않을 경우 인증 단계를 통째로 건너뛰고 잔액·이체 화면에 진입할 수 있습니다.
⚡ 내부 액티비티 강제 호출
adb로 잔액/이체 화면 직접 실행
OFF
🖥️ 금융 시스템 처리 로그
[SYSTEM] Core Banking Channel ready.
[INFO] 거래 요청 대기 중...
⚖️ 컴플라이언스 위반 분석
공격 실행 후 분석 결과가 표시됩니다.
[심각] 전자금융 보안 기준 위반 감지
  • 평가기준 [전자금융] 인증단계 우회 방지(위험도 5)
  • 불충분한 인증 / 부적절한 접근통제(IN)
  • 전자금융감독규정 제37조 추가인증 의무 우회
🛡️ 대응 코드/설정 실습

각 보호 화면은 진입 시 반드시 인증 상태(로그인·추가인증 완료)를 서버 세션 기준으로 확인하고, 미충족 시 로그인 화면으로 강제 이동해야 합니다. 화면 진입 로직을 보완하세요.

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

1. 점검 항목

이용자 인증/인가 > 인증단계 우회 방지

2. 위험 분석

  • 내부 화면 강제 호출로 로그인·추가인증 생략
  • 잔액·이체 등 보호 화면 무단 진입

3. 조치 방법

  • 모든 보호 화면 진입 시 인증 상태 검증
  • 미인증 시 로그인 화면 강제 이동
  • 인증 상태는 서버 세션 기준으로 판단
🏗️ 현대 금융 IT 환경에서의 변형
SPABFFDeep Link

어디가 달라졌나

SPA·네이티브 앱에서 화면 전환은 전적으로 클라이언트가 합니다. 서버는 어떤 화면이 떠 있는지 모릅니다. 그래서 “인증 화면을 건너뛰었다”는 개념 자체가 “인증 API 를 호출하지 않고 다음 API 를 호출했다” 로 바뀝니다.

현대 스택에서의 조치

  • 화면이 아니라 상태 머신을 서버가 보관합니다. txnState: INIT → AUTHED → CONFIRMED 를 서버가 들고, 순서를 어기면 거절합니다.
  • BFF(Backend for Frontend) 를 두면 흐름 제어를 서버로 되돌릴 수 있습니다. 프런트는 다음 단계를 서버에서 받습니다.
  • 딥링크로 내부 화면에 바로 진입하는 경로도 같은 상태 검증을 통과해야 합니다.
// 단계 건너뛰기 차단 — 화면이 아니라 상태로
var txn = txnStore.get(txnId);
if (txn.state != AUTHED)
    throw new SecurityException("인증 단계 미완료: " + txn.state);
txn.state = CONFIRMED;
놓치기 쉬운 곳 — 상태를 클라이언트가 들고 서버에 보내면 아무것도 막지 못합니다. 상태 토큰을 서명해서 넘기더라도 이전 단계의 유효한 토큰을 재사용할 수 있으므로, 서버 보관이 원칙입니다.