We want to write an react native app that:
-gets data over bluetooth from devices
-the app should send the data to our api
-it's important that the data is not tempered with or changed in any way
-the app is the only one that can send data to our api
I already read a lot about:
iOS - Keychain Services and
Android - Keystore
on the React Native docs: https://reactnative.dev/docs/security
And SafeNet(Android) or DevieCheck(IOS) (never mentioned on react native docs or articles I read)
What security layers should we use for our use case to make the api most secure and how can I implement them in react native?
We want to use the data from the api to verify the correctness of the same data passed to a smart contract that compares and evaluates them.
CodePudding user response：
YOUR PROBLEM
We want to use the data from the api to verify the correctness of the same data passed to a smart contract that compares and evaluates them.
I congratulate you by having taken the time to understand that the API sitting in front of a blockchain needs to be protected against abuse in order to prevent the blockchain from ingesting unwanted data.
Defending an API it's not an easy task, but if you read carefully all I am about to say I hope that by the end you will have a new perspective on API and Mobile security, that will allow you to devise and architect a robust and secure solution.
WHO IS IN THE REQUEST VERSUS WHAT IS MAKING THE REQUEST
-the app is the only one that can send data to our api
This is a very hard problem to solve, but not an impossible one. To understand why you need to first know the difference between who is in the request and what is making it, otherwise any security you add may not be protecting your API as expected.
The Difference Between WHO and WHAT is Accessing the API Server
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
So, think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
DATA INTEGRITY
-gets data over bluetooth from devices -the app should send the data to our api -it's important that the data is not tempered with or changed in any way
This is also very hard to solve. During the process of collecting the data and sending it to the API the data can be tampered with in several ways.
Manipulate Data with an Instrumentation Framework
-gets data over bluetooth from devices
While the data is being collected form the devices an instrumentation framework can be used to manipulate the data before sending it to the API. A popular instrumentation framework is Frida:
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
So, the attacker would inject a script to listen at runtime to the method that collects the data or to the one that sends the data to the API and then tamper with the data its being sent.
- the app should send the data to our api
Manipulating Data with a MitM Attack
Another alternative is for the attacker to also use Frida to perform a MitM attack to allow a tool like mitmproxy to intercept and modify the request. You can learn how to perform a MitM attack with Frida by reading my article How to Bypass Certificate Pinning with Frida on an Android App:
Today I will show how to use the Frida instrumentation framework to hook into the mobile app at runtime and instrument the code in order to perform a successful MitM attack even when the mobile app has implemented certificate pinning.
Bypassing certificate pinning is not too hard, just a little laborious, and allows an attacker to understand in detail how a mobile app communicates with its API, and then use that same knowledge to automate attacks or build other services around it.
The injection of Frida scripts at runtime allows for almost unlimited possibilities in how to tamper with your data integrity or whatever the mobile app is doing at runtime.
POSSIBLE SOLUTIONS
Secure Storage
I already read a lot about:
iOS - Keychain Services and Android - Keystore on the React Native docs: https://reactnative.dev/docs/security
Using this mechanism is recommended, but you need to be aware that anything that is stored in secure storage will need to be accessed and used by the mobile app at some point, and this is when the attacker can use an instrumentation framework to hook at runtime into the mobile app code. For example, when retrieving a securely stored secret the attacker can extract it to use outside of the mobile app to automate API requests as if they were from the mobile app.
So, use it to make it harder for less skilled attackers to tamper with your mobile app, but always remember that more skilled attackers may find their way around it.
Protecting Data Integrity in the Mobile App
-it's important that the data is not tempered with or changed in any way
To protecting data from being tampered with before it arrives to the API server it's necessary that you employ some solutions, like RASP:
Runtime application self-protection (RASP) is a security technology that uses runtime instrumentation to detect and block computer attacks by taking advantage of information from inside the running software.
RASP technology is said to improve the security of software by monitoring its inputs, and blocking those that could allow attacks, while protecting the runtime environment from unwanted changes and tampering.
The issue of using only RASP is that the API server doesn't have visibility for the ongoing attacks on the mobile app, therefore not able to refuse requests from a mobile app under attack. Also, RASP can be bypassed by skilled attackers with the use of instrumentations frameworks, and the API server will not be aware of this happening, therefore will continue to serve requests, because it doesn't have a mechanism to know that what is making the request is indeed a genuine and un-tampered version of your mobile app.
Defending the API Server
I recommend you to read this answer I gave to the question How to secure an API REST for mobile app?, especially the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution.
One of the solutions proposed is to use a Mobile App Attestation solution that runs outside the mobile device, for example on the cloud, therefore doesn't make client side decisions about the state of the mobile app and device is running on, instead they are done in the cloud service and transmitted to the API server as signed JWT token, that the API server can then used to verify that what is making the request is indeed the genuine and un-tampered version of the official mobile app.
Android Safetynet and iOS Devicecheck
And SafeNet(Android) or DevieCheck(IOS) (never mentioned on react native docs or articles I read)
Using the Android SafetyNet and iOS DeviceCheck runtime protections is for sure a good starting point, but you need to be aware of their scope, limitations and complexity. They can be complemented with a robust Mobile App Attestation solution to give you an higher level of security and confidence that your API server will be able to know when the request is not from what it expects, a genuine and un-tampered version of your mobile app.
Security Layers
What security layers should we use for our use case to make the api most secure and how can I implement them in react native?
I would not be approaching here how to implement it in React, because that is a huge topic and the exact code will depend on your current implementation, but I will summarize here the key points.
Security is always about adding as many layers as you can afford and are required by law, standards and business requirements. To summarize you should consider the following topics:
- Don't hardcode secrets in your mobile app code, but if you really want to do it, at least use Native C code.
- Obfuscate your mobile app code, because this will make it harder to reverse engineer the mobile app code in order to use instrumentations frameworks.
- Use runtime protections in your mobile app code and give preference to the ones that don't make decisions on the client side and allow for the API server to verify that the request is indeed from what it expects, a genuine and un-tampered version of your mobile app, like describe in the Mobile App Attestation I mentioned previously.
- Use certificate pinning to the public key to prevent MitM attacks, but wit h the awareness that it can be bypassed. I recommend you to read the section
Preventing MitM Attacksin this answer I gave to another question where you will learn how to implement static certificate pinning. If you can, try to use instead dynamic certificate pinning to allow to remotely update the pins used by your mobile app. - In your API server you can use rate limiting but do not give back in the headers the info about the rate limit available, because that is like putting the key to your front door under the mat.
- You can use Artificial Intelligence solutions, but be aware that they work in a negative identification model and are prone to false negatives and positives. If using a mobile app runtime protection that lets the API server know when is under attack then the use of AI solutions can be postponed until the API server needs to use other type of clients, like web apps.
This is not an exclusive list of topics you can consider to use in order to secure your mobile app and API server, but are the ones I think that more important for you to focus on.
DO YOU WANT TO GO THE EXTRA MILE?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.