HACKINGCAGE

 Vulnerability I - Broken Object Level Authorization (BOLA) 

How does it Happen? 

BOLA refers to Insecure Direct Object Reference (IDOR) - which creates a scenario where the user uses the input functionality and gets access to the resources they are not authorized to access. In an API, such controls are usually implemented through programming in Models (Model-View-Controller Architecture) at the code level. 

 

Likely Impact 

The absence of controls to prevent unauthorized object access can lead to data leakage and, in some cases, complete account takeover. User's or subscribers' data in the database plays a critical role in an organization’s brand reputation; if such data is leaked over the internet, that may result in substantial financial loss. 

 

Mitigation Measures 

·        An authorization mechanism that relies on user policies and hierarchies should be adequately implemented.  

·        Strict access controls methods to check if the logged-in user is authorized to perform specific actions.  

·        Promote using completely random values (strong encryption and decryption mechanism) for nearly impossible-to-predict tokens. 

 

Vulnerability II - Broken User Authentication (BUA)

How does it happen? 

User authentication is the core aspect of developing any application containing sensitive data. Broken User Authentication (BUA) reflects a scenario where an API endpoint allows an attacker to access a database or acquire a higher privilege than the existing one. The primary reason behind BUA is either invalid implementation of authentication like using incorrect email/password queries etc., or the absence of security mechanisms like authorization headers, tokens etc. 

 

Consider a scenario in which an attacker acquires the capability to abuse an authentication API; it will eventually result in data leaks, deletion, modification, or even the complete account takeover by the attacker. Usually, hackers have created special scripts to profile, enumerate users on a system and identify authentication endpoints. A poorly implemented authentication system can lead any user to take on another user's identity.  

 

Likely Impact  

In broken user authentication, attackers can compromise the authentication mechanism and easily access sensitive data. Malicious actors can pretend to be someone authorized and can conduct an undesired activity, including a complete account takeover.  

 

Mitigation Measures  

Ensure complex passwords with higher entropy for end users. 

Do not expose sensitive credentials in GET or POST requests. 

Enable strong JSON Web Tokens (JWT), authorization headers etc. 

Ensure the implementation of multifactor authentication (where possible), account lockout, or a captcha system to mitigate brute force against particular users.  

Ensure that passwords are not saved in plain text in the database to avoid further account takeover by the attacker.  

Vulnerability III - Excessive Data Exposure 

How does it happen? 

Excessive data exposure occurs when applications tend to disclose more than desired information to the user through an API response. The application developers tend to expose all object properties (considering the generic implementations) without considering their sensitivity level. They leave the filtration task to the front-end developer before it is displayed to the user. Consequently, an attacker can intercept the response through the API and quickly extract the desired confidential data. The runtime detection tools or the general security scanning tools can give an alert on this kind of vulnerability. However, it cannot differentiate between legitimate data that is supposed to be returned or sensitive data.  

 

Likely Impact  

A malicious actor can successfully sniff the traffic and easily access confidential data, including personal details, such as account numbers, phone numbers, access tokens and much more. Typically, APIs respond with sensitive tokens that can be later on used to make calls to other critical endpoints. 

 
 

Mitigation Measures  

·        Never leave sensitive data filtration tasks to the front-end developer.  

·        Ensure time-to-time review of the response from the API to guarantee it returns only legitimate data and checks if it poses any security issue.  

·        Avoid using generic methods such as to_string() and to_json(). 

·        Use API endpoint testing through various test cases and verify through automated and manual tests if the API leaks additional data. 

 

Vulnerability IV - Lack of Resources & Rate Limiting 

 

How does it happen? 

Lack of resources and rate limiting means that APIs do not enforce any restriction on the frequency of clients' requested resources or the files' size, which badly affects the API server performance and leads to the DoS (Denial of Service) or non-availability of service. Consider a scenario where an API limit is not enforced, thus allowing a user (usually an intruder) to upload several GB files simultaneously or make any number of requests per second. Such API endpoints will result in excessive resource utilization in network, storage, compute etc. 

