We recently reported on the topic “Why is app security important?.” This is the result of this article series. Today, we are looking at understanding the topic of security risks in apps.
To reduce costs, it’s important to build apps that take security into account from the start of development. This allows errors to be found and fixed earlier, and costly design flaws are discovered that require a complete redevelopment of the application. Applications can be classified according to the level of security built into the solution. However, security checks should be appropriate for the type of application to be developed.
A listing with an exemplary rating can be seen below. This should be adapted to your specific organizational requirements.
Safety was not taken into account in the development. The application may contain common vulnerabilities. Safety tests were not carried out.
Security was considered and security controls were implemented to protect against common vulnerabilities. Secure encryption is implemented and a penetration test has been carried out.
Security controls have been implemented and proven security methods have been applied. Advanced anti-analysis techniques have been used (e.g. B. antispy)
Security test cases were written and integrated into a build system. These are often performed and the risk associated with the application is well known.
Although applications should aim for a high level, in reality not all applications would need this level of security.
What level of security is right for my application?
When thinking about mobile security, three attack scenarios should be considered. The app should try to protect itself from these. In all scenarios, the reputational risk could be as high (or even more so) than the risk to users, and should therefore be taken into account when deciding on appropriate security controls.
- Reputational loss-an example of Facebook: http://dayssincelastfacebookscandal.com
Scenario 1-Device lost or stolen
In this attack scenario, think about the impact on the user if the device is lost or stolen. This boils down to what can be done with the device if physical access is granted. Note that the use of a device lock screen cannot be assumed.
Scenario 2-Harmful software and remote attacks
It is important to consider what can happen if a user unintentionally installs malicious applications on their device. Although the operating system should provide some protections, any malware running with increased (possibly root) permissions can bypass these controls. In addition, there may be vulnerabilities in the operating system that allow malicious applications to bypass these security controls without increasing permissions.
Most mobile operating systems offer applications the ability to share information. Some are explicitly activated by the application developer (e.g. B. IPC endpoints in Android), while others are activated automatically (e.g. B. the clipboard for the copy/paste function). These should be adequately protected so that they cannot be exploited by malware.
This attack category also includes intercepting and/or modifying communications such as network traffic. This can be especially dangerous if there is a vulnerability in the application or operating system that can be exploited by malicious traffic, or if sensitive information is sent through unencrypted channels.
Scenario 3-reverse engineering
The last attack scenario relates to an attacker’s ability to use their own application to identify vulnerabilities that can be used to attack other users or attack server-side applications and infrastructure. Although it is often taught that safety through ambiguity is not a valid technique for securing applications, it should be used as a deep-defense approach-d.H. A more layer of security.
Slowing down an attacker does not remove vulnerabilities from the application, but it may take more time to detect and fix detected bugs after deployment.
It is important to know that this type of security check is important and applied to every version of the application, as a single version without these controls can give an attacker enough information to look for additional vulnerabilities.
It’s unfortunate to say, but in recent years the motivation of the attackers has changed, and these days pure curiosity is rarely the reason mobile applications are under attack. In criminal activity, many attackers search for the low-hanging fruit. An attacker often gives up more time and effort to educate an application, dispensing with a simpler goal.