Reputation: 1566
I can call other apps' Activities without problem, including sending them some data and receiving some data back. But I am sending and receiving some sensitive information that could arguably be misused if in the wrong hands. My question is, is this data safe when traveling between appications?
For example, I call an Activity like this:
Intent intent = new Intent("com.my.package.MY_REQUEST_ACTION");
intent.setClassName("com.other.package", "com.other.package.UserActionActivity");
signerIntent.putExtra("INTENT_PASSWORD", "1234");
signerIntent.putExtra("INTENT_COMMAND", "COMMAND_DO_SOMETHING");
signerIntent.setType("text/plain");
startActivityForResult(intent, 0);
And return something in UserActionActivity:
Intent result = new Intent("com.other.package.INTENT_RESULT_DESCRIPTION");
result.putExtra("INTENT_RETURN_RESULT", "...");
result.putExtra("INTENT_RETURN_RESULT2", "...");
setResult(Activity.RESULT_OK, result);
finish();
And so on. But how secure are these extra strings? Do I have to worry about them being accessible to other applications (other than the two involved), either intentionally or through some kind of "hack"? Do I need something like public key encryption?
And is the situation different on rooted systems (i.e. an app with root privileges can, without too much effort, read inter-app communication)?
Upvotes: 2
Views: 597
Reputation: 14755
short answer: it is not safe but it needs some effort for the attacker.
long answer: the transfer can be intercepted by a man in the middle attack:
on unrooted phones:
if you send data to intent.setClassName("com.other.package", "com.other.package.UserActionActivity");
somone can uninstall the original "com.other.package" and install his own "com.other.package" with the same activity that receives the unencrypted data.
For example an attacker can disassemble the original software, add code (that does something with the secret data) and reassemble the code to a new apk (with a different certificate)
On rooted devices: I donot know but i assume it is possible that the "exposed framework" is capable to intercept and redefine android os calls.
Upvotes: 0
Reputation: 1007399
Do I have to worry about them being accessible to other applications (other than the two involved), either intentionally or through some kind of "hack"?
Let's assume for the moment that neither app has been modified by an attacker.
If so, then in principle, the communications that you have established should be private on non-rooted device. In practice, there have been bugs with activity Intent
extras, though none that I know of recently. Of your IPC options, activities are probably the worst choice from a security standpoint, as they have other impacts (e.g., appear in the overview/recent-tasks screen) that increase the likelihood that there is some bug that we have overlooked.
In your code, though, both sides assume that the other app has not been modified. In particular:
Unless you have some security that is not shown, any app on the device can run the code in your first snippet and try to trick the app to return the response in the second snippet.
The code in your first snippet assumes that com.other.package
has not been modified by an attacker.
There are ways to help defend against this (e.g., custom signature
permissions, checking the signature at runtime).
Also, bear in mind that an attacker can find "1234"
without much difficulty.
With regards to the comments advising encryption, given the protocol that you are describing, encryption seems like an unlikely solution. If you have to provide a secret (INTENT_PASSWORD
) in the IPC protocol, then there is no shared secret that both apps would have to use for encryption purposes, and I'm not quite certain what public-key infrastructure you would use to offer public-key encryption here.
And is the situation different on rooted systems (i.e. an app with root privileges can, without too much effort, read inter-app communication)?
Absolutely. On a rooted device, all bets are off. That is not tied specifically to IPC, though.
Upvotes: 1