With a continuously changing threat landscape, application security (AppSec) has emerged as a key process, focusing on integrating safety features into all layers of an application stack. As more organizations have begun publishing native mobile applications, mobile AppSec has become an important consideration in its own right.
In the first article in this series (How Hackers Attack Your Mobile Apps, Part 1), we discussed the threats that are made possible when hackers compromise client devices. In Part 2, we discussed network-level vulnerabilities for mobile applications: potential ways for attackers to intercept and compromise the communication between the client devices and the backend API endpoint.
Now in this third and final article, we discuss common attacks waged directly against mobile API endpoints, and some best practices to defend against them.
API Endpoint Vulnerabilities
Application Programming Interfaces (APIs) are ubiquitous on the modern web, serving as the foundation for service and microservice architectures. This makes them very attractive to attackers. At the same time, fully securing an API can be difficult, and API abuse is a common concern among application developers.
When attacking an API endpoint, threat actors typically scout the interface for vulnerabilities they can exploit. To help organizations adopt appropriate mitigation strategies, the Open Web Application Security Project (OWASP) lists a number of common API security risks. These include:
- Broken object level authorization (BOLA)
- Broken authentication
- Excessive data exposure
- Lack of Rate Limiting
Common Attacks Against Mobile Application APIs
The vulnerabilities listed above are not merely theoretical. An organization which publishes a mobile app will often see attacks targeting its API. Here are some of the more common types.
In an MitM incident, an attacker eavesdrops on conversations or data transfers, secretly intercepting traffic between an API and its clients. This is a very common, and potentially very damaging, attack against APIs that do not require clients to encrypt their requests with Transport Layer Security (TLS) or a similarly robust form of encryption. Although this situation is far less common than it used to be, nevertheless there are still organizations that allow unencrypted communication with their APIs, or that have other related issues such as certificate problems. These organizations are vulnerable to a variety of hostile activities, such as data theft and session hijacking.
Bot and Scraping Attacks
In scraping attacks, automated bots collect application data with malicious intent. There are many types of APIs that serve proprietary data: for example, a travel app might query a backend endpoint to get information about flights to a specific destination, along with times, prices, seat availability, and so on.
Scraped data can be quite valuable, and attackers frequently target APIs for this purpose. A common motive is to degrade a company’s advantage by stealing sensitive data such as product availability, pricing information, rate structures (e.g., insurance quotes), and so on. Another motive is to inflict direct financial damage on the target. For example, a travel company might be attacked via frequent API queries about flight availability. This type of data is not free (companies which access it must pay fees to the GDS provider), and a high rate of requests from attack bots can be very costly to the victim.
In an injection attack, attackers transmit malicious code to the server. Code injection is an old and well-known threat, but occasionally attackers will develop new variations in an attempt to bypass the server’s security measures. For APIs the problem can be worse than for web applications, since some WAFs do not support API security as well as they do for web apps. A successful injection attack is a serious incident, since a skillful hacker can sometimes leverage it into a system-wide breach.
Impersonation involves cybercriminals creating a malicious replica of an application and tricking users to download it. While the replica resembles the genuine application, it contains malicious software and extended functionality that captures data from the API server and transmits data to unauthorized third parties. These replicas can also be used to abuse the API in other ways, since often the backend endpoint will not recognize the client as being illegitimate.
Many APIs include login mechanisms, and they are a popular target for attackers. A common technique is credential stuffing, where hackers use lists of credential sets (e.g., user names and passwords) gained from breaches elsewhere. Because many users re-use credentials across sites and applications, attackers will systematically “stuff” the stolen credentials into APIs elsewhere, in an attempt to gain system access and take over user accounts. A successful ATO (account takeover) can be exploited in various ways, including financial fraud, exfiltrating sensitive data for later sale, performing unauthorized transactions, and more
DDoS attacks are the most common form of cyberattack today, and they are prevalent against mobile APIs too. A successful attack can make the system unavailable. This can be especially damaging when compared to a DDoS against a web application, and can create more reputational damage for the company that published the app. (When a web page is non-responsive, users can see what is occurring, and they have experienced this situation before. However, when a mobile API server is DDoS’d, the users only know that the mobile app for a specific company doesn’t appear to be working.)
Considered one of the most sophisticated forms of attack, hackers try to re-create an application’s code and configuration. This can be the basis for app impersonation, as described previously, or it can enable other forms of malicious software behavior such as API discovery.
Best Practices to Mitigate Attacks Against API Endpoints
An API tends to grow over time, and this can create an extended attack surface. Defending it can be challenging, because many web security solutions are heavily reliant on threat-detection methods that can’t be applied to APIs. (More on this later.)
Nevertheless, effective security for mobile APIs can be achieved. Here are some best practices and recommendations.
Detect Rooted and Jailbroken Mobile Devices
As discussed previously, rooted Android and jailbroken iOS devices can enable malicious activity in various ways, including the potential jeopardization of application APIs.
Some thought leaders view rooting and jailbreaking as an important right for users; they argue that people should be able to have full control over their devices. Even if you agree with this view, it can’t be denied that if your mobile app runs on a rooted/jailbroken device the API security risk for your organization is higher. Therefore, you should consider reducing your app’s functionality, whether partially or completely, if rooting/jailbreaking has been detected on the client device.
Make Reverse Engineering More Difficult
Obfuscation can hinder attackers’ attempts to reverse engineer your applications and APIs (e.g., renaming classes and libraries, altering code structure, encrypting strings, hiding metadata, and transforming logical and arithmetic expressions). Although it’s impossible to fully prevent reverse engineering, you can at least make it more difficult. This can deter hackers that have lower amounts of resources—time, finances, skills, etc.—available to wage the attack.
Avoid Storing Sensitive Data on Mobile Devices
When stored on user devices, some types of sensitive data (e.g., login credentials) can enable hackers to abuse the backend API in various ways. While the first line of defense to mitigate such abuse is to encrypt all sensitive information stored on the device, developers should also implement standard web or API login schemes (such as OpenAPI 3.0, Open Policy Agent [OPA], and OAuth) to ensure secure authentication for legitimate users. Additionally, if caching some authentication information cannot be avoided, you should leverage standard Android or iOS encryption libraries for encrypting cached data.
Pass User Data to Parameterized Queries
Parameterization involves storing user input via placeholders before the application’s interpreter processes them. By eliminating the dynamic generation of code from user input, parameterized queries make it difficult for hackers to abuse the application’s execution through malicious input. In addition, this allows the application’s interpreter to identify and suppress any malicious syntax within the input, thus discouraging client-side injection attacks.
Enforce Rate Limits
Many forms of API abuse involve higher-than-typical volumes of traffic. The list includes enumeration attacks, credential stuffing, scraping, payment card validation, payment card discovery, brute-forcing, and many others.
By limiting requestors to a normal volume of traffic, these attacks against your APIs can be defeated. Tip: when selecting a security solution, investigate its rate-limiting capabilities. Many commercial security solutions advertise this feature, but most use simplistic approaches that can be bypassed by motivated attackers (e.g., by rotating IP addresses during an attack), or that can’t be applied to APIs at all (such as CAPTCHA-based services).
Rate limiting is an important part of effective web security today; make sure your security solution can do it properly.
How to Harden Your APIs
As mentioned above, it’s important to select the right security solution to protect your APIs. Unfortunately, most solutions have deficiencies in this area. Here are the key features to look for:
- A robust WAF (Web Application Firewall). Many common attacks are based on hostile requests (e.g., code injection attempts). A next-gen WAF will filter these requests out from the incoming traffic stream.
- DDoS protection. Modern DDoS events can be difficult to mitigate, because hackers can send a large volume of seemingly legitimate requests. They will rapidly rotate IPs, change user agents, and employ other tactics so that the requests will appear to be unrelated (and thus, make it difficult to recognize which ones should be blocked). A good security solution will be able to protect against DDoS, defeat these tactics, and keep the targeted API performant and available.
- Hostile Bot Management. Most web attacks use bots in one form or another, and modern bots can be quite sophisticated and difficult to detect. The best security solutions include advanced bot management and are able to block hostile bot traffic using a variety of techniques (e.g., User and Entity Behavioral Analytics [UEBA], environment verification, bot challenges, and more) that are both effective and invisible to normal human users.
- Rate Limiting. As described previously, robust rate limiting capabilities are crucial to protecting APIs against attack.
- Other Technologies. A good solution will include a variety of other threat-prevention modules, such as ATO (account takeover) prevention, flow control (which enforces correct patterns of user behavior throughout an app or API, blocking anomalous use), real-time traffic control, and more.
- Full Protection for APIs. Some security solutions will claim to offer the capabilities above, but as mentioned earlier, will be unable to fully apply them to APIs. Seek one of the (few) security solutions which offer effective API security as well.
- Mobile App Security. A mobile app offers unique opportunities for hardening; unlike a web app, the publishing organization has complete control over the client software. Unfortunately, few security solutions take advantage of this; they treat mobile apps the same as web browsers.
The Reblaze platform includes a Mobile SDK for this latter purpose, which works for both Android and iOS applications. It is a unique security mechanism that signs the application, authenticates the device, and verifies user identity. It validates all requests coming from legitimate apps, adding a cryptographic HMAC signature to each one. The signatures are non-reproducible, non-guessable, and non-repeating.
The SDK provides a reliable and secure mechanism to confirm that the traffic is originating from a legitimate app user and not a bot or emulator. Incoming traffic that was not verified by the SDK can safely be rejected, or have other custom responses configured.
APIs are increasingly important on the modern web, while at the same time, can be more difficult to defend than sites and web applications. Unsurprisingly, they are becoming a common target for attackers.
The good news is that it’s possible to maintain effective defenses against malicious activity. Along with the best practices described earlier, a comprehensive web security solution is a crucial part of your defenses.
To learn more about how Reblaze can protect your APIs, sites, and web applications, you can get a demo here.