03 Apr, 2023

Insufficient access controls for APIs

Vulnerability Assessment as a Service (VAaaS)

Tests systems and applications for vulnerabilities to address weaknesses.

API stands for Application Programming Interface. It refers to a set of protocols, routines, and tools that allow different software applications to communicate with each other. Insufficient access controls for APIs mean that there is a lack of proper measures in place to limit or regulate access to APIs, which can lead to unauthorized access, misuse, or exploitation of sensitive data or functionalities. This can potentially result in security breaches, data leaks, and other forms of cyberattacks.

Example of vulnerable code on different programming languages:


in Java:

				
					public class MyAPI {
   public void sensitiveOperation(String secretKey) {
       if (secretKey.equals("mySecretKey")) {
           // Perform sensitive operation
       } else {
           throw new SecurityException("Unauthorized access");
       }
   }
}

				
			

 

In this Java code snippet, there is a sensitive operation that requires a secret key to be provided. However, the code only checks if the provided key matches the hardcoded value “mySecretKey”. This is a security flaw as an attacker could easily guess the secret key or bypass the check, allowing unauthorized access to the sensitive operation.

• in Python:

				
					def sensitive_operation(api_key):
   if api_key == "myAPIkey":
       # Perform sensitive operation
   else:
       raise ValueError("Unauthorized access")


				
			

 

Similarly, this Python code snippet only checks if the provided API key matches the hardcoded value “myAPIkey”. An attacker could easily guess the key or use other techniques such as API enumeration to discover valid keys, allowing unauthorized access to the sensitive operation.

• in Node.js:

				
					app.post('/api/sensitiveOperation', function(req, res) {
   var apiKey = req.body.api_key;
   if (apiKey == "myAPIkey") {
       // Perform sensitive operation
   } else {
       res.status(401).send("Unauthorized access");
   }
});

				
			


In this Node.js code snippet, the API key is obtained from the request body, but the code only checks if it matches the hardcoded value “myAPIkey”. This is a security flaw as an attacker could easily guess the key or intercept the API request to obtain the valid key, allowing unauthorized access to the sensitive operation. Additionally, the code only returns a 401 Unauthorized response, which may leak information about the existence of the sensitive operation and its location.

Examples of exploitation Insufficient access controls for APIs

Unauthorized access to sensitive data:

An attacker can use a valid or guessed API key to access sensitive data that should not be publicly available. For example, an attacker can use an API to retrieve personal information such as names, addresses, and credit card numbers of users, leading to identity theft, financial fraud, or other malicious activities.

Unauthorized modification of data:

An attacker can use an API to modify or delete data that should only be accessible to authorized users. For example, an attacker can modify the amount of a financial transaction or delete important records, leading to financial losses, data breaches, or other harmful consequences.

Denial of Service (DoS):

An attacker can flood an API with a high volume of requests or send requests that consume excessive resources, leading to a DoS attack that can make the API unavailable to legitimate users. This can lead to disrupted services, loss of revenue, or reputational damage.

API endpoint enumeration:

An attacker can use various techniques to discover valid API endpoints or keys, such as brute-force attacks, automated scans, or reverse engineering of mobile or web applications. Once the attacker discovers a valid endpoint or key, they can use it to access the sensitive data or functionality associated with the endpoint, leading to the consequences mentioned above.

Privilege escalation techniques for Insufficient access controls for APIs

API key guessing:

An attacker can use a brute-force or dictionary attack to guess valid API keys, which can allow them to access sensitive data or functionality that is normally restricted to authorized users. If the API key is weak or easy to guess, this technique can be effective in obtaining unauthorized access.

API endpoint manipulation:

An attacker can manipulate the API endpoints to bypass or modify the access control checks, which can allow them to access or modify sensitive data or functionality. For example, an attacker can modify the parameters of an API request or modify the URL to access a different endpoint.

API request tampering:

An attacker can tamper with the API requests to bypass or modify the access control checks, which can allow them to access or modify sensitive data or functionality. For example, an attacker can modify the headers or body of an API request to bypass the authentication or authorization checks.

Session hijacking:

