Maintain control over WebView content

[TheDauntless]

I propose to add a check to make sure that only trusted content can be loaded in a WebView. Let's say you are using a webview, you often wouldn't want the user to navigate away from your controlled pages/domains. Newly loaded pages could be malicious, exploit webview bindings and phish the user.

The closest one that is related is 6.4, but doesn't quite cover the phishing aspect, and it's angle is a bit different:

6.4 If native methods of the app are exposed to a WebView, verify that the WebView only renders JavaScript contained within the app package.

The MSTG also doesn't cover this aspect, since there is only one mention of shouldOverrideUrlLoading and it's in a section about XSS.

So my proposition:

6.12: Restrict content of WebViews to trusted or local resources if necessary.

This could be a level1 and level2, but maybe something extra is needed to fine-tune the scope more.

[cpholguera]

I guess this would be the place for the content of this new MSTG PR:

https://github.com/OWASP/owasp-mstg/pull/1655/files

I'd say it's wrongly located now. It talks about SafeBrowsing in the section about "Testing JavaScript Execution in WebViews"

[TheDauntless]

Yes, that was my initial trigger. I didn't notice where the content was added, but you are correct that it's not in the right place currently.

So proposal is to add the requirement and move the PR to a new segment.

[cpholguera]

@TheDauntless What if MSTG-PLATFORM-2 is already covering this as @A-AFTAHI suggests.

All inputs from external sources and the user are validated and if necessary sanitized. This includes data received via the UI, IPC mechanisms such as intents, custom URLs, and network sources.

I think as you comment above "you often wouldn't want the user to navigate away from your controlled pages/domains" can be considered under this requirement, right? At the end, this is also "inputs from external sources and the user" and a way to protect these concrete case is via SafeBrowsing.

[A-AFTAHI]

@cpholguera I think the right thing to do is to add a paragraph in the MSTG-PLATFORM-2 after https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05h-Testing-Platform-Interaction.md#testing-for-fragment-injection-mstg-platform-2 . the new section will cover the use of SafeBrowsing to control WebView Content. Intitled : Control WebView content with SafeBrowsing (MSTG-PLATFORM-2)

[TheDauntless]

I would argue that this is an 'internal input'. The use case I'm thinking of is that you (fe) include your FaceBook page in a webview in your app, and don't realise that you don't have full control over it. Someone might post a link on that page to a phishing page, and the user might click it.

I interpret the MSTG-PLATFORM-2 as everything I enter into the application/send to the application, and not things I do that are part of the application. (I hope I'm making sense :) )

[A-AFTAHI]

What i would call 'internal input' is the initial URL you defined for your application to load. But the other links the user might click-on or the redirections that might happen i see this as external to the app.

[commjoen]

I have a bit of doubts about this requirement... because a webview is often used to load content from various domains. So what would be "trusted" in that sense?

[cpholguera]

I agree with Aftahi on the last comment. I also see the first URL loaded by the app as the internal input and both the URL that the user might enter (if it's even possible, normally it shouldn't) as well as all links loaded by an arbitrary page as "inputs from external sources and the user" which should be "validated and if necessary sanitized" as stated in MSTG-PLATFORM-2. e.g. by leveraging SafeBrowsing or restricting navigation by using the overrideurlloading method which will check the domain.

So I really think that the proposed requirement fits in this situation. Therefore we can keep or enhance MSTG-PLATFORM-2 if necessary. Actually, the requirement says "This includes... Network sources" wouldn't this be it?

What do you think?

[A-AFTAHI]

I think that Keeping MSTG-PLATFORM-2 is mandatory. Therefore we can add the new suggested requirement if u want.
For the MSTG i guess as suggested earlier the best option is to move the PR to enhace MSTG-PLATFORM-2 coverage.

[TheDauntless]

I also propose to have a separate requirement for this. The PLATFORM-2 one is pretty clear in what it wants to accomplish, and the solution to the webview issue is very specific and different from those use cases.