Theoretical Foundation

API, whose full name is Application Programming Interface, also known as Application Interface, defines the data interaction methods and functional types between software. With the popularization and development of the Internet, API has expanded from the early software internal call interface to the interface that provides services to the outside world on the Internet. Callers can obtain various services provided by the interface by calling API, without accessing the source code and without understanding the details of the internal working mechanism.
API is a pre-defined function that provides services for data interaction and function triggering between programs. Callers only need to call the API and input the pre-agreed parameters to realize various functions encapsulated by developers, without accessing the source code of the functions or understanding the specific implementation mechanism of the functions.
API usually includes the following components: communication protocols, domain names, version numbers, paths, request methods, request parameters, response parameters, interface documents, etc.
API is the foundation of program development, especially for system API functions. Through the system's built-in API functions, program development functions can be quickly realized. Now, advanced languages are also based on language features to encapsulate various API interfaces that facilitate program development. This reduces the developer's need to implement specific functions, and functions can be quickly realized by directly calling API functions. However, although APIs facilitate development, they also bring many security risks and expose many security issues. The security risks of APIs include direct HOOK risks, security vulnerability risks, and security attack risks.
API security is the intersection of various security rules, and it mainly manifests in the following three parts:
Information Security:Focus on information protection, which includes the creation, storage, transmission, retention, and final destruction of information throughout its lifecycle.
Network Security:Address both aspects of the service, how to protect data streams transmitted over the network and how to prevent unauthorized network access.
Application Security:Ensure that the applications designed and deployed can resist attacks and prevent misuse.
API Security Risks
During the development and deployment of APIs, various security vulnerabilities are inevitably generated, which usually exist in communication protocols, request methods, request parameters, response parameters, access behavior, and face both external and internal threats. For example, external attackers may gain unauthorized access to data by exploiting the API, or the API parameters are not strictly checked and can be tampered with. While dealing with external threats, APIs also face internal threats.
API interfaces do not limit the frequency of API interface access at the beginning of design, allowing attackers to access a large number of API interfaces in a short period of time. This results in high-frequency access behavior, which can complete attacks such as marketing fraud and malicious registration in a very short time, and even may lead to CC attacks.
The Top 10 API Security Risks Summarized by OWASP
1. Invalid Object-Level Authorization
APIs tend to expose endpoints that handle object identification, causing widespread access control issues. Object-level authorization checks should be considered in every function that can access user input data.
2. Damaged User Authentication
The authentication mechanism is often implemented incorrectly, allowing attackers to破坏 authentication tokens or exploit implementation flaws to temporarily or permanently impersonate the identity of other users. The damage to the system's ability to identify clients/users will overall damage the API's security.
3. Excessive data leakage
Developers tend to expose all object properties without considering their individual data sensitivity, relying on the client to perform data filtering and display.
4. Lack of resource and rate limits
APIs generally do not impose any limits on the size or quantity of resources that clients/users can request. This not only affects the performance of the API server, leading to Denial of Service (DoS), but also opens the door to authentication vulnerabilities such as brute force attacks.
5. Function-level authorization damage
Complex access control strategies with different levels, groups, and roles, as well as unclear boundaries between management functions and regular functions, often lead to authorization flaws. By exploiting these issues, attackers can access the resources of other users and/or management functions.
6. Bulk allocation
Binding client-provided data (such as JSON) to a data model without proper attribute filtering based on a whitelist usually leads to bulk allocation. Whether it is guessing object properties, browsing other API endpoints, reading documents, or providing other object properties in the request payload, attackers can modify object properties outside of their permissions.
7. Security configuration errors
The most common security configuration errors are insecure default configurations, incomplete or temporary configurations, open cloud storage, incorrectly configured HTTP headers, unnecessary HTTP methods, Cross-Origin Resource Sharing (CORS), and long error messages containing sensitive information.
8. Injection
Injection flaws occur when untrusted data is sent as part of a command or query to an interpreter, such as SQL, NoSQL command injection, etc. The malicious data of attackers may induce the interpreter to execute unexpected commands or unauthorized access to data.
9. Inadequate asset management
Compared with traditional Web applications, APIs tend to expose more endpoints, making the accuracy and timeliness of documentation particularly important. Healthy hosts and the latest API versions can effectively alleviate security issues such as expired API versions and exposed debugging endpoints.
10. Insufficient logging and monitoring
Insufficient logging and monitoring, coupled with the lack or ineffective integration of event response, allows attackers to further attack the system, remain for a long time, and move horizontally to more systems to tamper with, extract, or destroy data. A large number of intrusion investigation studies show that the average time to detect an intrusion exceeds 200 days, and intrusion detection warnings usually come from external third parties, rather than from corporate internal security processes or monitoring.
API security is not only about referencing and learning from OWASP security risks, but also about facing some security vulnerabilities of system-builtin APIs, as well as the risk of the system APIs being HOOKed and changing the process. This is a common implementation plan for reverse engineering, and it also needs to be focused on and responded to in the software development process.
API security testing
API security testing mainly tests the security, correctness, and reliability of APIs to ensure that the product meets security requirements. Its testing needs to include user access, encryption, and authentication. API security testing starts with defining the APIs to be tested. Test tools use various specification formats (including OpenAPI v2/v3, Postman Collections, and HAR files) to provide information about the input and output of APIs.
API security testing is a very complex field, and the security testing of APIs brings new challenges to manual, automated, and hybrid activities. Usually, API security testing requires a combination of static analysis tools and dynamic analysis tools, and can focus on key security testing based on common API security vulnerabilities such as SQL and OS command injection, authorization/authenticity bypass, path traversal issues, and OWASP Top 10 API vulnerabilities.
Static analysis tools can effectively identify language-specific software security issues or well-known injection attack categories, and continue to be effective for complex codebases of APIs, but on the premise that these tools also model the libraries and platforms used to publicly expose these API routes.
When performing API security testing, it is also recommended to use OWASP Zap and Postman for API security testing, and the following several github repositories are worth referencing and applying.
1. https://github.com/roottusk/vapi
2. API endpoint brute force
https://github.com/danielmiessler/SecLists/tree/master/Discovery/Web-Content/api
3. Authorization Testing
https://github.com/PortSwigger/autorize
API security application
API security applications should focus on identifying API security vulnerabilities, and then carry out the research and development of API security countermeasures and strategy formulation. At the same time, API security applications should meet confidentiality (ensuring that information can only be accessed by specified users), integrity (preventing unauthorized creation, modification, and deletion), and availability (ensuring that APIs are accessible when users need to access them).
API security in application security can focus on the safe coding rules of the language, be familiar with common security vulnerabilities of software, and strengthen the management of systems and application credentials accessing APIs.
For example, strengthen the protection of API functions for some sensitive operations built-in to the system, which can prevent the destruction of the functional flow by directly hooking into system functions using an self-implemented method.
In API security, in terms of network security, we can focus on firewalls, load balancing, reverse proxies, and use secure communication protocols (such as https) to ensure data security in communication.
In the application of API security practices, the following rules can be followed to improve API security.
Each API should use Transport Layer Security (TLS) to prevent data leakage. Although this introduces the complexity of certificate management, modern platforms are turning to integrated certificate solutions to simplify adoption.
For internal users with known identities, API keys can be used to simplify access to APIs without the complexity of OAuth2, as long as the key is managed securely.
3. Do not submit any API key to the source code repository. If necessary, use a secret management solution.
4. Use authorization middleware to standardize access control and avoid functional-level authorization vulnerabilities.
5. Ensure fine-grained permissions for API keys to avoid providing unnecessary or unexpected access permissions.
6. If the software you develop has particularly complex authorization requirements, consider using standard libraries, do not reinvent the wheel and increase complexity and maintenance issues.
7. Use standard authorization modes to reduce complexity, while using clients for intensive processing to reduce the amount of data returned to the client.
8. Strengthen the implementation of log recording in software and ensure the use of standard modes, which is conducive to the review and optimization of subsequent log information.
Summary
API security has increasingly become one of the main technical needs in the field of network applications. Developers need to further strengthen in-depth research and development on API business models, analytical capabilities, technical blueprints, and compliance and standardization.
Through automated and diversified API network attacks, hackers can not only consume system resources and disrupt services, but can also master the API application and deployment through reverse engineering, and monitor the transmission of unencrypted data to steal corporate data.
There are many security design principles in security architecture design, such as open design principles, minimum privilege, minimum openness, default distrust, etc. Therefore, these security principles can also be referred to in the process of API security design.
In API security, it is also necessary to pay close attention to the entire lifecycle of API security: design, development, testing, online operation, iteration, and offline. Issues such as illegal API calls, API security vulnerabilities, and API data leaks may arise during this lifecycle.
A brief discussion on security detection in the context of security attack and defense scenarios
A Brief Discussion on Data Security Governance and Hierarchical Classification Implementation
A brief discussion on the role and challenges of the data asset mapping system
A brief discussion on enterprise security and the security risks under cloud-native

评论已关闭