Security

Mobile Security

OWASP Top 10 Mobile- 2024

Jun 24, 2023 ·

OWASP Mobile Top 10 - 2024

The 2024 OWASP Mobile Top 10 reflects a significant restructuring from the 2016 list, consolidating some categories and adding new ones to reflect the current threat landscape for Android and iOS applications.

M1: Improper Credential Usage

Hardcoded credentials, improperly stored secrets, and insecure transmission of authentication credentials remain the leading mobile vulnerability. This category covers:

API keys, tokens, and passwords hardcoded directly in source code or resource files.
Credentials stored in plaintext in SharedPreferences, plist files, or SQLite databases.
Authentication tokens transmitted over HTTP or stored in insecure locations.
Credentials exposed in log output or error messages.

Mitigation: Never hardcode credentials. Use the platform’s secure storage (Android Keystore, iOS Keychain). Enforce HTTPS for all credential transmission. Implement certificate pinning.

M2: Inadequate Supply Chain Security

Mobile applications depend heavily on third-party SDKs, libraries, and development toolchains. Vulnerabilities in these dependencies directly impact the app.

Malicious or compromised third-party SDKs.
Outdated libraries with known vulnerabilities.
Unverified dependencies or build tools.
Tampering during the build or distribution pipeline.

Mitigation: Audit all third-party dependencies. Pin dependency versions and verify checksums. Monitor CVE databases for dependency vulnerabilities. Use software composition analysis (SCA) tools.

M3: Insecure Authentication and Authorization

Authentication mechanisms that can be bypassed at the client level or that rely entirely on client-side checks. This includes:

Authentication decisions made purely in local code (e.g., isAdmin = true in client logic).
Biometric authentication bypass via runtime instrumentation.
Broken or missing authorization checks on API endpoints.
Token-based auth without proper server-side validation.

Mitigation: Enforce all authentication and authorization on the server. Never trust client-supplied privilege claims. Validate tokens server-side on every request.

M4: Insufficient Input/Output Validation

Lack of validation on data received from users, other apps, or the network leads to injection attacks, logic bypasses, and data corruption.

SQL injection through content providers or deep link parameters.
JavaScript injection via insecure WebView configuration.
Intent injection through exported components without input validation.
XML/JSON injection in API responses processed without validation.

Mitigation: Validate all input at every trust boundary. Use parameterized queries. Sanitize all data displayed in WebViews. Treat data from other apps as untrusted.

M5: Insecure Communication

Data transmitted between the app and backend that is inadequately protected:

Using HTTP instead of HTTPS.
Accepting self-signed or expired certificates without warning.
Disabling certificate validation entirely in code.
Missing or bypassable certificate pinning.
Weak TLS configurations (outdated protocol versions, weak cipher suites).

Mitigation: Enforce HTTPS with valid certificates. Implement certificate pinning for sensitive backends. Use Android’s Network Security Configuration or iOS’s App Transport Security. Disable cleartext traffic.

M6: Inadequate Privacy Controls

Collecting, storing, or transmitting more user data than is necessary for the application’s functionality, or failing to adequately protect personal data.

Excessive permissions requested (camera, contacts, location) beyond functional need.
PII logged to crash reporting services or analytics.
Sensitive data included in device backups.
Screen content cached in the app switcher revealing sensitive information.

Mitigation: Apply data minimization principles. Review all permission requests. Disable backups for sensitive app data. Use FLAG_SECURE to prevent screenshot capture of sensitive screens.

M7: Insufficient Binary Protections

The compiled application binary can be analyzed, modified, and repackaged by an attacker without adequate protections.

No code obfuscation — class and method names remain readable.
No tamper detection — modified APK/IPA continues to function normally.
No anti-debugging measures.
No root/jailbreak detection.
Sensitive strings (API keys, encryption keys) visible in the binary.

Mitigation: Apply ProGuard/R8 obfuscation (Android) or equivalent iOS obfuscation. Implement integrity checks. Add root/jailbreak detection. Encrypt sensitive strings in the binary.

M8: Security Misconfiguration

Insecure defaults or misconfigurations in the application or its hosting environment:

android:debuggable="true" in production builds.
android:allowBackup="true" exposing app data via ADB.
Overly permissive exported components (exported="true" without permission protection).
Insecure Firebase or backend rules permitting unauthenticated reads/writes.
Excessive permissions in the app manifest.

Mitigation: Review and harden AndroidManifest.xml and Info.plist. Disable debug flags in production. Apply network security configuration. Test exported component access with tools like drozer.

M9: Insecure Data Storage

Sensitive data stored on the device in locations accessible to attackers or other apps:

