Why does Google say my code still has an Intent Vulnerability?

Question

My apps on the Google Play store are affected by the Intent Redirection Vulnerability (see article https://support.google.com/faqs/answer/9267555)

I implemented "Option 2" on the recommended solutions yet the warning is still being reported.

I've tried several different ways of verifying the calling activity, but nothing passes whatever check they're doing.

Here's their recommended solution:

 // check if the originating Activity is from trusted package
 if (getCallingActivity().getPackageName().equals(“known”)) {
   Intent intent = getIntent();
   // extract the nested Intent
   Intent forward = (Intent) intent.getParcelableExtra(“key”);
   // redirect the nested Intent
   startActivity(forward);
 }

And here's my code:

public void onFinish() {
      finish();
      // check if the originating Activity is from trusted package
      if (getCallingActivity() != null &&
          getCallingActivity().getPackageName().equals(
           PerfectCommon.getAppContext().getPackageName())) {
        Intent intent = null;
        // extract the nested Intent
        intent =
           getIntent().getParcelableExtra(BaseActivity.ORIG_ACTIVITY);
        if (intent != null){
            // redirect the nested Intent
            startActivity(intent);
            return;
        }
      }

      Intent newIntent;
        SplashActivity context = SplashActivity.this;
        boolean portrait = PerfectCommon.portraitMode;
        ArrayList<Intent> intents = new ArrayList<>();

        // Create intent stack for next activities to run, starting w/ last
        newIntent = new Intent(context, portrait ? MainActivity.P.class : MainActivity.class);
        newIntent.setData(getIntent().getData());
        intents.add(newIntent);

        startActivities(intents.toArray(new Intent[intents.size()]));
    }

  };

The code should check to see if the calling activity is a trusted source, then use the intent; if it isn't then a different intent is used.

However, when I publish the app on the Google Play store it says that the vulnerability still exists in this bit of code.

This is legacy code and has been working fine up to now, so I prefer not to make large change to get past this, rather just need to pass whatever static checker is being used.

Answer 1

I ran into this problem as well, and it seems that the confusion is caused by two separate problems, combined. First, their suggested implementation for Option 2 is incomplete due to that method being nullable. Second, they reject the entire app update, if ANY of the remaining APKs is considered vulnerable.

1. Google confused us by continuing to reject our app updates, even though we believed we had solved the problem. However, you should pay attention to the versionCode specified in the rejection email -- because they might not be rejecting your latest app version!

In our case, we had an old (vulnerable) app version in production (say, versionCode=100) track, and a first-attempt at fixing the issue in the Beta track (versionCode=150) (see #2 below). When we released a second-attempt at fixing the issue (versionCode=200), Google still sent us the rejection email, but the email still specifically cited versionCode 150, NOT 200.

The reason is because the 150 version was in the beta track, and the 200 version went straight to Production, at 5% rollout (did not replace the Beta version). So technically the 150 version was still accessible in the play store to beta users, and that was the reason for rejecting our 200 update. Once they rejected the update due to the 150 APK being available still, the 200 update was also halted, and we had no choice but to make another updated versionCode.

Once we deactivated the 150 version in the beta track, and re-released the 200 app to production, the rejection went away and we confirmed that the newer version was being distributed to users.

2. Separately, the reason that the first attempt (150) did not resolve the issue, is because of how we were implementing their Option 2 solution. Their solution (which you linked to above)[1]:

if (getCallingActivity().getPackageName().equals(“known”)) {

but they do not consider the fact that getCallingActivity() is nullable. So in our first attempt, we were using:

if (getCallingActivity() == null || getCallingActivity().getPackageName().equals(BuildConfig.APPLICATION_ID)

and that is still vulnerable, hence why our 150 update was rejected. The accepted solution (versionCode 200 in the above example) flipped that logic:

if (getCallingActivity() != null && getCallingActivity().getPackageName().equals(BuildConfig.APPLICATION_ID))

So once we made that change and replaced the app in the beta track, everything was accepted. You can see all currently accessible app versionCodes in the play console by going to Release Management -> App Releases. Every published version in each track will be listed there.