2

We have a mobile app (React and Expo) in which the user is able to provide payment via Stripe. Our implementation uses a WebView which renders HTML and JavaScript content, which in turn pulls in the Stripe JavaScript client and implements the payment process.

We've recently made some modifications to the app architecture and build which has caused an issue on Android in which the WebView is no longer able to access files embedded in the app package. As a temporary workaround we're considering hosting the files on a CDN (probably CloudFront) and loading them in from there.

Would this arrangement be any less secure than accessing the same pages in a browser? It occurs to me that if something caused the app to load the pages from another location (maybe some kind of DNS exploit?) then the affected user could end up with a compromised payment system within what they see as a trusted app.

Is this a risk that should be taken seriously, and if so what measures could/should we take to protect against it?

jlmt
  • 123
  • 2

2 Answers2

1

Your CDN will likely use HTTPS to serve the assets, so if the app is configured correctly (requiring HTTPS with trusted certificate), DNS hijacking/spoofing and other similar malice should at most result in a DoS.

You can use subresource integrity to check the hash of JavaScript files on the client to make sure they match a known good, so any modifications will prevent it from being loaded:

<script src="https://example.com/example-framework.js" integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>
multithr3at3d
  • 12,355
  • 3
  • 29
  • 42
1

Subresource Integrity was designed to solve this problem. You can use subresource integrity to ensure that the supporting files that your system relies on have not been modified or tampered with (or replaced altogether) by a malicious actor.

To use subresource integrity, you specify the expected hash of the supporting file, along with the URL of the supporting file. Then, when the supporting file is loaded, the browser (or, in your case, WebView), checks to verify that the actual hash of the supporting file matches the expected hash that you specified. In case of a DNS exploit like you describe, or some other type of attack where the supporting file has been modified, the hashes won't match, and the supporting file is not loaded.

According to https://www.chromestatus.com/feature/6183089948590080, subresource integrity is supported for WebView 45 and above.

mti2935
  • 19,868
  • 2
  • 45
  • 64