Weak and insecure apps can create a whole lot of chaos, not to mention embarrassment, for those organisations that release them. Take for instance the Iowa Democratic Caucuses voting app. Due to its shortcomings, the count for the state’s Democratic nomination for US president was significantly delayed. That is despite Troy Price, the Iowa Democratic Party Chairman unequivocally stating: “If there is a challenge, we’ll be ready with a backup and a backup to that backup and a backup to the backup to the backup.”
That this belief was not “backed up” by reality simply highlights a long history of organisations confidently releasing untested software, only to end up with egg on their faces because of poor security.
In the rush to get apps and websites out the door it is only natural to focus on functionality, yet security has to be just as equal a consideration right from the start of the development cycle. Therefore, below we have compiled four application security themes all organisations should take note of.
How what’s “best” could be “worst” for security
Apps and websites that feature unprotected code are an open invitation to bad actors. It enables them to explore how the asset was made, providing them with a detailed schematic of how it can be exploited.
Bad actors can read the code of apps that don’t have the appropriate security features by simply using any of the free or paid-for tools on the market, such as IDA Pro, Binary Ninja, and Hopper. Using this information, they can then reverse engineer the asset to create their own rip-off or find hidden elements that were only meant for developers’ eyes.
For instance, it’s common practice for developers to embed credentials into the code of the apps and websites they are working on. They do this to simplify login procedures and reduce friction when moving from one workflow to another. However, these keys and tokens can effectively be accessed by anyone reading the code in clear text. Obviously, while this might be a good practice for private or internal apps and sites, it’s a huge no-no for public facing software particularly if it enables access to sensitive data. Developers should avoid this practice all together to avoid “leaving their keys in the front door”.
We’re only human after all
As the great philosopher Alexander Pope once said, “To err is human”, which applies just as much to coders as to anybody else. Even the best coding will have some errors and any errors in coding on a website or app will create vulnerabilities that can be exploited. As such, it is vital to thoroughly test code on an ongoing basis. Nowhere is this more true than for DevOps where the code changes all the time. Organisations should deploy security measures to help negate any mistakes that get through the testing net.
Where many departments are involved in creating an app, several mistakes can creep into the process and remain if someone does not have overall accountability. To avoid this, firms developing apps need to ensure that they designate an employee or team who is responsible for, and has oversight of, how security is being implemented across a DevOps process. This is the beginning of the transition to DevSecOps and helps an organisation ensure that security is considered throughout the plan, build and run lifecycle.
Another element of human error that needs to be accounted for is that once they are out in the wild, apps and websites can be misused, albeit unintentionally, by users. Developers should look to build controls into apps that mitigate activities such as workarounds, installing unapproved apps, mistreating data and flouting acceptable use policies, as all pose a threat to the integrity of an organisation’s IT network and assets. Beyond production, Developers should include telemetry helping to identify emerging attacks once their application in the wild. This is critical feedback to the development process as it informs the team how real-world attacks attempt to exploit their application.
Web and API exploits
Another threat that organisations should be on high alert for are API vulnerabilities. Application Programming Interfaces (APIs) help to provide a bespoke experience for users by enabling apps to dynamically react to how they are being used. They can do this by letting the app interact more directly with the back-end web application and its associated infrastructure and databases. Vulnerabilities in the API enable hackers to directly exfiltrate huge amounts of data in one go.
To counter these threats, organisations need to implement monitoring and controls to ensure their apps and websites are secure end-to-end. Organisations shouldn’t stop there though. Unknown APIs are a real problem and the enterprise should develop an ability to identify and ultimately manage these shadow APIs that can exist in off-the-shelf applications.
How tools can be used by cybercriminals as weapons
Unfortunately for those looking to secure apps and websites there are a whole raft of widely available tools that enable attackers to easily hack them. Many of these are simple to use and supported by a wealth of documentation and online communities.
Take Frida for instance. This easy-to-use toolkit enables developers, and hackers, to orchestrate dynamic code and data injection into native apps. With Frida it is possible to trace private application code, hook any function and spy on crypto APIs without the need for source code.
Then there is the game hacking tool Game Guardian, which can modify key player stats such as health or money. In a market worth some $120 billion, securing game integrity should be a top priority for studios looking to protect their brand, revenues and the player experience.
Elsewhere, Magisk enables hackers to alter Android devices and apps by providing root access and negating the need to tamper with partitions. Further, these modifications are undetectable by a majority of system integrity verification solutions including Google SafetyNet API.
Taking stock of app and website security
Bearing these themes in mind security needs to be at the heart of any website or app development. To achieve this, organisations need to ensure that code works in the same way as it was developed, without causing significant delay to the DevOps cycle. Failure to do this could create significant vulnerabilities that enable hackers to compromise the security of your assets and wreak havoc.
Chad McDonald, VP of Customer Experience, Arxan