Android Security: Kotlin Coding Practices & Intent Handling

Posted on Jul 25, 2025 in Computers

🔧 Kotlin & Android Coding Terms You Must Know

• ?.let {}: Kotlin null-safe scope function. Prevents crashes if an object is null; not a security check.

• getCallingPackage(): Identifies the app that sent an intent. Use this to verify the intent source.

• checkCallingOrSelfPermission(): Checks if a permission is declared. Does not verify the actual identity of the sender.

• resolveActivity(intent, 0): Checks if the intent can be handled. Prevents app crashes, but not a security check.

• putExtra() / getStringExtra(): Used to send/get data via intents. Can be spoofed if not validated.

• android:exported="true": Allows external apps to access a component. Must be paired with permissions or signature checks.

• android:permission="...": Declares the required permission for component access. Best practice for services and receivers.

• Explicit Intent: Targets a known component. Safer, no hijacking.

• Implicit Intent: System matches via filters. Can be hijacked or intercepted.

• BroadcastReceiver: Listens for system/app events. Can be abused if exported & unprotected.

• Service: Background task handler. Must verify who sends commands (onStartCommand()).

🔒 Encryption & Authentication Distinctions

• FDE (Full-Disk Encryption): Encrypts all at once with a single key. Unlocks everything at once; no file-level control.

• FBE (File-Based Encryption): Encrypts each file with its own key. Allows selective access (e.g., alarms before unlock).

• HMAC: Ensures integrity, not confidentiality. Cannot encrypt or decrypt data.

• AES: Symmetric encryption for data protection. Used to encrypt/decrypt entire payloads.

• JWT: Signed token used in authentication. Stateless, hard to revoke without server state.

• Nonce: One-time-use number. Stops replay attacks.

🛡️ Secure Intent Handling Rules

• Always verify:

  • getCallingPackage() or getCallingUid()

  • Permissions via checkCallingOrSelfPermission()

  • Whether the intent can be handled via resolveActivity()

• Secure intent pattern example:

incomingIntent?.let { intent ->
if (packageManager.resolveActivity(intent, 0) != null &&
checkCallingOrSelfPermission("com.example.SAFE_PERMISSION") == PackageManager.PERMISSION_GRANTED &&
getCallingPackage() == "com.trusted.app") {
processIntent(intent)
}
}

• Don’t:

  • Rely on ?.let {} for security

  • Trust extras without checking the source

  • Export components without protection

⚠️ High-Risk Misconceptions to Avoid

• ❌ HMAC encrypts data → HMAC only checks integrity

• ❌ Kotlin let{} validates sender → It just checks for null

• ❌ Implicit intents are always safe → They can be hijacked by any app with a matching filter

• ❌ A signed JWT cannot be reused → It can, unless short-lived or bound to a nonce

• ❌ Logging tokens to Logcat is fine → Logcat can be accessed on rooted/debug builds

• ❌ Certificate pinning is optional → Without it, MITM with a rogue CA is possible

• ❌ Bootloader fails → kernel loads anyway → Secure boot halts the process on any failure

• ❌ RASP replaces other layers → It complements OS/hardware protections, doesn’t replace them

🧠 Biometric & Hardware Memory Aids

• TEE (Trusted Execution Environment): Handles biometric processing and secure key storage.

• HSM (Hardware Security Module): Offloads crypto, prevents physical key extraction.

• Secure Boot Chain: Must validate Bootloader → Kernel → System.

• MAC Address Randomization: Prevents device tracking via Wi-Fi/Bluetooth.

📱 Intent-Related Attacks to Know

• Intent Spoofing: A fake app sends a malicious intent to a component.

• Intent Hijacking: Another app intercepts an intent meant for your component.

• Broadcast Injection: A malicious app sends a broadcast your app reacts to.

• Service Hijack: A malicious app invokes exported service methods (e.g., deleteUser()).

🧪 Replay Attack Mitigation Checklist

• ✅ Use short token lifetimes

• ✅ Include a nonce or timestamp

• ✅ Store tokens in hardware-backed keystore

• ❌ Don’t store in plain text

• ❌ Don’t trust tokens after logout or timeout

✅ Key Kotlin Coding Lessons

1. Validate All Incoming Intents

incomingIntent?.let { intent ->
if (packageManager.resolveActivity(intent, 0) != null &&
checkCallingOrSelfPermission("com.example.SAFE_PERMISSION") == PackageManager.PERMISSION_GRANTED &&
getCallingPackage() == "com.trusted.sender") {
processIntent(intent)
}
}

• Defends against spoofed intents, broadcast injection, and hijacking.

2. Avoid Sending Sensitive Data via putExtra() Unless Secured

val intent = Intent(this, DashboardActivity::class.java).apply {
putExtra("session_token", sessionToken) // Risky if not encrypted or validated
}

• Extras can be read by malicious apps if intercepted.

3. Explicit vs. Implicit Intents

// Explicit (Safe) val intent = Intent(this, TargetActivity::class.java) startActivity(intent) // Implicit (Risky) val intent = Intent(Intent.ACTION_VIEW, Uri.parse("https://nyu.edu")) startActivity(intent)

• Use explicit for internal navigation.

• Validate implicit before processing.

🧱 Intent Verification Checklist

• Confirm intent is not null.

• Use resolveActivity() to check if the component exists.

• Use checkCallingOrSelfPermission() to check permissions.

• Use getCallingPackage() or getCallingUid() to verify the sender.

🛡️ Signature-Level Permissions

• Only apps signed with the same certificate can access the component.

🔐 Token Handling Best Practices

• Store tokens in Android Keystore or EncryptedSharedPreferences

• Never log tokens (Log.d(), println())

• Use short-lived and refreshable tokens

📡 Secure BroadcastReceiver Pattern

class AlarmReceiver : BroadcastReceiver() {
override fun onReceive(context: Context, intent: Intent) {
if (intent.getStringExtra("msg") != null &&
context.checkCallingOrSelfPermission("com.example.ALARM_PERMISSION") == PackageManager.PERMISSION_GRANTED) {
showAlarm(intent.getStringExtra("msg")!!)
}
}
}

• Add the corresponding android:permission in the manifest to protect access.

⚠️ Common Mistakes to Spot on the Exam

• Using intent.getStringExtra() without checking the sender → Spoofable

• Logging tokens or user data with Log.d() → Sensitive info leak

• Storing tokens in plain SharedPreferences → Easily accessible

• Calling startActivity() on a null intent → App crash risk