I am a Developer Advocate for Security in Mobile Apps and APIs at approov.io.
Another passion is the Elixir programming language that was designed to be concurrent, distributed and fault tolerant.
Location
Scotland
Education
Self teached Developer
Work
Developer Advocate for Mobile and API Security at approov.io
If I will be building a fintech related app, what are the securities I need to have (ex. Library, Encryption etc.) for me to have a better level of security for my android and iOS apps
Fintech is one of that use cases were security is mandatory and must be a first class citizen from day zero in any project, thus I need to present my congratulations to you for being so diligent in security.
I know this is vague but Im still searching for best practices for security in mobile apps
A common problem among developers is that they focus to much in just one side of the equation. When building a mobile app you usually need an API server, and the security strategy must be aligned between both sides.
Lets' clear first a usual misconception among developers, that relates to WHO vs WHAT is accessing the API server.
The Who vs What Is Accessing the API Server
For a better understanding off the difference between WHO vs WHAT is accessing your API server, I recommend you to read this section of my article, but I will extract here some lines of it:
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.
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
Public vs Private APIs
Let me tell you here a cruel truth... Private APIs don't exist!!!
No matter if an API doesn't have public accessible documentation or if is is protected by any kind of secret or authentication mechanisms, once is accessible from the Internet is not private any-more, and you even have tooling to help with discover them.
You can read more about it in this article section, and I extract to here some bits:
Now just because the documentation for your API is not public or doesn’t even exist, it is still discoverable by anyone having access to the applications that query your API.
Interested parties just need to set up a proxy between your application and the API to watch for all requests being made and their responses in order to build a profile of your API and understand how it works.
An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers.
So the lesson here is that from the moment you release a mobile app that uses your API, you can consider it to belong now to the public domain, because anyone can reverse engineer it and discover how your "private" API works, and use that to build automated attacks against it.
Mobile Apps Binaries are Public
From the moment you release your mobile app you can consider everything inside of it to belong to the public domain.
Oh but I obfuscated it, I encrypted it and so on and so forth, but you need to bear in mind that this only makes it hard to reverse engineer, not impossible. So you get ride of script kids and seasonal hackers, but you don't get ride from skilled ones that are willing to put the effort and necessary time to reverse engineer your app, provided that they can profit from it, and we have tools to help with the task:
Mobile Security Framework is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing framework capable of performing static analysis, dynamic analysis, malware analysis and web API testing.
Mobile Apps Should be Dumb
A common mistake among developers is to have business logic inside their mobile app...
Yes it's a mistake because once a mobile binary is public it can be reverse engineer.
Instead you should delegate as much as possible all business logic to the API server, because you also have the threat of instrumentation frameworks that can hook into your mobile app during run-time to change the business logic in order to change the outcome of it.
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.
Xposed is a framework for modules that can change the behavior of the system and apps without touching any APKs. That's great because it means that modules can work for different versions and even ROMs without any changes (as long as the original code was not changed too much). It's also easy to undo.
Plus this approach have the benefit of helping you to fix bugs quickly without the need to release a new version of your mobile app, and wait for everyone to update or use a kill switch to force them to update.
In my previous work we used this strategy with a huge success, and this was for e-commerce mobile apps for the UK biggest retailers.
Mobile Apps and Third Part APIs
Try to NEVER access third part services in your mobile app, instead always delegate it to your API server, unless is technically impossible.
Why?
Well access to third part service need some kind of secret, and once mobile app binaries are public your secrets are not secrets anymore, even if you hide them in native C code with JNI/NDK or in the native secure storage, because you can use instrumentation frameworks to hook into you mobile app at runtime and extract that secrets or encryption keys.
The lesson to take here is that as a best practice a mobile app should only communicate with an API server that is under your control and any access to third party APIs services must be done by this same API server you control. This way you limit the attack surface to only one place, where you will employ as many layers of defense as what you are protecting is worth.
The Basic API Security Defenses
Now that you understand the difference between who vs what is accessing your API server you may want to go an read my article about the basic techniques to secure an API:
In this article we will explore the most common techniques used to protect an API, including how important it is to use HTTPS to protect the communication channel between mobile app and API, how API keys are used to identify the mobile app on each API request, how user agents, captchas and IP addresses are used for bot mitigation, and finally how user authentication is important for the mobile security and api security. We will discuss each of these techniques and discuss how they impact the business risk profile, i.e. how easy they are get around.
More Advanced API Security Defenses
You can start by read this series of articles on Mobile API Security Techniques to understand how API keys, HMAC, OAUTH and certificate pinning can be used to enhance the security and at same time how they can be abused/defeated.
Afterwards and depending on your budget and resources you may employ an array of different approaches and techniques to defend your API server, and I will start to enumerate some of the most usual ones.
reCAPTCHA is a free service that protects your website from spam and abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive challenges to keep automated software from engaging in abusive activities on your site. It does this while letting your valid users pass through with ease.
...helps you detect abusive traffic on your website without any user friction. It returns a score based on the interactions with your website and provides you more flexibility to take appropriate actions.
A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to and from a web application. A WAF is differentiated from a regular firewall in that a WAF is able to filter the content of specific web applications while regular firewalls serve as a safety gate between servers. By inspecting HTTP traffic, it can prevent attacks stemming from web application security flaws, such as SQL injection, cross-site scripting (XSS), file inclusion, and security misconfigurations.
User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats. Instead of tracking devices or security events, UBA tracks a system's users. Big data platforms like Apache Hadoop are increasing UBA functionality by allowing them to analyze petabytes worth of data to detect insider threats and advanced persistent threats.
All this solutions work based on a negative identification model, by other words they try their best to differentiate the bad from the good by identifying what is bad, not what is good, thus they are prone to false positives, despite of the advanced technology used by some of them, like machine learning and artificial intelligence.
So you may find yourself more often than not in having to relax how you block the access to the API server in order to not affect the good users. This also means that this solutions require constant monitoring to validate that the false positives are not blocking your legit users and that at same time they are properly keeping at bay the unauthorized ones.
Regarding APIs serving mobile apps a positive identification model can be used by implementing a Mobile App Attestation solution that attests the integrity of your mobile app and device its running on before any request is made to the API server.
Mobile App attestation
Finally if you have the resources you can go even further, by building your own Mobile APP Attestation solution:
The role of a Mobile App Attestation service is to authenticate what is sending the requests, thus only responding to requests coming from genuine mobile app instances and rejecting all other requests from unauthorized sources.
In order to know what is sending the requests to the API server, a Mobile App Attestation service, at run-time, will identify with high confidence that your mobile app is present, has not been tampered/repackaged, is not running in a rooted device, has not been hooked into by an instrumentation framework(Frida, xPosed, Cydia, etc.), and is not the object of a Man in the Middle Attack (MitM). This is achieved by running an SDK in the background that will communicate with a service running in the cloud to attest the integrity of the mobile app and device it is running on.
On a successful attestation of the mobile app integrity, a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud know. In the case that attestation fails the JWT token is signed with an incorrect secret. Since the secret used by the Mobile App Attestation service is not known by the mobile app, it is not possible to reverse engineer it at run-time even when the app has been tampered with, is running in a rooted device or communicating over a connection that is the target of a MitM attack.
The mobile app must send the JWT token in the header of every API request. This allows the API server to only serve requests when it can verify that the JWT token was signed with the shared secret and that it has not expired. All other requests will be refused. In other words a valid JWT token tells the API server that what is making the request is the genuine mobile app uploaded to the Google or Apple store, while an invalid or missing JWT token means that what is making the request is not authorized to do so, because it may be a bot, a repackaged app or an attacker making a MitM attack.
A great benefit of using a Mobile App Attestation service is its proactive and positive authentication model, which does not create false positives, and thus does not block legitimate users while it keeps the bad guys at bay.
Conclusion
Anything that runs on the client side and needs some secret to access an API can be abused in different ways and you must delegate the access to all third part APIs to a API server under your control, so that you reduce the attack surface, and at the same time protect their secrets from public pry eyes.
In my opinion the best solution is defense in depth, by applying as many layers as you can, so that you increase the time, effort and skill-set necessary to by pass all your security layers, thus keeping at bay the script kids and occasionally hackers from abusing your service.
So you should employ has much techniques as possible in both sides of the equation, mobile app and API, like the ones you have learned when reading the articles I have linked: HTTPS, API keys, User Agents, Captchas, Rate Limiting, OAuth, HMAC, Certificate Pinning, Code Obsfuscation, JNI/NDK to hide secretes, WAF, UBA, etc.
In the end, the solution to use in order to protect your API server must be chosen in accordance with the value of what you are trying to protect and the legal requirements for that type of data, like the GDPR regulations in Europe.
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.
I am a Developer Advocate for Security in Mobile Apps and APIs at approov.io.
Another passion is the Elixir programming language that was designed to be concurrent, distributed and fault tolerant.
Location
Scotland
Education
Self teached Developer
Work
Developer Advocate for Mobile and API Security at approov.io
Your Problem
Fintech is one of that use cases were security is mandatory and must be a first class citizen from day zero in any project, thus I need to present my congratulations to you for being so diligent in security.
A common problem among developers is that they focus to much in just one side of the equation. When building a mobile app you usually need an API server, and the security strategy must be aligned between both sides.
Lets' clear first a usual misconception among developers, that relates to WHO vs WHAT is accessing the API server.
The Who vs What Is Accessing the API Server
For a better understanding off the difference between WHO vs WHAT is accessing your API server, I recommend you to read this section of my article, but I will extract here some lines of it:
Public vs Private APIs
Let me tell you here a cruel truth... Private APIs don't exist!!!
No matter if an API doesn't have public accessible documentation or if is is protected by any kind of secret or authentication mechanisms, once is accessible from the Internet is not private any-more, and you even have tooling to help with discover them.
You can read more about it in this article section, and I extract to here some bits:
A proxy tool:
MiTM Proxy
So the lesson here is that from the moment you release a mobile app that uses your API, you can consider it to belong now to the public domain, because anyone can reverse engineer it and discover how your "private" API works, and use that to build automated attacks against it.
Mobile Apps Binaries are Public
From the moment you release your mobile app you can consider everything inside of it to belong to the public domain.
Oh but I obfuscated it, I encrypted it and so on and so forth, but you need to bear in mind that this only makes it hard to reverse engineer, not impossible. So you get ride of script kids and seasonal hackers, but you don't get ride from skilled ones that are willing to put the effort and necessary time to reverse engineer your app, provided that they can profit from it, and we have tools to help with the task:
Mobile Security Framework
Mobile Apps Should be Dumb
A common mistake among developers is to have business logic inside their mobile app...
Yes it's a mistake because once a mobile binary is public it can be reverse engineer.
Instead you should delegate as much as possible all business logic to the API server, because you also have the threat of instrumentation frameworks that can hook into your mobile app during run-time to change the business logic in order to change the outcome of it.
Frida
xPosed
Plus this approach have the benefit of helping you to fix bugs quickly without the need to release a new version of your mobile app, and wait for everyone to update or use a kill switch to force them to update.
In my previous work we used this strategy with a huge success, and this was for e-commerce mobile apps for the UK biggest retailers.
Mobile Apps and Third Part APIs
Try to NEVER access third part services in your mobile app, instead always delegate it to your API server, unless is technically impossible.
Why?
Well access to third part service need some kind of secret, and once mobile app binaries are public your secrets are not secrets anymore, even if you hide them in native C code with JNI/NDK or in the native secure storage, because you can use instrumentation frameworks to hook into you mobile app at runtime and extract that secrets or encryption keys.
The lesson to take here is that as a best practice a mobile app should only communicate with an API server that is under your control and any access to third party APIs services must be done by this same API server you control. This way you limit the attack surface to only one place, where you will employ as many layers of defense as what you are protecting is worth.
The Basic API Security Defenses
Now that you understand the difference between who vs what is accessing your API server you may want to go an read my article about the basic techniques to secure an API:
More Advanced API Security Defenses
You can start by read this series of articles on Mobile API Security Techniques to understand how API keys, HMAC, OAUTH and certificate pinning can be used to enhance the security and at same time how they can be abused/defeated.
Afterwards and depending on your budget and resources you may employ an array of different approaches and techniques to defend your API server, and I will start to enumerate some of the most usual ones.
You can start with reCaptcha V3, followed by Web Application Firewall(WAF) and finally if you can afford it a User Behavior Analytics(UBA) solution.
Google reCAPTCHA V3:
WAF - Web Application Firewall:
UBA - User Behavior Analytics:
All this solutions work based on a negative identification model, by other words they try their best to differentiate the bad from the good by identifying what is bad, not what is good, thus they are prone to false positives, despite of the advanced technology used by some of them, like machine learning and artificial intelligence.
So you may find yourself more often than not in having to relax how you block the access to the API server in order to not affect the good users. This also means that this solutions require constant monitoring to validate that the false positives are not blocking your legit users and that at same time they are properly keeping at bay the unauthorized ones.
Regarding APIs serving mobile apps a positive identification model can be used by implementing a Mobile App Attestation solution that attests the integrity of your mobile app and device its running on before any request is made to the API server.
Mobile App attestation
Finally if you have the resources you can go even further, by building your own Mobile APP Attestation solution:
Conclusion
Anything that runs on the client side and needs some secret to access an API can be abused in different ways and you must delegate the access to all third part APIs to a API server under your control, so that you reduce the attack surface, and at the same time protect their secrets from public pry eyes.
In my opinion the best solution is defense in depth, by applying as many layers as you can, so that you increase the time, effort and skill-set necessary to by pass all your security layers, thus keeping at bay the script kids and occasionally hackers from abusing your service.
So you should employ has much techniques as possible in both sides of the equation, mobile app and API, like the ones you have learned when reading the articles I have linked: HTTPS, API keys, User Agents, Captchas, Rate Limiting, OAuth, HMAC, Certificate Pinning, Code Obsfuscation, JNI/NDK to hide secretes, WAF, UBA, etc.
In the end, the solution to use in order to protect your API server must be chosen in accordance with the value of what you are trying to protect and the legal requirements for that type of data, like the GDPR regulations in Europe.
Going the Extra Mile
OWASP Mobile Security Project - Top 10 risks
frida is powerful tools. If you can please make an article or tutorial about how to hook or how to use it.
Yes its a very powerful tool, and its in my TODO list to do an article with it ;)