Nowadays, attackers are using such attacks to ensure the non-availability of service for an organization, thus tarnishing the brand reputation through increased downtime. A simple example is non-compliance with the Captcha system on the login form, allowing anyone to make numerous queries to the database through a small script written in Pytho 

 

Likely Impact  

The attack primarily targets the Availability principles of security; however, it can tarnish the brand's reputation and cause financial loss. 

 
 

Mitigation Measures  

·        Ensure using a captcha to avoid requests from automated scripts and bots. 

·        Ensure implementation of a limit, i.e., how often a client can call an API within a specified time and notify instantly when the limit is exceeded.  

·        Ensure to define the maximum data size on all parameters and payloads, i.e., max string length and max number of array elements. 

 

Vulnerability V - Broken Function Level Authorization 

How does it happen? 

Broken Function Level Authorization reflects a scenario where a low privileged user (e.g., sales) bypasses system checks and gets access to confidential data by impersonating a high privileged user (Admin). Consider a scenario of complex access control policies with various hierarchies, roles, and groups and a vague separation between regular and administrative functions leading to severe authorization flaws. By taking advantage of these issues, the intruders can easily access the unauthorized resources of another user or, most dangerously – the administrative functions.  
 

Broken Function Level Authorization reflects IDOR permission, where a user, most probably an intruder, can perform administrative-level tasks. APIs with complex user roles and permissions that can span the hierarchy are more prone to this attack.  

 
 

Likely Impact  

The attack primarily targets the authorization and non-repudiation principles of security. Broken Functional Level Authorization can lead an intruder to impersonate an authorized user and let the malicious actor get administrative rights to perform sensitive tasks.  

 
 

 

Mitigation Measures  

·        Ensure proper design and testing of all authorization systems and deny all access by default.  

·        Ensure that the operations are only allowed to the users belonging to the authorized group.  

·        Make sure to review API endpoints against flaws regarding functional level authorization and keep in mind the apps and group hierarchy's business logic.  

 

Vulnerability VI - Mass Assignment 

How does it happen? 

Mass assignment reflects a scenario where client-side data is automatically bound with server-side objects or class variables. However, hackers exploit the feature by first understanding the application's business logic and sending specially crafted data to the server, acquiring administrative access or inserting tampered data. This functionality is widely exploited in the latest frameworks like Laravel, Code Ignitor etc. 
 

Consider a user's profiles dashboard where users can update their profile like associated email, name, address etc. The username of the user is a read-only attribute and cannot be changed; however, a malicious actor can edit the username and submit the form. If necessary, filtration is not enabled on the server side (model), it will simply insert/update the data in the database.  

 
 

Likely Impact  

The attack may result in data tampering and privilege escalation from a regular user to an administrator.  

 

 

Mitigation Measures  

·        Avoid using functions that bind an input from a client to code variables automatically. 

·        Allowlist those properties only that need to get updated from the client side.  

 

Vulnerability VII - Security Misconfiguration

How does it happen? 

Security misconfiguration depicts an implementation of incorrect and poorly configured security controls that put the security of the whole API at stake. Several factors can result in security misconfiguration, including improper/incomplete default configuration, publicly accessible cloud storage, Cross-Origin Resource Sharing (CORS), and error messages displayed with sensitive data. Intruders can take advantage of these misconfigurations to perform detailed reconnaissance and get unauthorized access to the system.  

Security misconfigurations are usually detected by vulnerability scanners or auditing tools and thus can be curtailed at the initial level. API documentation, a list of endpoints, error logs etc., must not be publicly accessible to ensure safety against security misconfigurations. Typically, companies deploy security controls like web application firewalls, which are not configured to block undesired requests and attacks. 
 

 
 

Likely Impact  

Security misconfiguration can give intruders complete knowledge of API components. Firstly, it allows intruders to bypass security mechanisms. Stack trace or other detailed errors can provide the malicious actor access to confidential data and essential system details, further aiding the intruder in profiling the system and gaining entry.   

 

 

Mitigation Measures  

