What are the five common vulnerabilities of APIs?

API makes it easy to do business, and hackers think so too. Today, when the digital transformation of enterprises is in full swing, APIs have gone far beyond the scope of technology. Both Internet business innovation and the digital transformation of traditional enterprises are inseparable from the API economy or API strategy. APIs connect not only systems and data, but also corporate functional departments, customers and partners, and even the entire business ecosystem. At the same time, with increasingly severe security threats, APIs are becoming the next frontier of network security. We have compiled the top five API security weaknesses and patching suggestions that security experts have given to enterprises.

APIs make everything easier, from data sharing to system connectivity to the delivery of critical functions, but APIs also make it easier for attackers, including malicious bots. The proliferation of API applications is stimulating cybercriminals to increasingly exploit API security vulnerabilities to commit fraud and steal data.

Below, we will discuss five API vulnerabilities that are easily exploited by hackers and share mitigation and hardening suggestions given by security experts.

1. Too easy to be discovered

If you are a hacker and are going to attack a company, the first thing you need to do is to identify as many APIs as possible . I first use the target application in the normal way, opening the web application in a browser or downloading and installing the mobile application on the phone, and then use an interception proxy to monitor the communication.

Intercepting proxies are capable of capturing all requests made by a browser or mobile application to a backend web server, allowing an attacker to catalog all available API endpoints. For example, most APIs have API/V1/login as the authentication endpoint.

If the target is also a mobile app, then unpack the app and look at the API calls available inside the app. Taking into account all possible activities, attackers can search for common configuration errors or APIs that fail to properly protect user data.

Finally, the attacker looks for API documentation. Some organizations publish API documentation for third parties but use the same API endpoints for all users.

With a good endpoint list, attackers can test standard user behavior and abnormal behavior testing, two methods that can find interesting vulnerabilities.

Workaround: To make the API more difficult for attackers to discover, be sure to control access to the API documentation through permission management that only allows valid users to access. While pinning the certificate to the mobile app doesn't completely hide the API endpoint, and it's not perfect, it does add an extra step to the attack. API requests to the web server should be obfuscated and controlled as much as possible.

2. Overly detailed error messages

Recently, attempts by attackers to take over accounts have been increasing. Error messages that are too "detailed" tend to make such attacks easier. The lengthy error message guides the attacker on what changes they need to make to appear as a legitimate request. The API is designed for high-speed transactions under low load, allowing attackers to use high-performance systems to identify valid accounts and then attempt to log in and change passwords for exploitation.

Solution: Don’t use user experience as a shield. Some practices that seem to be beneficial to user experience may not be beneficial to security. The error message returned by the system should not include a wrong username or wrong password, or even the category of the error message (wrong username or password). The same goes for error messages used to query data, if the query/search is malformed or cannot be executed for some reason, it should return the most "unnutritious" error message: "Oops, something went wrong".

3. Too Many Parameters

When attackers traverse the attack system through API calls, they must figure out what they can send to obtain data. Attackers "believe" in the fact that the more complex the system, the more things can go wrong. Once the attacker identifies the API, they will catalog the parameters and then attempt to access the administrator's (vertical privilege escalation) or another user's (horizontal privilege escalation) data to collect additional data. Often, too many unnecessary parameters are exposed to the user.

In a recent research project, our API calls to the target service returned a large amount of data, much of which was unnecessary data information, such as payment gateway processor keys and available discount information. This "reward information" allows attackers to better understand the context and syntax of these API calls. It doesn't take much imagination for the attacker to figure out what to do next. These additional parameters provide attackers with a rich attack data set.

Solution: If you limit the scope of content users see to required content, restrict the transmission of critical data, and make the data query structure unknown, it will be difficult for attackers to know about them parameters for brute force cracking.

4. Too much data

Again, with so many parameters available, collecting data will be the obvious next step. Many enterprise systems support anonymous connections and tend to leak additional data that the average user does not need. Additionally, many businesses prefer to store data that can be accessed directly.

Security professionals are grappling with the challenge of API requests often exposing where data is stored. For example, when I view video from a security camera, I can see that the information comes from an Amazon S3 repository. Often, those S3 repositories are not well protected and anyone's data can be retrieved.

Another common data challenge is data overload. Many businesses are like chipmunks before winter, storing far more data than they need. A lot of expired user data has no commercial value or preservation value, but if leaked, it will bring huge brand and compliance risks to the enterprise.

Solution: For businesses that store user data, not just PII or PHI, a thorough data review is required. After examining the stored data, data access rules should be developed and tested. Ensure that data that can be accessed anonymously does not involve any sensitive data.

5. Too little security design

For many years, application design has always prioritized functionality and usability, with little regard for security. Many CISOs say that API security in particular is not taken seriously, or is even completely excluded from the security design process. Usually, after developers have completed development and deployment, they only try to find problems after the API is put into production and frequently attacked. Security (including API security) needs to be part of the product design and implemented as one of the first considerations, rather than filling in holes after the fact.

Solution: Reviewing the security architecture of your application is an important first step toward a secure system. Remember, APIs enable attackers to attack or exploit your system more efficiently. The goal of designing security is to make the API an efficient tool for users rather than attackers.

The above is the detailed content of What are the five common vulnerabilities of APIs?. For more information, please follow other related articles on the PHP Chinese website!