In-App Protection Is Not Enough

If the essential security layer is flawed, you're toast

Blog In-App Protection Is Not Enough

| 5 min read

Contact us

Allow us to start this blog post with a simple petition. Imagine you bought some stuff, including a box of donuts, and brought them for a retreat in your country house. You hurry to store most of the stuff, as you must take off asap to pick up some of your guests. Since there is no space left in the fridge, and you have no time to go and look for the zip bags in your car, you decide to place the box of donuts inside a plain plastic bag and leave them on the kitchen counter. "That should do," you think. Hours later, you're back with your guests and, as you look in the kitchen for something to offer them, you see a signal. An ant, several, lots. They are all surrounding the bag with the donuts. Had you inspected the bag beforehand, You could have seen a little hole.

"I would have used two bags to protect them better!" a reader might argue. Possibly. But, as anyone who's had an ant problem in their kitchen would attest to, ants always find their way to where they're not wanted, if given enough time. Let's get some things clear, though. We're not supposing that the zip bag is infallible. There might be other antagonists at your country house with more strength to power through piercing the different layers securing the donuts. Our point is that combining these solutions might have resulted in a more successful prevention than what we saw in this hypothetical.

Doesn't all of the above remind us of the posture that some have adopted towards cybersecurity? Adding layer upon layer –each imperfect– as defense, without turning to the most appropriate solution, and rather confident that that should be enough. Is this the case with you and your team?

Security through obscurity

Within the sheer amount of offers in the cybersecurity market, there are solutions that integrate controls to protect apps as the latter run. This is the case of a category that Gartner calls "in-app protection."

In-app protection is the type of solution that introduces functions in its clients' software products to make them more resistant to cyberattacks. Some of those defenses, offered directly or from third parties, are the following:

  • Runtime application self-protection (RASP): It is a function that monitors the app (e.g., its inputs and outputs) and notifies the user or closes the app if it finds an insecure pattern.

  • Man-in-the-middle (MITM) attacks prevention: It is a set of functions like detection of malicious proxies, certificate pinning (see below), URL allowlisting/whitelisting, etc., that work to prevent hackers from intercepting communications between two parties.

  • Detection of jailbroken or rooted devices: It is a function that notifies or prevents the execution of the app in devices where there's access to the root user.

  • Secure certificate pinning: This is a function that forces the use of matching SSL for communications between the app and a server. This is to avoid hackers detour communications to a malicious server with fake certificates.

  • Code obfuscation: It is a function that makes source code hard for a hacker to interpret or for an static code analysis (SAST) tool to scan in search of vulnerabilities.

  • Anti-reverse engineering techniques: It is a function to block the tools hackers use for identifying software components, functions and relationships, and ultimately, the product's business logic, without initial access to source code.

The above are additional security measures for apps. They are recommended by some, e.g., the OWASP Mobile App Security (MAS) project, for apps whose owners are organizations with an urgent need to safeguard their assets and business logic. However some solutions in the market promise to alleviate the dev team's workload, to enable speedy deployments into production, and, something quite attractive, to protect apps with no need to write code. Such offerings may be interpreted by clients as enough measures to keep apps secure, as if that was a way to remediate their vulnerabilities.

We need you and your team to learn and understand this mantra: "Enabling security controls is not remediating". Precisely, the security features we mentioned in the previous lines are defenses that help increase the complexity to exploit a vulnerability or understand the code. Remediation, on the other hand, is the elimination of a characteristic of a software product's security posture, configuration or design that renders it open to exploitation.

Maybe some of the teams that delegate security wholly to in-app protection don't need the above explanation. They are satisfied with the armor they procured for their apps and don't see remediation as necessary, while perceiving it as extremely expensive. But hiding software vulnerabilities behind layers of defenses without any intention to fix them is an unfortunate decision.

You are just buying time

