The “Open Source Web Application Security Project” (OWASP) released the top ten API security risks “OWASP API Security Top 10” in 2019: failed object-level authorization, failed user authentication, excessive data exposure, lack of resources and rate limits, Broken function-level authorization, bulk allocation, security misconfigurations, injections, improper asset management, and insufficient logging and monitoring are among them. Based on this, we introduce the top ten security risks of APIs.
Invalid object-level authorization
Invalid object-level authorization means that when the user communicates with the server using the API, the server does not perform object-level permission control or the restrictions are not strict. An attacker can obtain or modify sensitive information without authorization by modifying information such as the object ID in the request data.
Case: When using a certain function, the corresponding data can be accessed or manipulated through the object ID (such as order number, record number) submitted by the user, without strict permission restrictions.
As shown in the figure below, normal order query request:
As shown in the figure below, use burpsuite to traverse the oid parameters and try to access the details of other people’s orders without permission. You can see that the order information of others was successfully viewed:
Broken user authentication
Invalid user authentication means that the API does not authenticate the requester when accessing or there are problems with the authentication, which makes it easy to be cracked. Then the attacker can operate the API without authorization.
Case:
1. The validity of the token is not verified;
2. The update password interface does not limit the request frequency, and the old password parameters can be cracked by brute force;
3. The SMS verification code or email verification code is valid for more than 10 minutes or is less than 6 digits in length.
Excessive data exposure
One of the main reasons why excessive data exposure occurs is that developers and coders don’t have enough insight into the kinds of data their applications will use. Because of this, developers tend to leverage a common flow in which all object properties are exposed to the end user.
Example:
Exploiting over-exposed data is easy, often by sniffing responses from traffic analysis APIs to obtain excess sensitive information that should not be returned to the user.
Defense:
-
Don’t rely on the client to filter sensitive data;
-
Check the API’s response to confirm that it contains only legitimate data;
-
It’s also important to stop the process of sending everything to users with a generic API. For example, you must avoid executing to_json() and to_string() directly on all information and then sending it to the client. The attributes that need to be returned to authorized users should be specifically selected and this information sent specifically;
-
Sensitive data should be protected using encryption technology. This way, even if the location of that data is revealed as part of an excessive data exposure vulnerability, there is a good second line of defense that can protect the data even if it falls into the hands of a malicious user or threat actor.
Now I have also found a lot of test friends and created a communication group to share technology, sharing a lot of technical documents and video tutorials we collected. If you don’t want to experience the feeling of not being able to find resources when self-study, having no one to answer your questions, and persisting for a few days before giving up. You can join us to communicate. And there are many technical experts who have made certain achievements in automation, performance, security, test development, etc. Share their experience, and also share many live lectures and technical salons You can learn for free! Focus on it! Open source! ! ! QQ group number: 110685036 [password: csdn999]
Resource Lack and Rate Limiting
With resource scarcity and rate limitations, each API has limited resources and computing power, depending on its environment. Most also need to handle requests from users or other programs to perform required functions. This vulnerability occurs when too many requests come in at the same time and the API does not have enough computing resources to handle them. The API may then become unavailable or unresponsive to new requests.
APIs are prone to this problem if their rate or resource limits are not set correctly, or if the limits are not defined in the code.
The specific case is shown below:
The above code has no restrictions. We can access all users through a large number of unlimited requests to /api/users in a short period of time, causing other client requests to be unable to respond.
After modification:
The API will limit anonymous users to 200 requests per hour. Known users who have been vetted by the system will have more leeway, with 5,000 requests per hour, but even they will be capped to prevent surprises during peak periods. Overload, or compensate when user accounts are compromised and used in denial-of-service attacks.
Enforce clear time window limits on how often users can call the API, and define and enforce validation of maximum data sizes for all incoming parameters and payloads, such as the maximum length of a string and the maximum number of elements in an array. Notify customers when limits are breached and provide limit quantities and time for limit resets.
Invalid feature-level authorization
Broken function-level authorization vulnerabilities allow users to perform functions that should be restricted, or allow them to access resources that should be protected.
As shown in the figure below, the attacker has ordinary user rights on the site. He guessed the possible management function URLs of the site through experience. After several attempts, he found that the admin_statuspage page that should not have access rights can be accessed successfully:
As shown in the figure below, the attacker is a user with ordinary permissions on the site. The site uses a known framework. The attacker looks up the details of the data packets that need to be sent for the new management user function, constructs a data packet and sends it, and finds that the new user can be successfully created.
Preventing this kind of API vulnerability is particularly important because it is not difficult for attackers to find unprotected functions in structured APIs, so all business-level functionality must be protected using a role-based authorization approach. Authorization must be implemented on the server and cannot be attempted to ensure functional security from the client. When creating functionality and resource levels, users should only be given permissions to do what they need, practicing a least privilege approach.
Batch allocation
The backend application object may contain many properties, some of which can be updated directly by the client (for example, user.firstname or user.address), and some of which should not be updated (for example, the user.isvip flag).
Case:
A ride-sharing app offers users the option to edit basic profile information. Users can update the two parameters “user_name” and “age”.
PUT /api/v1/users/me
{“user_name”:”inons”,”age”:24}
Found that the /api/v1/users/me interface returns an additional “credit_balance” parameter:
GET/api/v1/users/me {“user_name”:”inons”,”age”:24,”credit_balance”:10}
The attacker constructs a message and replays the first request:
PUT/api/v1/users/me {“user_name”:”attacker”,”age”:60,”credit_balance”:99999}
Attackers can tamper with their own credit without paying.
How to prevent:
1. If possible, avoid using functions that automatically bind customer input into code variables or internal objects; 2. Only whitelist client-updatable properties;
3. Use built-in functionality to blacklist properties that clients should not have access to;
4. If possible, define and implement schema formats for input data payloads accurately and distinctly.
Security configuration error
Overview:
Security misconfigurations can occur at any level of an application stack, including platform, web server, application server, database, framework, and custom code.
Case:
For example, the attacker found the .bash_history file in the root directory of the server. This file contains the commands used by the DevOps team to access the API:
$ curl -X GET ‘https://api.server/endpoint/’ -H ‘authorization: Basic Zm9vOmJhcg==’, the attacker can obtain the permission authentication information (Zm9vOmJhcg== base64 decoding: foo:bar) and interface with this command information.
Injection
Overview:
The server does not verify, filter or purify the data provided by the client. The data is directly used or spliced into SQL/NoSQL/LDAP query statements, OS commands, XML interpreters and ORM (Object Relational Mapper)/ODM (Object Document Mapping) device), generating injection attacks.
Case:
Determine whether the server supports XML parsing. If so, you can try XML injection.
]>
The API does not validate, filter, or sanitize data from external systems (e.g., integrated systems).
Improper asset management
The pitfalls of improper asset management are a product of the modern era, where organizations moving at the speed of business can sometimes spin out hundreds or thousands of services and microservices every day. This is usually done quickly and without creating any accompanying documentation, without explaining what the relevant API does, how long it takes, or why it’s important. This can quickly create API creep that can become uncontrollable over time, especially if there are no comprehensive policies that define how long an API can exist. In this environment, it is very likely that some APIs will be lost, forgotten, or not destroyed.
This results in improper asset management that directly allows attackers to access sensitive data or even connect to the same database via an old, unpatched API version.
How to eliminate improper asset management pitfalls: A rigorous inventory of all APIs, their uses and versions should be done. Key factors of concern include, what environment they are deployed into, such as production or development, who should have network access to them, what data is collected and processed, whether it is regular or sensitive data, APIs
survival time, and of course their versions. Once completed, a process needs to be implemented to add documentation to any newly created APIs or services. This should include all aspects of the API, including rate limits, how requests are made and responded to, resource sharing, which endpoints can be connected to, and any aspects of it that need to be audited later. You also need to avoid using non-production APIs in production and consider adding A time limit etc.
Insufficient logging and monitoring
If there are no logs and monitoring, or insufficient logs and monitoring, it will be impossible to detect malicious activities of attackers in a timely manner. At the same time, it will be impossible to quickly locate and track suspicious activities and respond in a timely manner, leaving enough time for attackers to damage the system.
API Vulnerability:
-
No logs are generated, the log level is not set correctly, or the log message lacks sufficient detail;
-
The integrity of the log cannot be guaranteed;
-
There is no ongoing monitoring of logs;
-
API infrastructure is not continuously monitored.
Recommendation:
1. There should be a system that records various authentication and authorization events, such as login failures, brute force attacks, access to sensitive data, etc.;
2. An effective monitoring and alarm system must be established, which can detect suspicious activities and respond promptly;
3. The log should ensure that there is sufficient detailed information to record the attacker’s behavior and identify malicious activities;
4. If a problem arises, the relevant team must be notified. 5. Industry standards must be used to develop incident response and recovery plans.
END Today’s sharing ends here, like and follow to avoid getting lost