3일차 (화) – 안드로이드 보안 기초 및 OWASP Mobile Top 10
목표: 안드로이드 운영체제 구조와 보안 기본 개념 학습 활동: 유튜브에서 “OWASP Mobile Top 10” 및 안드로이드 보안 개념 관련 무료 영상 시청 보안 취약점(예: 인텐트 검증, 파일 권한 문제) 목록 정리 실습: 각 취약점에 대한 간단한 사례를 메모장에 정리
내용이 너무 많아 (상),(하)로 나눴습니다. 시작하기 전에
OWASP Top 10이란?
개발자가 설계하고 배포하는 애플리케이션의 보안을 강화할 수 있도록 가장 중요한 애플리케이션 보안 위험을 나열하는 업계 표준 가이드라인입니다.
Web, Mobile, API 뿐 아니라, IoT, Cloud 등에 대한 가이드라인도 제공하고 있습니다.
OWASP Mobile Top 10
M1
Improper Credential Usage (부적절한 자격 증명 사용)
구체적 형식
-
앱 내에 하드코딩된 API 키, 비밀번호, 토큰 등 자격 증명을 노출하거나 안전하게 관리하지 않아 공격자가 이를 추출하는 경우.
실제 사례 및 예시
-
일부 금융/게임 앱에서 API 키를 소스코드에 하드코딩하여 역컴파일 시 노출됨.
-
Snapchat의 과거 사례(하드코딩 문제로 인해 API 접근이 노출된 사례)
대응 방안
-
하드코딩 금지, 안전한 키 관리 솔루션(예: 키스토어) 사용
-
자격 증명 주기적 갱신 및 암호화 저장
M2
Inadequate Supply Chain Security (불충분한 공급망 보안)
구체적 형식
-
서드파티 라이브러리, SDK, 오픈소스 컴포넌트 등 외부 구성 요소가 검증 없이 앱에 포함되어, 악의적으로 수정되거나 악성 코드가 삽입되는 경우.
실제 사례 및 예시
-
일부 앱에서 사용된 오픈소스 라이브러리의 취약점을 공격자가 악용해 백도어를 삽입한 사례.
-
서드파티 SDK를 통해 외부에서 전달된 업데이트가 변조되어 악성 코드를 포함한 사례.
대응 방안
-
신뢰할 수 있는 공급업체 및 라이브러리 사용, 정기적인 보안 스캔 및 업데이트 적용 공급망 보안 정책 수립 및 서드파티 구성 요소에 대한 검증 절차 마련
M3
Insecure Authentication/Authorization (보안에 취약한 인증/권한 부여)
구체적 형식
-
사용자 인증, 세션 관리, 권한 검증 등의 메커니즘이 미흡하여 공격자가 인증 절차를 우회하거나 권한 상승을 시도할 수 있는 경우.
실제 사례 및 예시
-
Facebook API 취약점을 통해 특정 API 호출 시 관리자 권한을 부여받은 사례가 있음.
-
WordPress REST API에서 인증 우회로 인해 게시물 수정/삭제가 가능했던 사례.
대응 방안
-
서버 측에서 강력한 인증 및 세션 관리 구현(예: 2단계 인증, OTP 도입); 최소 권한 원칙 및 역할 기반 접근 제어(RBAC) 적용; 정기적인 보안 점검.
M4
Insufficient Input/Output Validation (부족한 입력/출력 검증)
구체적 형식
-
사용자 입력이나 외부 데이터에 대해 유효성 검증이 미흡하여 SQL 인젝션, 커맨드 인젝션, XSS 등의 공격이 발생하는 경우.
실제 사례 및 예시
-
앱에서 사용자 입력값에 대한 검증 없이 데이터베이스 쿼리를 구성해 SQL 인젝션 공격에 취약했던 사례
-
인텐트 데이터나 파일 경로를 검증하지 않아 경로 순회(Path Traversal) 공격에 노출된 사례
대응 방안
-
모든 입력 데이터에 대해 엄격한 유효성 검사 및 이스케이프 적용
-
매개변수화된 쿼리 사용 및 클라이언트/서버 양쪽에서 데이터 검증 강화
M5
Insecure Communication (안전하지 않은 통신)
구체적 형식
-
네트워크 통신 시 암호화(SSL/TLS) 미적용 또는 부적절한 구성으로 인해 중간자 공격(MITM)이나 데이터 도청에 노출되는 경우.
실제 사례 및 예시
-
HTTP를 통한 민감 데이터 전송 사례, 자체 서명된 인증서를 허용해 MITM 공격에 취약했던 사례
-
모바일 앱에서 SSL 인증서 검증을 우회하여 세션 토큰이 노출된 사례
대응 방안
-
모든 통신에 대해 강력한 SSL/TLS 적용 및 인증서 핀닝 구현
-
신뢰할 수 있는 CA 제공자의 인증서를 사용하고, 잘못된 인증서 감지 시 사용자에게 경고
M6
Inadequate Privacy Controls (불충분한 개인 정보 보호 제어)
구체적 형식
-
개인정보(Personal Identifiable Information, PII)를 처리하는 과정에서 불필요한 데이터 수집, 과도한 권한 요청, 안전하지 않은 저장 및 전송이 이루어지는 경우.
실제 사례 및 예시
-
앱에서 사용자 위치, 연락처 등 민감 정보를 암호화 없이 저장해 탈취된 사례
-
Equifax, LinkedIn 등 대형 해킹 사건에서 민감 정보 유출이 발생한 사례를 참고
대응 방안
-
최소한의 개인정보 수집 및 저장, 필요 시 강력한 암호화 적용
-
안전한 데이터 전송 및 저장소(예: Android Keystore, iOS 키체인) 사용
-
개인정보 보호 정책 및 사용자 동의 절차 강화
M7
Insufficient Binary Protections (부족한 바이너리 보호)
구체적 형식
-
앱 바이너리(DEX, APK 등)에 대한 난독화, 무결성 검사, 안티 디버깅 등의 보호 조치가 미흡하여 리버스 엔지니어링이나 코드 변조가 용이한 경우.
실제 사례 및 예시
-
모바일 게임에서 Lucky Patcher와 같은 도구를 사용해 인앱 결제 기능 우회 사례
-
APK를 역컴파일하여 민감 로직 및 API 키가 노출된 사례
대응 방안
-
코드 난독화, 디지털 서명, 체크섬 등 무결성 검증 도구 적용
-
RASP, 안티 디버깅, 안티 후킹 기술 도입 및 정적/동적 분석 도구 활용
M8
Security Misconfiguration (잘못된 보안 구성)
구체적 형식
-
기본 보안 설정, 권한, 디버깅 옵션 등이 올바르게 구성되지 않아 불필요한 정보 노출이나 무단 액세스가 발생하는 경우.
실제 사례 및 예시
-
디버그 모드가 활성화된 상태로 프로덕션 앱이 배포되어 내부 정보가 노출된 사례
-
안전하지 않은 기본 설정(예: 기본 관리자 계정, 불충분한 암호화 설정)으로 인해 공격자가 시스템에 접근한 사례
대응 방안
-
프로덕션 배포 전 모든 디버그 및 테스트 코드를 제거하고, 보안 구성 점검 수행
-
보안 설정, 기본 권한, API 엔드포인트, 네트워크 구성 등을 정기적으로 감사 및 업데이트
M9
Insecure Data Storage (안전하지 않은 데이터 저장소)
구체적 형식
-
민감 정보(자격 증명, PII 등)가 평문 또는 약한 암호화 방식으로 저장되어, 기기 탈취 또는 루팅 시 공격자가 파일 시스템에 직접 접근할 수 있는 경우.
실제 사례 및 예시
-
앱이 SharedPreferences나 외부 저장소(SD카드)에 민감 데이터를 평문으로 저장하여 루팅된 디바이스에서 정보가 탈취된 사례
-
일부 게임 앱에서 사용자의 로그인 정보가 암호화 없이 저장된 사례
대응 방안
-
민감 데이터를 저장할 때 플랫폼 제공 보안 저장소(예: Android Keystore, iOS 키체인) 활용
-
저장 전 데이터 암호화 및 접근 권한 강화를 통한 보안 적용
M10
Insufficient Cryptography (불충분한 암호화)
구체적 형식
-
암호화 알고리즘 선택 및 구현이 부적절하여, 민감 정보 보호에 실패하고 공격자가 암호화 데이터를 해독할 수 있는 경우.
실제 사례 및 예시
-
일부 앱이 MD5, SHA-1 등 취약한 해시 알고리즘을 사용하여 사용자 비밀번호를 처리해 해킹된 사례
-
Yahoo! 해킹 사건에서 약한 암호화 알고리즘으로 인해 수억 명의 사용자 정보가 유출된 사례
대응 방안
-
최신 암호화 알고리즘(AES, RSA, ECC 등)과 충분한 키 길이, 솔팅 및 KDF(PBKDF2, bcrypt 등) 적용
-
암호화 키의 안전한 관리 및 저장(예: 키 볼트, HSM 활용)
-
정기적인 보안 업데이트 및 암호화 구현 검토
궁금하신 점이나, 잘못된 정보가 있다면 댓글로 알려주세요. 감사합니다!