If the API uses session-based authentication, an attacker can steal the session tokens or cookies of a legitimate user and use them to perform actions on behalf of the user. This can allow the attacker to access or modify sensitive data or functionality that is normally restricted to the user.

Man-in-the-middle (MITM) attack:

An attacker can intercept and modify the API traffic between the client and server to bypass or modify the access control checks, which can allow them to access or modify sensitive data or functionality. For example, an attacker can intercept the API requests and modify the headers or body to bypass the authentication or authorization checks.

General methodology and checklist for Insufficient access controls for APIs

Methodology:

  1. Identify all the API endpoints and their parameters that are used to access or modify sensitive data or functionality.

  2. Identify the access control mechanisms used by the API to restrict access to the sensitive data or functionality. This can include authentication mechanisms such as API keys, OAuth tokens, or session-based authentication, as well as authorization mechanisms such as role-based access control or attribute-based access control.

  3. Test the access control mechanisms to ensure that they are effective in restricting access to the sensitive data or functionality. This can include testing for the absence of authentication or authorization checks, testing for weak or predictable API keys or tokens, testing for missing or insufficient rate limiting, and testing for other vulnerabilities such as CSRF or XSS.

  4. Test for privilege escalation vulnerabilities that can allow an attacker to obtain higher-level access or privileges than originally granted or intended. This can include testing for API key guessing, endpoint manipulation, request tampering, session hijacking, and MITM attacks.

  5. Test for DoS vulnerabilities that can make the API unavailable to legitimate users. This can include testing for the absence of rate limiting or throttling, testing for excessive resource consumption, and testing for other vulnerabilities that can be exploited to perform DoS attacks.

  6. Document and report all identified vulnerabilities to the API owner, including the potential impact and severity of each vulnerability. Provide recommendations for mitigating the vulnerabilities, such as implementing stronger authentication and authorization mechanisms, implementing proper rate limiting and throttling, encrypting API traffic, and monitoring API access logs.

  7. After the vulnerabilities have been mitigated, retest the API to ensure that the fixes are effective and that no new vulnerabilities have been introduced.

Checklist:

  1. Identify all the API endpoints and their parameters that are used to access or modify sensitive data or functionality.

  2. Identify the access control mechanisms used by the API to restrict access to the sensitive data or functionality, such as authentication mechanisms and authorization mechanisms.

  3. Test the access control mechanisms to ensure that they are effective in restricting access to the sensitive data or functionality.

  4. Test for the absence of authentication or authorization checks.

  5. Test for weak or predictable API keys or tokens.

  6. Test for missing or insufficient rate limiting.

  7. Test for privilege escalation vulnerabilities that can allow an attacker to obtain higher-level access or privileges than originally granted or intended.

  8. Test for DoS vulnerabilities that can make the API unavailable to legitimate users.

  9. Test for other vulnerabilities such as CSRF or XSS.

  10. Document and report all identified vulnerabilities to the API owner, including the potential impact and severity of each vulnerability.

  11. Provide recommendations for mitigating the vulnerabilities, such as implementing stronger authentication and authorization mechanisms, implementing proper rate limiting and throttling, encrypting API traffic, and monitoring API access logs.

  12. Retest the API after the vulnerabilities have been mitigated to ensure that the fixes are effective and that no new vulnerabilities have been introduced.

Tools set for exploiting Insufficient access controls for APIs

Automated Tools:

  • OWASP ZAP – An open-source web application scanner that can detect and exploit vulnerabilities, including insufficient access controls, through automated and manual testing.

  • Burp Suite – A popular web application security testing toolkit that includes a variety of tools for automated and manual testing, including a scanner for detecting insufficient access controls.

  • Nikto – An open-source web server scanner that can identify vulnerabilities, including insufficient access controls, through automated testing.

  • Acunetix – A web application scanner that can detect vulnerabilities, including insufficient access controls, through automated testing.

  • Netsparker – A web application scanner that can identify vulnerabilities, including insufficient access controls, through automated testing.

  • AppSpider – A web application scanner that can detect vulnerabilities, including insufficient access controls, through automated testing.

  • Qualys Web Application Scanning – A cloud-based web application scanner that can identify vulnerabilities, including insufficient access controls, through automated testing.

  • OpenVAS – An open-source vulnerability scanner that can detect vulnerabilities, including insufficient access controls, in web applications and other software through automated testing.

  • Grendel-Scan – An open-source web application scanner that can identify vulnerabilities, including insufficient access controls, through automated testing.

  • Nessus – A commercial vulnerability scanner that can identify vulnerabilities, including insufficient access controls, in web applications and other software through automated testing.

