전자금융 보안: 모바일 DeepLink 도용

← 메인으로

💡 쉽게 말하면
아무 택배 운송장이나 붙이면 그대로 배달되듯, 검증 없는 링크는 위조해 보내면 앱이 시키는 대로 합니다. 정해진 허용 목록의 링크만 받고 돈 나가는 일은 본인 확인을 또 받아야 합니다.

🔓 공격 시뮬레이션 (Red Team)

🛡️ 대응 방안 (Blue Team)

DeepLink 수신 처리🔒 Secured Channel

검증 없는 DeepLink/커스텀 스킴(예: bankapp://)을 외부에서 그대로 수신·실행하면, 공격자가 만든 악성 링크가 앱을 호출해 피싱 화면 표시·세션 탈취·이체 화면 자동 실행 등 임의 동작을 유발할 수 있습니다.

⚡ 악성 DeepLink 유도
문자/웹의 위조 링크로 이체 화면 자동 호출

OFF

📡 거래/인증 요청 (가로채어 변조 가능)

🖥️ 금융 시스템 처리 로그

[SYSTEM] Core Banking Channel ready.

[INFO] 거래 요청 대기 중...

⚖️ 컴플라이언스 위반 분석

공격 실행 후 분석 결과가 표시됩니다.

[심각] 전자금융 보안 기준 위반 감지

평가기준 [전자금융] DeepLink 도용 방지(위험도 5)
부적절한 인텐트 처리 / 출처 검증 부재(IN)
검증되지 않은 리다이렉트 및 임의 동작 유발

🛡️ 대응 코드/설정 실습

DeepLink 수신 시 허용된 경로·파라미터만 허용목록(allowlist)으로 검증하고, 민감 동작(이체 등)은 링크만으로 실행하지 말고 인증·사용자 확인을 강제해야 합니다. 수신 처리 로직을 보완하세요.

// [취약] DeepLink를 검증 없이 그대로 실행
override fun onNewIntent(intent: Intent) {
    val data = intent.data ?: return
    val path = data.host    // 예: "transfer"
    navigate(path, data.query)   // 출처/값 검증 없이 화면 이동
}

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

1. 점검 항목

모바일 보안 > DeepLink 도용 방지

2. 위험 분석

위조 링크로 피싱 화면·세션 탈취
이체 등 민감 화면 자동 실행(임의 동작)

3. 조치 방법

수신 경로·파라미터 허용목록(allowlist) 검증
민감 동작은 인증·사용자 확인 강제
커스텀 스킴 대신 검증된 App Link 사용 권장

🏗️ 현대 금융 IT 환경에서의 변형

App LinksUniversal LinksPKCE

어디가 달라졌나

커스텀 스킴(mybank://)은 누구나 선점할 수 있습니다. 악성 앱이 같은 스킴을 등록하면 OS 가 선택 창을 띄우거나 그쪽으로 보내 버립니다. 그래서 검증된 딥링크 (Android App Links, iOS Universal Links)가 표준이 되었습니다 — 도메인 소유 증명이 필요해 선점이 불가능합니다.

현대 스택에서의 조치

assetlinks.json / apple-app-site-association 을 도메인에 게시하고 autoVerify 를 켭니다.
딥링크 파라미터는 전부 신뢰할 수 없는 입력입니다. 이체 금액·수취계좌를 딥링크로 받아 화면에 미리 채우는 설계는 피싱에 직결됩니다.
OAuth 리다이렉트에는 PKCE 를 적용합니다. 인가코드가 탈취돼도 code_verifier 없이는 못 씁니다.

<!-- 검증된 App Link — 스킴이 아니라 도메인 소유로 증명한다 -->
<intent-filter android:autoVerify="true">
  <data android:scheme="https" android:host="m.bank.example" />
</intent-filter>

놓치기 쉬운 곳 — App Links 를 켜도 커스텀 스킴을 같이 남겨 두면 우회 경로가 유지됩니다. 레거시 호환 때문에 남긴 스킴이 실제 공격 경로가 됩니다 — 기한을 정해 제거하세요.

🔗 전자금융 보안 모의해킹 · 모바일 DeepLink 도용

1. 점검 항목

2. 위험 분석

3. 조치 방법

어디가 달라졌나

현대 스택에서의 조치