Fluid Attacks' hacking team has experience bypassing controls including the ones mentioned in this post. That is not necessarily due to RASP misconfigurations, or insufficient obfuscation, but rather to hackers being able to always bypass these controls, if given enough time. Behind these controls hackers find back-ends with vulnerabilities ready to be exploited. Another possibility is they can obtain previous software versions with no in-app protection and launch their attacks against them.

Excessive confidence in security controls may eventually allow for security breaches which can mean losses of information, money and reputation.

Get started with Fluid Attacks' Security Testing solution right now

Don't comply only with resilient security

We stress on this: In-app protection defenses are additional measures. They do not replace security requirements your app's source code and configurations need to comply with. That's the same OWASP MAS says. The latter project recognizes the importance of security controls as resilient security and calls them an extra layer that reinforces the other two: an essential security layer and an advanced security layer.

Essential security requires your mobile app to use preexisting, tested and secure cryptographic mechanisms, protect network traffic, use inter-process communication mechanisms securely, have no vulnerable third-party dependencies, among other requirements. All this must be verified continuously and fixed when an issue of noncompliance is detected. It matters not how good you think your resilient security is. We list the risks to mobile apps elsewhere along with the role that security testing plays in identifying them.

Regarding advanced security, compliance with the corresponding set of requirements are strongly advised if your app handles high-risk sensitive data. Some security measures in this layer include usage of secure authentication mechanisms, identity pinning, and secure update mechanisms.

Remediating is safer and faster each time

We have defined what you should recognize as additional and what is essential. We know that it's the security of your app's code and configurations what ultimately stands between a malicious threat actor and the integrity, confidentiality and availability of your business' and your end users' information. Undoubtedly, an important chunk of your team's efforts needs to focus on identifying and fixing security flaws while resilient security measures buy you some time.

Not only is it safer to remediate vulnerabilities, but it is a task that tends to gain velocity. When your development team takes responsibility for the app's security they can acquire knowledge about vulnerabilities and, through timely feedback, they can learn to write secure code. This translates into fewer instances of at least one type of vulnerability and less rework and time to remediate. In fact, our latest report, State of Attacks 2023, we found that, if a team breaks the build, preventing vulnerable code from being deployed into production, they take less time to remediate detected vulnerabilities than when they do not break the build.

Fluid Attacks tests your app's security thoroughly and helps fix flaws

As mentioned, Fluid Attacks has a hacking team. It's a highly qualified team that evaluates the security of software products continuously alongside AppSec testing tools developed by Fluid Attacks. Such a combination results in speed and precision. Thanks to Fluid Attacks, you can learn about vulnerabilities in your essential, advanced and resilient security, as well as obtain remediation recommendations from an expert team.

Find vulnerabilities in your app before a cybercriminal does. Contact us.

Subscribe to our blog

Sign up for Fluid Attacks' weekly newsletter.

Recommended blog posts

You might be interested in the following related posts.

Photo by FlyD on Unsplash

Software supply chain management in financial services

Photo by Robs on Unsplash

Consequential data breaches in the financial sector

Photo by Towfiqu barbhuiya on Unsplash

Data protection in the financial sector, tips and more

Photo by Christian Wiediger on Unsplash

The need to enhance security within the fintech sector

Photo by Claudio Schwarz on Unsplash

Is your financial service as secure as you think?

Photo by mitchell kavan on Unsplash

Bringing the zero trust model to life

Photo by Brian Kelly on Unsplash

We need you, but we can't give you any money

Start your 21-day free trial

Discover the benefits of our Continuous Hacking solution, which hundreds of organizations are already enjoying.

Start your 21-day free trial
Fluid Logo Footer

Hacking software for over 20 years

Fluid Attacks tests applications and other systems, covering all software development stages. Our team assists clients in quickly identifying and managing vulnerabilities to reduce the risk of incidents and deploy secure technology.

Copyright © 0 Fluid Attacks. We hack your software. All rights reserved.