Manual Tools:

  • Postman – A popular API development environment that can be used for manual testing of APIs, including testing for insufficient access controls.

  • Fiddler – A web debugging proxy that can be used for manual testing of APIs, including testing for insufficient access controls.

  • SoapUI – A tool for testing web services that can be used for manual testing of APIs, including testing for insufficient access controls.

  • CURL – A command-line tool for making HTTP requests that can be used for manual testing of APIs, including testing for insufficient access controls.

  • HTTPie – A command-line tool for making HTTP requests that can be used for manual testing of APIs, including testing for insufficient access controls.

  • Paw – A tool for testing APIs that can be used for manual testing, including testing for insufficient access controls.

  • RESTClient – A browser extension for Firefox and Chrome that can be used for manual testing of APIs, including testing for insufficient access controls.

  • Insomnia – A cross-platform tool for testing APIs that can be used for manual testing, including testing for insufficient access controls.

  • Advanced REST Client – A browser extension for Chrome that can be used for manual testing of APIs, including testing for insufficient access controls.

  • SOAPSonar – A tool for testing SOAP web services that can be used for manual testing of APIs, including testing for insufficient access controls.

The Common Weakness Enumeration (CWE)

• CWE-285: Improper Authorization: This weakness occurs when an application does not properly enforce access controls or user permissions, allowing an attacker to perform actions that should be restricted.

• CWE-287: Improper Authentication: This weakness occurs when an application does not properly authenticate users or verify their credentials, allowing an attacker to impersonate a legitimate user and perform unauthorized actions.

• CWE-434: Unrestricted Upload of File with Dangerous Type: This weakness occurs when an application allows users to upload files without proper validation, which can lead to the execution of malicious code or the disclosure of sensitive information.

• CWE-506: Embedded Malicious Code: This weakness occurs when an application allows users to submit or execute arbitrary code, which can be used to bypass access controls or perform unauthorized actions.

• CWE-611: Improper Restriction of XML External Entity Reference: This weakness occurs when an application processes XML input without properly validating external entities, which can lead to the disclosure of sensitive information or the execution of malicious code.

• CWE-749: Failure to Follow Principle of Least Privilege: This weakness occurs when an application grants excessive permissions or privileges to users, which can increase the risk of unauthorized access or data breaches.

• CWE-862: Missing Authorization: This weakness occurs when an application fails to enforce proper access controls or user permissions, allowing attackers to bypass authentication and gain unauthorized access to sensitive data or functionality.

• CWE-863: Incorrect Authorization: This weakness occurs when an application incorrectly enforces access controls or user permissions, allowing attackers to perform actions that should be restricted.

• CWE-935: Improper Verification of Cryptographic Signature: This weakness occurs when an application does not properly verify digital signatures, allowing attackers to impersonate legitimate users or modify data without detection.

• CWE-1175: Improperly Controlled Modification of Security-critical Elements: This weakness occurs when an application allows unauthorized modification of security-critical elements, such as access controls or permissions, which can lead to unauthorized access or data breaches.

Top 5 CVES related to Insufficient access controls for APIs

• CVE-2023-24029 – In Progress WS_FTP Server before 8.8, it is possible for a host administrator to elevate their privileges via the administrative interface due to insufficient authorization controls applied on user modification workflows.