Plaintext credentials in SharedPreferences or NSUserDefaults.
Unencrypted SQLite databases containing PII.
Sensitive files with world-readable permissions.
Data stored in external storage (SD card) accessible by other apps.
Clipboard content with sensitive data.

Mitigation: Use Android Keystore / iOS Keychain for secrets. Encrypt sensitive databases with SQLCipher. Avoid writing sensitive data to external storage. Use EncryptedSharedPreferences (Android).

M10: Insufficient Cryptography

Weak, improperly implemented, or misused cryptography:

Using MD5 or SHA1 for security-sensitive purposes.
ECB mode encryption (reveals data patterns through identical ciphertext blocks).
Hardcoded or predictable encryption keys.
Using java.util.Random instead of SecureRandom for security-sensitive values.
Improper IV (initialization vector) reuse in CBC mode.
Custom cryptography implementations instead of vetted libraries.

Mitigation: Use AES-256 in GCM mode for symmetric encryption. Use RSA-2048+ or ECC for asymmetric operations. Always use SecureRandom for cryptographic key and IV generation. Never roll your own crypto — use platform-provided cryptographic APIs.

OWASP 모바일 Top 10 - 2024

2024년 OWASP 모바일 Top 10은 2016년 목록에서 일부 카테고리를 통합하고 새로운 항목을 추가하여 Android 및 iOS 애플리케이션의 현재 위협 환경을 반영한 중요한 구조 개편을 보여준다.

M1: 부적절한 자격 증명 사용 (Improper Credential Usage)

하드코딩된 자격 증명, 부적절하게 저장된 비밀, 안전하지 않은 인증 자격 증명 전송이 여전히 주요 모바일 취약점이다:

소스 코드나 리소스 파일에 직접 하드코딩된 API 키, 토큰, 패스워드.
SharedPreferences, plist 파일, SQLite 데이터베이스에 평문으로 저장된 자격 증명.
HTTP로 전송되거나 안전하지 않은 위치에 저장된 인증 토큰.
로그 출력이나 에러 메시지에 노출된 자격 증명.

대응 방안: 자격 증명을 하드코딩하지 말 것. 플랫폼 보안 저장소(Android Keystore, iOS Keychain) 사용. 모든 자격 증명 전송에 HTTPS 강제 적용. 인증서 피닝 구현.

M2: 부적절한 공급망 보안 (Inadequate Supply Chain Security)

모바일 애플리케이션은 서드파티 SDK, 라이브러리, 개발 도구체인에 크게 의존한다. 이러한 의존성의 취약점은 앱에 직접적인 영향을 미친다:

악의적이거나 손상된 서드파티 SDK.
알려진 취약점이 있는 구버전 라이브러리.
검증되지 않은 의존성 또는 빌드 도구.
빌드 또는 배포 파이프라인 중 변조.

대응 방안: 모든 서드파티 의존성 감사. 의존성 버전 고정 및 체크섬 검증. 의존성 취약점에 대한 CVE 데이터베이스 모니터링. 소프트웨어 구성 분석(SCA) 도구 사용.

M3: 안전하지 않은 인증 및 인가 (Insecure Authentication and Authorization)

클라이언트 수준에서 우회할 수 있거나 완전히 클라이언트 측 검사에 의존하는 인증 메커니즘:

로컬 코드에서만 이루어지는 인증 결정(예: 클라이언트 로직에서 isAdmin = true).
런타임 계측을 통한 생체 인증 우회.
API 엔드포인트의 손상되거나 누락된 인가 검사.
적절한 서버 측 검증 없는 토큰 기반 인증.

대응 방안: 서버에서 모든 인증 및 인가 강제 적용. 클라이언트 제공 권한 주장을 절대 신뢰하지 말 것. 모든 요청에서 서버 측 토큰 검증.

M4: 불충분한 입출력 검증 (Insufficient Input/Output Validation)

사용자, 다른 앱 또는 네트워크에서 수신한 데이터 검증 부재로 인한 인젝션 공격, 로직 우회, 데이터 손상:

콘텐츠 프로바이더나 딥링크 파라미터를 통한 SQL 인젝션.
안전하지 않은 WebView 설정을 통한 JavaScript 인젝션.
입력 검증 없는 내보내기된 컴포넌트를 통한 인텐트 인젝션.
검증 없이 처리되는 API 응답의 XML/JSON 인젝션.

대응 방안: 모든 신뢰 경계에서 모든 입력 검증. 매개변수화된 쿼리 사용. WebView에 표시되는 모든 데이터 살균. 다른 앱의 데이터를 신뢰할 수 없는 것으로 취급.

M5: 안전하지 않은 통신 (Insecure Communication)

앱과 백엔드 사이에 전송되는 데이터가 적절히 보호되지 않은 경우:

