As a user of hundreds of web-enabled applications, I often take security for granted. I fall into the trap of thinking that as long as I follow some rule-of-thumb guidelines, I remain safe. I don’t transmit sensitive information over insecure networks, I don’t give passwords to strangers, and I don’t reply to Nigerian princes (unless they’re super convincing). However, common sense is not a fool-proof security strategy.
Developers can and should do much more than rely on the wisdom of users when building their mobile applications, especially those that require access to sensitive personal or financial information. Unfortunately, developers often have to prioritize speed over security.
Introducing OWASP: A Hive of Security Measures
When it comes to security, wrapping everything in HTTPS is just the bare minimum. There’s much more that can be done, and the non-profit Open Web Application Security Project (OWASP) catalogs these security measures to promote better practices among the development community.
Beginning in 2014, OWASP added mobile applications to their focus. Although similar to their web counterparts, mobile applications rely on new and ever-evolving platforms that feature unique risk factors. For one, mobile apps remain vulnerable to breach even when idling in the background due to their persistent on-device presence. And the devices in question are far more ubiquitous than their heavier, computer-screened browser-powered counterparts (try saying that five times fast).
Smartphones roam freely in space and often in public and, therefore, are vulnerable to in-person social hacking techniques. These discrepancies between mobile and web applications inspired OWASP to craft a unique list of 10 security risks specifically for mobile software.
Let’s explore each vulnerability, how your mobile offering can best avoid it, and how OutSystems addresses it.
1. Improper Platform Usage
Whereas the web was born of open standards, mobile was born of Apple’s walled-garden. And in response, Google did its best to counter Apple with the open-source Android operating system. But rather than work together to create a unified mobile visual language and backing technology, these software giants created two wildly divergent mobile platforms, each with their own unique specifications. Failure to adhere to these specifications results in the first security risk on OWASP’s list: improper platform usage. It encompasses any implementation that fails to follow the guidelines set by Apple, Google, Microsoft, or any other mobile OS vendor.
In one OWASP example, developers place user data at risk when they store sensitive information in local storage rather than the iOS Keychain. On both platforms, any application may read and write to local storage (and therefore, access data written by other applications). However, both platforms provide secure ways to store limited information such as passwords, authorization keys, and more.
To avoid improper platform usage, adhere to documentation provided by Apple and Google, and restrict your code to documented public APIs. When guidelines are not present, follow best practices. In the case of OutSystems, our approach to mobile is a React-based hybrid client built on top of the Open-Source Apache Cordova library. Special care is taken to guarantee that our generated code complies with all Android and iOS specifications.
Learn more about Improper Platform Usage.
2. Insecure Data Storage
Much like the example used in the first risk, insecure data storage refers to improper (or accidental) caching of sensitive information in one of several vulnerable locations. OWASP expands this risk beyond local storage (such as SQL databases) to include intermediary data handlers such as the URL cache, keyboard press cache, copy/paste buffer, application backgrounding/restoration subroutine, logger, browser storage/cookies, analytics libraries, and beyond.
To undermine would-be attackers, product teams must take great care to prevent personal data from appearing in local storage, URL requests (and responses), the application’s logs, and in state-persisting data bundles. And when passing information to third-party libraries, you should ensure that any user-identifying data remains strictly in developer possession (passing personal information to analytics services is typically a policy violation).
OutSystems takes care to prevent sensitive information from finding its way into plain sight: URLs, headers, and unencrypted bodies. As detailed by OWASP, developers should avoid storing personal information in the local database (OutSystems creates SQL databases to cache local data). If you absolutely must include personally-identifying data in local storage, we suggest you encrypt your database with the Ciphered Local Storage Plugin.
Learn more about Insecure Data Storage.
3. Insecure Communication
The majority of value provided by mobile applications exists elsewhere, on a lonely server in a galaxy far, far away. But the Empire is gaining power, and they plan to intercept Rebel communications to discover the… wait, this isn’t starwars-fanfic.net. Communicating securely over the network is a must for any application that transmits critical information from client to server or any other network-enabled device via WiFi, Bluetooth, NFC, or other radio technology.
Often, developers believe that authenticating with SSL “gets the job done,” but that leaves a lot of holes in their security cheese wheel (pretty grate analogy, right?). So, what else can you do to prevent attackers from pilfering user data? According to OWASP, you should:
- Require SSL for all network messages (including third-party libraries).
- Never permit self-signed certificates.
- Verify the authenticity of the endpoint server before forming a secure connection.
- If possible, perform additional client-side encryption before transmitting data over SSL.
How does OutSystems handle this? By mandating secured HTTP protocols for every network request. And, preventing man-in-the-middle attacks is as simple as incorporating the SSL Pinning Plugin. For Bluetooth, NFC, and third-party plugins that communicate over a network, be sure to secure these channels yourself.
Learn more about Insecure Communication.
4. Insecure Authentication
Logging into an application on a mobile device can be cumbersome, so developers look for shortcuts to bring users into the app. These shortcuts can take the form of “spoofable” authentication methods like generated device identifiers passed as user credentials. The thinking here is, “As long as this generated ID remains unique to the device, so does the owner of the device to which it belongs.”
Developers cannot guarantee the uniqueness of these values (especially after Apple deprecated UIUDs), however, and attackers that discover this identifier gain access to seemingly “secure” server functionality, as well as user data. These vulnerabilities take other forms as well, such as offline authentication models that permit users to access and manipulate cached data when the application fails to establish a connection with the server.
From OWASP’s perspective, developers can better secure their authentication models by performing user verification on the server (returning data only when verified), providing unique and revocable access tokens to each device, encrypting offline data with keys derived from the user’s login credentials, and more.
As for OutSystems, by default, it enables secure server-side authentication. However, we allow developers to incorporate federated authentication methods (SAML, OAuth) into their applications with plugins such as the Google Login Plugin and the ldP component. In addition, by sticking to approved authentication methods, developers can secure user credentials with a high degree of confidence.
Go here to learn more about Insecure Authentication.
5. Insufficient Cryptography
The root of any security strategy involves abstracting sensitive data into a mishmash of characters that attackers can no longer identify, aka encryption. However, “encrypted” data is only as secure as the algorithm that encrypted it and the developer who chose the encryption algorithm, which means both can be sources of cryptographical insufficiency.
First, the iOS platform claims to protect application binaries with full encryption. iOS decrypts the application binary, loads it into memory, then verifies the binary against a signature. But during that moment, an attacker using a jailbroken iPhone and freely available tools can freeze execution and copy the decrypted application from memory before verification occurs.
Read more about Insufficient Cryptography.
6. Insecure Authorization
Authentication refers to verifying an individual’s identity, whereas authorization verifies their access permissions. The most common flaw of authorization protocols is the complete lack thereof. Developers sometimes wrongly assume that by limiting the scope of public-facing endpoints, users will fail to discover and access those unlisted methods. Therefore, private methods intended for administrator and developer use remain secure only through obscurity.
But any attacker sophisticated enough to discover these endpoints will gain free access to their functionality if the server fails to perform authorization checks. For added security, OWASP recommends developers restrict permission-identifying labels (or flags) to backend storage.
Built-in anti-tampering mechanisms in OutSystems prevent users from elevating their access levels. And OutSystems verifies authority server-side, never relying on locally-stored permission flags. However, developers should still take care when elevating user authority.
Learn more about Insecure Authorization.
7. Poor Code Quality
Ah, a vulnerability that fails to begin with the letter i! Poor code quality refers to any code executed on the mobile device that lends itself to exploitation through malicious inputs. For example, attackers may use a poorly implemented buffer to overflow the runtime stack with injected code. This behavior grants them access to runtime variables and other application-specific functionality.
OWASP recommends that mobile developers prioritize the debugging of any code that risks buffer overflow or memory leaks above other code quality issues. Developers should also take care to analyze their hand-written code and that of the plugins they choose to incorporate.
Because OutSystems generates code, a single improvement impacts performance and security across the board for all developers. Our platform also enables OTA updates (software updates that circumvent app stores). This allows developers to deploy performance and quality improvements instantly.
Learn more about Poor Code Quality.
8. Code Tampering
Like all packaged executables, mobile apps are susceptible to code modification. Even when encrypted by the operating system (see 5), sophisticated attackers can, and will, recover a decrypted binary, which gives them every opportunity to edit system calls, conditional statements, and other application logic. Attackers make these changes and then publish your modified application to third-party app stores; they masquerade as you, the original publisher.
Their modified version of your application may subvert transaction confirmation to give away free in-app content. Meanwhile, their servers collect personal information from your users—information the attackers intend to use to defraud you or the individuals in question.
To prevent an attacker from publishing a working, tampered copy of your application, OWASP recommends you validate the integrity of your executable at runtime. With the Secure Device Plugin for OutSystems, developers may verify whether the user has compromised their devices to gain access to privileged subroutines and shut down the application in response.
Learn more about Code Tampering.
9. Reverse Engineering
Yes, it’s possible to reverse-engineer a mobile application. Attackers use tools to look into a binary’s string table and discover hard-coded values such as encryption keys or authentication credentials. They can use this tactic to discover runtime integrity checks and subvert them. Or they use a Java Decompiler to rebuild an Android application’s source code from its Dex file.
Generally, there’s not much a developer can do to prevent reverse engineering, but they can use obfuscation tools to make the job that much more difficult. However, obfuscators add complexity to crash analysis; developers must deobfuscate code before they can properly examine stack traces. Your team must evaluate the cost-benefit tradeoff inherent to obfuscation and determine whether the added security step is justified.
Learn more about Reverse Engineering.
10. Extraneous Functionality
Developers who do a lot of debugging occasionally place backdoors into their applications to make them easier to work with. These backdoors can skip authentication or otherwise permit unauthorized behaviors. Unfortunately, sometimes, these shortcuts make it into production code and remain toggled by variable constants that attackers can exploit through reverse engineering and code tampering.
OWASP recommends removing extraneous code before releasing to production, deleting log statements used strictly for debugging purposes, and guaranteeing that published applications exclusively access known and publicly available APIs.
The OutSystems platform allows for backdoors and debug menus that ease development. However, the OutSystems platform enables significantly accelerated development cycles; these hyperfast cycles permit developers to make changes quickly and revert them just the same.
Learn more about Extraneous Functionality.
The Right Thing to Do
Every day, thousands of users access mobile applications built on the OutSystems platform. Securing their data is not only the right thing to do, but it is an organizational imperative. That’s why we’ve taken steps to mitigate the risks as outlined by OWASP—and we’ll keep on taking them.
To learn more about what we’ve done to secure our platform and check out OutSystems Security page.