• CVE-2022-30316 – Honeywell Experion PKS Safety Manager 5.02 has Insufficient Verification of Data Authenticity. According to FSCT-2022-0054, there is a Honeywell Experion PKS Safety Manager unauthenticated firmware update issue. The affected components are characterized as: Firmware update functionality. The potential impact is: Firmware manipulation. The Honeywell Experion PKS Safety Manager utilizes the DCOM-232/485 communication FTA serial interface and Enea POLO bootloader for firmware management purposes. An engineering workstation running the Safety Builder software communicates via serial or serial-over-ethernet link with the DCOM-232/485 interface. Firmware images were found to have no authentication (in the form of firmware signing) and only relied on insecure checksums for regular integrity checks. Firmware images are unsigned. An attacker with access to the serial interface (either through physical access, a compromised EWS or an exposed serial-to-ethernet gateway) can utilize hardcoded credentials (see FSCT-2022-0052) for the POLO bootloader to control the boot process and push malicious firmware images to the controller allowing for firmware manipulation, remote code execution and denial of service impacts. A mitigating factor is that in order for a firmware update to be initiated, the Safety Manager has to be rebooted which is typically done by means of physical controls on the Safety Manager itself. As such, an attacker would have to either lay dormant until a legitimate reboot occurs or possibly attempt to force a reboot through a secondary vulnerability.

• CVE-2022-30315 – Honeywell Experion PKS Safety Manager (SM and FSC) through 2022-05-06 has Insufficient Verification of Data Authenticity. According to FSCT-2022-0053, there is a Honeywell Experion PKS Safety Manager insufficient logic security controls issue. The affected components are characterized as: Honeywell FSC runtime (FSC-CPU, QPP), Honeywell Safety Builder. The potential impact is: Remote Code Execution, Denial of Service. The Honeywell Experion PKS Safety Manager family of safety controllers utilize the unauthenticated Safety Builder protocol (FSCT-2022-0051) for engineering purposes, including downloading projects and control logic to the controller. Control logic is downloaded to the controller on a block-by-block basis. The logic that is downloaded consists of FLD code compiled to native machine code for the CPU module (which applies to both the Safety Manager and FSC families). Since this logic does not seem to be cryptographically authenticated, it allows an attacker capable of triggering a logic download to execute arbitrary machine code on the controller’s CPU module in the context of the runtime. While the researchers could not verify this in detail, the researchers believe that the microprocessor underpinning the FSC and Safety Manager CPU modules is incapable of offering memory protection or privilege separation capabilities which would give an attacker full control of the CPU module. There is no authentication on control logic downloaded to the controller. Memory protection and privilege separation capabilities for the runtime are possibly lacking. The researchers confirmed the issues in question on Safety Manager R145.1 and R152.2 but suspect the issue affects all FSC and SM controllers and associated Safety Builder versions regardless of software or firmware revision. An attacker who can communicate with a Safety Manager controller via the Safety Builder protocol can execute arbitrary code without restrictions on the CPU module, allowing for covert manipulation of control operations and implanting capabilities similar to the TRITON malware (MITRE ATT&CK software ID S1009). A mitigating factor with regards to some, but not all, of the above functionality is that these require the Safety Manager physical keyswitch to be in the right position.

• CVE-2022-27673 – Insufficient access controls in the AMD Link Android app may potentially result in information disclosure.

• CVE-2021-35534 – Insufficient security control vulnerability in internal database access mechanism of Hitachi Energy Relion 670/650/SAM600-IO, Relion 650, GMS600, PWC600 allows attacker who successfully exploited this vulnerability, of which the product does not sufficiently restrict access to an internal database tables, could allow anybody with user credentials to bypass security controls that is enforced by the product. Consequently, exploitation may lead to unauthorized modifications on data/firmware, and/or to permanently disabling the product. This issue affects: Hitachi Energy Relion 670 Series 2.0 all revisions; 2.2.2 all revisions; 2.2.3 versions prior to 2.2.3.5. Hitachi Energy Relion 670/650 Series 2.1 all revisions. 2.2.0 all revisions; 2.2.4 all revisions; Hitachi Energy Relion 670/650/SAM600-IO 2.2.1 all revisions; 2.2.5 versions prior to 2.2.5.2. Hitachi Energy Relion 650 1.0 all revisions. 1.1 all revisions; 1.2 all revisions; 1.3 versions prior to 1.3.0.8; Hitachi Energy GMS600 1.3.0; 1.3.0.1; 1.2.0. Hitachi Energy PWC600 1.0.1 version 1.0.1.4 and prior versions; 1.1.0 version 1.1.0.1 and prior versions.

