Expanding the Attack Surface: React Native Android Applications(blog.assetnote.io) |
Expanding the Attack Surface: React Native Android Applications(blog.assetnote.io) |
1. Firebase permissions
That is a problem of a badly configured server, in firebase you need to write some rules that are less permissive as possible, making possible only to read what the user really needs (for example it's own data and the data that is truly public), same for writing.
2. Debug files in the APK
The map file should not be in the APK (unless it's an internal-only debuggable APK), webpack/gulp can be configured to not produce that file when the target is production.
If you use tools that collect errors like Sentry, you can upload the map file to their servers and avoid releasing it.
It will not stop the attacker from obtaining your API_KEY but it will make it harder (security through obscurity).
Both problems are not exclusive to React Native but are shared to any app/web-app that uses firebase.
"https://assetnote.io/bug-bounty/2020/02/01/expanding-attack-...
Hm, perhaps the link has been updated by now? I am reading from Feedly on Android, and the link is the bad one I quoted. But from here on news.ycombi, if I click the link at the top, I get a valid link that begins with "blog."
ElasticSearch and most of AWS would do well to make Security by Default more commonplace.
That is also a reason why although I rant about the capabilities exposed to the NDK, I do appreciate it being locked down.