HTTPS 대신 HTTP 사용.
경고 없이 자체 서명되거나 만료된 인증서 수락.
코드에서 인증서 검증 완전 비활성화.
누락되거나 우회 가능한 인증서 피닝.
취약한 TLS 설정(구버전 프로토콜, 취약한 암호 제품군).

대응 방안: 유효한 인증서로 HTTPS 강제 적용. 민감한 백엔드에 인증서 피닝 구현. Android 네트워크 보안 구성 또는 iOS App Transport Security 사용. 평문 트래픽 비활성화.

M6: 부적절한 개인정보 보호 (Inadequate Privacy Controls)

애플리케이션의 기능에 필요한 것보다 더 많은 사용자 데이터를 수집, 저장 또는 전송하거나 개인 데이터를 적절히 보호하지 못하는 경우:

기능적 필요를 초과하는 과도한 권한 요청(카메라, 연락처, 위치).
충돌 보고 서비스나 분석에 기록된 PII.
기기 백업에 포함된 민감한 데이터.
민감한 정보를 드러내는 앱 전환기의 화면 콘텐츠 캐시.

대응 방안: 데이터 최소화 원칙 적용. 모든 권한 요청 검토. 민감한 앱 데이터 백업 비활성화. 민감한 화면의 스크린샷 캡처 방지를 위해 FLAG_SECURE 사용.

M7: 불충분한 바이너리 보호 (Insufficient Binary Protections)

컴파일된 애플리케이션 바이너리를 공격자가 적절한 보호 없이 분석, 수정 및 재패키징할 수 있는 경우:

난독화 없음 — 클래스 및 메서드 이름이 그대로 읽힘.
변조 탐지 없음 — 수정된 APK/IPA가 정상적으로 계속 작동.
안티 디버깅 조치 없음.
루팅/탈옥 탐지 없음.
바이너리에서 보이는 민감한 문자열(API 키, 암호화 키).

대응 방안: ProGuard/R8 난독화(Android) 또는 동등한 iOS 난독화 적용. 무결성 검사 구현. 루팅/탈옥 탐지 추가. 바이너리의 민감한 문자열 암호화.

M8: 보안 잘못 구성 (Security Misconfiguration)

애플리케이션 또는 호스팅 환경의 안전하지 않은 기본값 또는 잘못된 구성:

프로덕션 빌드에서 android:debuggable="true".
ADB를 통해 앱 데이터를 노출하는 android:allowBackup="true".
권한 보호 없이 과도하게 허용적인 내보내기된 컴포넌트.
비인증 읽기/쓰기를 허용하는 안전하지 않은 Firebase 또는 백엔드 규칙.
앱 매니페스트의 과도한 권한.

대응 방안: AndroidManifest.xml 및 Info.plist 검토 및 강화. 프로덕션에서 디버그 플래그 비활성화. 네트워크 보안 구성 적용. drozer 같은 도구로 내보내기된 컴포넌트 접근 테스트.

M9: 안전하지 않은 데이터 저장 (Insecure Data Storage)

공격자나 다른 앱이 접근 가능한 위치에 장치에 저장된 민감한 데이터:

SharedPreferences나 NSUserDefaults의 평문 자격 증명.
PII를 포함하는 암호화되지 않은 SQLite 데이터베이스.
전 세계 읽기 가능한 권한의 민감한 파일.
다른 앱이 접근 가능한 외부 저장소(SD 카드)에 저장된 데이터.
민감한 데이터가 있는 클립보드 콘텐츠.

대응 방안: 비밀을 위해 Android Keystore/iOS Keychain 사용. SQLCipher로 민감한 데이터베이스 암호화. 외부 저장소에 민감한 데이터 쓰기 회피. EncryptedSharedPreferences 사용(Android).

M10: 불충분한 암호화 (Insufficient Cryptography)

취약하거나 부적절하게 구현되거나 잘못 사용된 암호화:

보안 민감 목적에 MD5 또는 SHA1 사용.
ECB 모드 암호화(동일한 암호문 블록으로 데이터 패턴 노출).
하드코딩되거나 예측 가능한 암호화 키.
보안 민감 값에 SecureRandom 대신 java.util.Random 사용.
CBC 모드에서 부적절한 IV(초기화 벡터) 재사용.
검증된 라이브러리 대신 커스텀 암호화 구현.

대응 방안: 대칭 암호화에 GCM 모드의 AES-256 사용. 비대칭 작업에 RSA-2048+ 또는 ECC 사용. 암호화 키와 IV 생성에 항상 SecureRandom 사용. 자체 암호화 구현 금지 — 플랫폼 제공 암호화 API 사용.