Insufficient access controls for APIs exploits

  • API key or token theft: An attacker can steal an API key or token by intercepting network traffic, brute-forcing credentials, or exploiting a vulnerability that allows unauthorized access to the token. Once the attacker has the key or token, they can use it to perform unauthorized actions or access sensitive data.

  • Privilege escalation: An attacker can escalate their privileges by exploiting a vulnerability that allows them to bypass access controls or impersonate a legitimate user. This can allow the attacker to access sensitive data or perform actions that should be restricted.

  • Data tampering: An attacker can modify or delete data by exploiting a vulnerability that allows them to bypass access controls or manipulate the API parameters. This can lead to data loss or integrity issues.

  • API parameter manipulation: An attacker can manipulate the API parameters to perform actions that should be restricted, such as accessing sensitive data or performing unauthorized transactions.

  • Session hijacking: An attacker can hijack a valid user session by stealing session tokens or exploiting a vulnerability that allows them to impersonate a legitimate user. This can allow the attacker to perform actions as the legitimate user, including accessing sensitive data or performing unauthorized transactions.

  • API rate limiting bypass: An attacker can bypass rate limiting controls by exploiting a vulnerability that allows them to send requests at a higher rate than intended. This can cause denial of service (DoS) issues or other performance problems.

  • Cross-site request forgery (CSRF): An attacker can trick a user into performing actions on the API without their knowledge or consent by exploiting a vulnerability that allows them to inject malicious code into a legitimate request. This can lead to unauthorized data access or transaction execution.

  • API endpoint enumeration: An attacker can enumerate the API endpoints by using brute-force techniques or exploiting a vulnerability that allows them to retrieve metadata. This can allow the attacker to identify sensitive API functions or data.

Practicing in test for Insufficient access controls for APIs

Set up a testing environment: create a testing environment that simulates a real-world scenario, including API endpoints, user roles, and data access controls. Use mock data or non-sensitive data to avoid any potential impact on live systems.

Perform a threat modeling exercise: to identify potential attack vectors and prioritize areas to test.

Test API endpoints: to ensure that access controls are implemented correctly and that only authorized users can access sensitive data or perform actions.

Test user roles and permissions: to ensure that each role can only access the data and functions they are authorized to use.

Test authentication and authorization mechanisms: to ensure that they are implemented securely and cannot be bypassed.

Test for session management vulnerabilities: such as session hijacking or session fixation, to ensure that sessions are managed securely.

Test for API rate limiting bypass: to ensure that the API is protected against DoS attacks and other performance issues.

Test for API parameter manipulation: vulnerabilities to ensure that only valid parameters and values are accepted by the API.

Test for cross-site request forgery (CSRF): to ensure that malicious requests cannot be executed through the API.

Use automated tools: such as Burp Suite or OWASP ZAP, to assist with testing and to identify common vulnerabilities.

Stay up-to-date with best practices: keep up-to-date with the latest best practices and security recommendations for API security, such as those published by OWASP.

For study Insufficient access controls for APIs

OWASP API Security Project: The OWASP API Security Project provides guidance and best practices for securing APIs, including access control considerations.

NIST SP 800-53: The NIST SP 800-53 document provides guidelines for securing federal information systems and includes a section on access controls for APIs.

API Security Checklist: The API Security Checklist provides a comprehensive list of security considerations for APIs, including access controls.

API Security Testing Guide: The API Security Testing Guide provides guidance on testing the security of APIs, including testing for access control vulnerabilities.

The API Security Mindset: The book “The API Security Mindset” provides a holistic view of API security and includes a chapter on access control.

Online courses and tutorials: Platforms like Udemy, Coursera, and Pluralsight offer online courses and tutorials on API security that include coverage of access control vulnerabilities.

Community forums and discussions: Participating in community forums and discussions, such as the OWASP community or Reddit’s r/netsec, can provide insights into real-world access control vulnerabilities and how to remediate them.

Books with review of Insufficient access controls for APIs

The API Security Mindset by Isabelle Mauny and Philippe De Ryck: This book covers a wide range of API security topics, including access control vulnerabilities and how to mitigate them.

API Security in Action by Neil Madden: This book provides an overview of API security concepts and includes a chapter on access control vulnerabilities.

