Shulou(Shulou.com)05/31 Report--

This article shows you what the five common API vulnerabilities are, concise and easy to understand, absolutely can make your eyes shine, through the detailed introduction of this article I hope you can gain something.

API makes the world no difficult business, hackers also think so. In today's enterprise digital transformation in full swing, API has gone far beyond the scope of technology, Internet business innovation and traditional enterprise digital transformation are inseparable from API economy or API strategy. APIs connect not only systems and data, but also enterprise functions, customers and partners, and even the entire business ecosystem. At the same time, increasing security threats are making APIs the next frontier for cybersecurity. We compiled the top five API security weaknesses and fix recommendations that security experts suggest to organizations.

APIs make everything easier, from data sharing to system connectivity to delivery of critical functionality, but APIs also make it easier for attackers, including malicious bots, to carry out attacks. The proliferation of API adoption is spurring cybercriminals to increasingly exploit API security vulnerabilities for fraud and data theft.

Below, we explore five API vulnerabilities that are vulnerable to hackers and share mitigation and hardening recommendations from security experts.

1. It is too easy to find

If you're a hacker and you're planning to attack a business, the first thing you should do is identify as many APIs as possible. I first use the target app in the usual way, opening the Web app in my browser or downloading and installing the mobile app on my phone, and then monitor the traffic using an interception agent.

Intercepting agents are able to capture all requests made by browsers or mobile applications to backend Web servers, allowing attackers to classify all available API endpoints. For example, most APIs use API/V1/login as an authentication endpoint.

If the target is also a mobile app, unpack the app and look at the API calls available inside the app. Considering all possible activities, an attacker could search for common configuration errors or APIs that fail to properly protect user data.

Finally, attackers look 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, an attacker can test standard user behavior and anomalous behavior tests, which can find interesting vulnerabilities in two ways.

Workaround: To make it more difficult for attackers to discover APIs, ensure that access to API documents is controlled through rights management that allows access only to valid users. While pinning certificates to mobile apps doesn't completely hide API endpoints and isn't perfect, it does add an extra step to the attack. API requests to Web servers should be obfuscated and controlled as much as possible.

2. Too detailed error information

Recently, attempts by attackers to take over accounts have increased. Error messages that are too "detailed" tend to make such attacks easier. A lengthy error message leads an attacker to understand what changes they need to make in order to disguise as a legitimate request. The API is designed for high-speed transactions under low load, allowing attackers to use high-performance systems to find valid accounts and then try to log in and change passwords for exploitation.

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

Third, too many parameters

As attackers traverse the attack system via API calls, they must figure out what they can send to get data. Attackers "believe" in the fact that the more complex a system is, the more things go wrong. Once an attacker recognizes the API, they classify the parameters and then attempt to gain additional data by accessing the data of an Access Management member (vertical privilege escalation) or another user (horizontal privilege escalation). Often, too many unnecessary parameters are exposed to the user.

In a recent research project, API calls to target services returned a lot of data, much of it unnecessary, such as processor keys for payment gateways and discounts available. These "reward messages" allow attackers to better understand the context and syntax of these API calls. An attacker doesn't need much imagination to figure out what to do next. These additional parameters provide attackers with a rich attack dataset.

Solution: If you restrict what users see to what is necessary, restrict the transmission of critical data, and make the data query structure unknown, it will be difficult for attackers to brute force the parameters they know.

IV. Excessive data

Again, because there are so many parameters available, collecting data becomes the obvious next step. Many enterprise systems support anonymous connections and tend to leak extra data that ordinary users don't need. In addition, many businesses tend to store data that can be accessed directly.

Security professionals are grappling with the challenge of API requests frequently exposing data storage locations. For example, when I look at the video in the security camera, I can see that the information comes from the Amazon S3 repository. Often, those S3 repositories are poorly protected and anyone's data can be retrieved.

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

Workaround: Businesses that store user data, not just PII or PHI, must conduct thorough data vetting. After examining the stored data, data access rules should be developed and tested. Ensure that anonymously accessible data does not involve any sensitive data.

5. Too little safety design

For years, application design has prioritized functionality and usability over security. Many CISOs indicate that API security in particular is not taken seriously or even excluded entirely from the security design process. It is usually after developers have developed and deployed, and after APIs have been put into production and frequently attacked, they fix the problem. Security (including API security) needs to be part of the product design and should be implemented as one of the first considerations, not as an afterthought.

Workaround: Reviewing an application's security architecture is an important first step toward a secure system. Keep in mind that APIs enable attackers to attack or exploit your system more efficiently. Security is designed to make APIs efficient tools for users, not attackers.

What are the five common API vulnerabilities, and have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserves, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.