Expanding the Attack Surface: React Native Android Applications(blog.assetnote.io)
blog.assetnote.io
Expanding the Attack Surface: React Native Android Applications
https://blog.assetnote.io/bug-bounty/2020/02/01/expanding-attack-surface-react-native/
5 comments
I am not sure if this is specific to React Native. In a regular Android application, this information is available in the JSON file. Having permissive credentials on the client is a security gap, no matter the technology.
This article highlights some security errors that are not really related to React Native:
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.
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.
To the author, your blog platform outputs an invalid canonical url for your content. It omits the `blog` subdomain which makes your canonical url point to a 404.
Are you sure? I am not seeing the same behavior.
And I am not seeing anything but a 404.
"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."
"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."
The source in the linked article has canonical link: <link rel="canonical" href="https://assetnote.io/bug-bounty/2020/02/01/expanding-attack-...
Isn't this just security 101? Not sure what it has to do with React Native
Do people really put server keys into clients? I thought the general assumption outside of private servers is to trust nobody.
Many app developers are just people with some programming knowledge trying their luck into the app world, so plenty of engineering best practices never come into consideration.
This is a case for security by default. I’ve messed around with Firebase and Firestore- my experience with auth and security was painful enough that I started to look for alternatives.
ElasticSearch and most of AWS would do well to make Security by Default more commonplace.
ElasticSearch and most of AWS would do well to make Security by Default more commonplace.
I agree.
That is also a reason why although I rant about the capabilities exposed to the NDK, I do appreciate it being locked down.
That is also a reason why although I rant about the capabilities exposed to the NDK, I do appreciate it being locked down.