Which choice below accounts for the Intent extra injection vulnerability in Android, and what validation must developers perform before using Intent extras in security-sensitive decisions?
- A.Intent extra injection applies to implicit Intents only, and an explicit Intent naming a fully qualified component is immune (the resolver binds the target before the extras bundle is ever read); developers must validate extras on every implicitly reached component, and treat an explicitly addressed component like a trusted caller for authorization decisions
- B.Intent extras are signed by the PackageManager at dispatch time, and the receiving component verifies that signature before the bundle is unmarshalled (a check performed inside Intent.getExtras); a sender has no room to tamper with a key named isAdmin, and developers need only confirm the expected key is present on every request the component handles
- C.An exported component that reads Intent extras and uses them for authorization (e.g., extras.getBoolean('isAdmin')) can be exploited by any caller who constructs an Intent with the expected key set to an attacker-chosen value; developers must never trust Intent extras for authorization - use server-side or cryptographic verification instead