Practical Web API Security by Nauman Fakhar and Jamal Khan: This book covers common API security threats, including access control vulnerabilities, and provides practical solutions for securing APIs.

Securing RESTful Web Services with OAuth 2.0 by Prabath Siriwardena: This book focuses on using OAuth 2.0 to secure APIs, including addressing access control vulnerabilities.

APIs: A Strategy Guide by Daniel Jacobson, Greg Brail, and Dan Woods: This book provides a high-level overview of APIs and includes a section on security, including access control.

Web API Design: Crafting Interfaces that Developers Love by Brian Mulloy: This book covers best practices for designing APIs, including security considerations like access control.

API Management: An Architect’s Guide to Developing and Managing APIs for Your Organization by Brajesh De: This book covers API management topics, including security considerations like access control.

OAuth 2.0 Cookbook by Adolfo Eloy Nascimento: This book provides recipes for implementing OAuth 2.0 for API security, including addressing access control vulnerabilities.

RESTful API Design: Best Practices in API Design with REST by Mark Masse: This book covers best practices for designing RESTful APIs, including security considerations like access control.

Pro ASP.NET Web API Security: Securing ASP.NET Web API by Badrinarayanan Lakshmiraghavan: This book provides practical guidance for securing ASP.NET Web APIs, including addressing access control vulnerabilities.

List of payloads Insufficient access controls for APIs

SQL injection payloads: These can be used to test whether an API endpoint is vulnerable to SQL injection attacks. Some examples include:

				
					' OR 1=1 --
%27%20OR%20%271%27=%271
UNION ALL SELECT NULL,NULL,NULL-- 

				
			

 

XPath injection payloads: These can be used to test whether an API endpoint is vulnerable to XPath injection attacks. Some examples include:

				
					' or 1=1 or ''='
' or 1=1 or ''=''
"/users/user[id='1' or 1=1]"

				
			

 

Parameter manipulation payloads: These can be used to test whether an API endpoint is vulnerable to parameter manipulation attacks. Some examples include:

				
					?id=1
?id=1' OR '1'='1
?id=1%20OR%201=1

				
			

 

Directory traversal payloads: These can be used to test whether an API endpoint is vulnerable to directory traversal attacks. Some examples include:

				
					../../../../../../etc/passwd
..\..\..\..\..\..\..\..\windows\system32\drivers\etc\hosts
../../../../../boot.ini

				
			

 

Authentication bypass payloads: These can be used to test whether an API endpoint is vulnerable to authentication bypass attacks. Some examples include:

				
					admin' --
'or 1=1 --
'or 1=1 /* 

				
			

How to be protected from Insufficient access controls for APIs

  1. Implement strong authentication mechanisms such as multi-factor authentication, strong passwords, and password policies.

  2. Ensure that your APIs are protected with proper access control mechanisms, such as role-based access control (RBAC), attribute-based access control (ABAC), and mandatory access control (MAC).

  3. Implement encryption mechanisms to protect data in transit and at rest. This includes using secure communication protocols such as HTTPS and encrypting sensitive data using strong encryption algorithms.

  4. Regularly assess the security of your APIs using tools such as vulnerability scanners, penetration testing, and code reviews.

  5. Stay informed about the latest security threats and vulnerabilities related to APIs, and ensure that you apply patches and updates as soon as they become available.

  6. Monitor your API activity for any suspicious or anomalous behavior, such as unusual traffic patterns, excessive requests, or unauthorized access attempts.

  7. Implement rate limiting mechanisms to prevent abuse and reduce the risk of attacks such as brute-force attacks and denial-of-service (DoS) attacks.

Conclusion

Insufficient access controls for APIs can pose a serious security risk to organizations and users. Attackers can exploit this vulnerability to gain unauthorized access to sensitive data or perform privileged actions, leading to data theft, data manipulation, and other malicious activities.

To mitigate this risk, organizations should implement strong authentication mechanisms, access control mechanisms, and encryption mechanisms to protect their APIs. Regular security assessments, staying up-to-date with the latest security threats, and monitoring API activity can also help to detect and prevent attacks.

Other Services

Ready to secure?

Let's get in touch