·        Limit access to the administrative interfaces for authorized users and disable them for other users.  

·        Disable default usernames and passwords for public-facing devices (routers, Web Application Firewall etc.). 

·        Disable directory listing and set proper permissions for every file and folder.  

·        Remove unnecessary pieces of code snippets, error logs etc. and turn off debugging while the code is in production. 

Vulnerability VIII - Injection 

How does it happen? 

Injection attacks are probably among the oldest API/web-based attacks and are still being carried out by hackers on real-world applications. Injection flaws occur when user input is not filtered and is directly processed by an API; thus, enabling the attacker to perform unintended API actions without authorization. An injection may come from Structure Query Language (SQL), operating system (OS) commands, Extensible Markup Language (XML) etc. Nowadays, frameworks offer functionality to protect against this attack through automatic sanitization of data; however, applications built in custom frameworks like core PHP are still susceptible to such attacks.  

 
 

Likely Impact  

Injection flaws may lead to information disclosure, data loss, DoS, and complete account takeover. The successful injection attacks may also cause the intruders to access the sensitive data or even create new functionality and perform remote code execution.  

 

 

Mitigation Measures 

·        Ensure to use a well-known library for client-side input validation. 

·        If a framework is not used, all client-provided data must be validated first and then filtered and sanitized.  

·        Add necessary security rules to the Web Application Firewall (WAF). Most of the time, injection flaws can be mitigated at the network level. 

·        Make use of built-in filters in frameworks like Laravel, Code Ignitor etc., to validate and filter data.  

 

Vulnerability IX - Improper Assets Management 

How does it happen? 

Inappropriate Asset Management refers to a scenario where we have two versions of an API available in our system; let's name them APIv1 and APIv2. Everything is wholly switched to APIv2, but the previous version, APIv1, has not been deleted yet. Considering this, one might easily guess that the older version of the API, i.e., APIv1, doesn't have the updated or the latest security features. Plenty of other obsolete features of APIv1 make it possible to find vulnerable scenarios, which may lead to data leakage and server takeover via a shared database amongst API versions. 

It is essentially about not properly tracking API endpoints. The potential reasons could be incomplete API documentation or absence of compliance with the Software Development Life Cycle. A properly maintained, up-to-date API inventory and proper documentation are more critical than hardware-based security control for an organization. 
 

 
 

Likely Impact  

The older or the unpatched API versions can allow the intruders to get unauthorized access to confidential data or even complete control of the system.  

 

 

Mitigation Measures  
 

·        Access to previously developed sensitive and deprecated API calls must be blocked at the network level. 

·        APIs developed for R&D, QA, production etc., must be segregated and hosted on separate servers. 

·        Ensure documentation of all API aspects, including authentication, redirects, errors, CORS policy, and rate limiting.  

·        Adopt open standards to generate documentation automatically. 

 

Vulnerability X - Insufficient Logging & Monitoring 

How does it happen? 

Insufficient logging & monitoring reflects a scenario when an attacker conducts malicious activity on your server; however, when you try to track the hacker, there is not enough evidence available due to the absence of logging and monitoring mechanisms. Several organizations only focus on infrastructure logging like network events or server logging but lack API logging and monitoring. Information like the visitor's IP address, endpoints accessed, input data etc., along with a timestamp, enables the identification of threat attack patterns. If logging mechanisms are not in place, it would be challenging to identify the attacker and their details. Nowadays, the latest web frameworks can automatically log requests at different levels like error, debug, info etc. These errors can be logged in a database or file or even passed to a SIEM solution for detailed analysis. 

 
 

Likely Impact  

Inability to identify attacker or hacker behind the attack.  

 

 

Mitigation Measures  

·        Ensure use of the Security Information and Event Management (SIEM) system for log management.  

·        Keep track of all denied accesses, failed authentication attempts, and input validation errors, using a format imported by SIEM and enough detail to identify the intruder. 

·        Handle logs as sensitive data and ensure their integrity at rest and transit. Moreover, implement custom alerts to detect suspicious activities as well.