Implement permissions on exported component.

[ernestoA92]

Is your feature request related to a problem? Please describe.

In our application we started using SonarCloud for monitoring and checking our code quality. The first run we got the next security alert/issue:

---

Title: Implement permissions on this exported component.

Where:

<activity android:name="com.linusu.flutter_web_auth_2.CallbackActivity" android:exported="true">
   <!-- Implement permissions on this exported component. -->
    <intent-filter android:label="app-name">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="scheme" />
    </intent-filter>
</activity>

Description:
Once an Android component has been exported, it can be used by attackers to launch malicious actions and might also give access to other components that are not exported.

As a result, sensitive user data can be stolen, and components can be launched unexpectedly.

For this reason, the following components should be protected:

• Providers
• Activities
• Activity-aliases
• Services

To do so, it is recommended to either set exported to false, add android:readPermission and android:writePermission attributes, or add a <permission> tag.

References:

• developer.android.com - Implementing content provider permissions
• Mobile AppSec Verification Standard - Platform Interaction Requirements
• OWASP Mobile Top 10 2016 Category M1 - Improper platform usage
• OWASP Mobile Top 10 2016 Category M2 - Insecure Data Storage
• MITRE, CWE-926 - Improper Export of Android Application Components

---

Describe the solution you'd like

We did a research on our side and we found that:

We are using oauth2_client | Flutter Package, which uses flutter_web_auth_2 | Flutter Package. The docs says it’s necessary to add the following to the AndroidManifest.xml:

<activity android:name="com.linusu.flutter_web_auth_2.CallbackActivity" android:exported="true">
    <intent-filter android:label="app-name">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="scheme" />
    </intent-filter>
</activity>

This is the cause of the issue, because of android:exported="true". If android:exported="true" is removed the app does not build. Adding android:permission, as suggested by SonarCloud, makes the callback not work without updating the callers of the CallbackActivity.

I dug deep into this but could not find a solution. I think the solution is still to add a tag and then update the callers to start the intent with the permission (according to here under “Securing Activities”). The problem is updating the callers - I was not able to find them. The oauth2_client library uses flutter_web_auth_2, which uses method channels that on Android does intent.launchUrl(context!!, url). I don’t know where the callback activity is called.

This is a Medium severity issue for our app, and it might compromise the data of our customers and the security of our organisation.

Additional context

More info can be found here:

• Bitwarden disclosed on HackerOne: Vulnerable exported broadcast...
• oversecured published a vulnerability from ██████ on HackerOne:...

[ThexXTURBOXx]

Thanks for the detailed report. I will take a look at this during the next few days. I am not quite sure what the best way of handling this is or if it is even a false warning.

[thundering-herd]

Any updates on this @ThexXTURBOXx ?

[ThexXTURBOXx]

Right now I am still unsure about this since I believe it is a false warning. At least I was not able to abuse it in a malicious way.
I believe it is because of the way this has been implemented internally in this package.
"Malicious" data can only be injected if the authenticate function has been called, since otherwise no data will be returned to the app.
If you believe that I am mistaken, please provide me with a MWE that somehow abuses this behavior and I will make sure that it is not possible to abuse this anymore

[ThexXTURBOXx]

Another small thing: This should not affect this package itself and would only be an issue about documentation since the package does not need changing.
If you think this issue affects your app, you only need to change your entry in the manifest. In that case, just let me know how you were able to solve it at your end and I will adjust the Readme.