Every few years the OWASP community come together to review the ten most critical vulnerabilities and security risks relating to Application Programming Interfaces (APIs) by analysing the most important security risks in real-world web APIs, drawing on vulnerabilities and incidents reported by member and partner organisations of OWASP, and identifying the frequency of occurrence as well as impact of common exploit of these vulnerabilities.
This list is then published at https://owasp.org/www-project-api-security/ and is intended to feed into the production of guidance on concerns, countermeasures and best practices relating to security in this area.
It hasn’t received the same attention as its better-known sibling to date, but we’ll take a look at the vulnerabilities presented, and how you can best address them within your organisation’s API development.
So, what are the specific risks facing API usage within organisations, and how can these best be addressed by developers and security teams?
“Broken object level authorization” or “BOLA” is the number one API vulnerability that attackers can exploit to gain access to an organization’s data, according to the OWASP report. Essentially, this is similar to an IDOR vulnerability in a web application in which attackers can manipulate the object that is sent with the API request in order to gain access to an inappropriate data set in response.
Because so much processing can occur client-side it is easy for developers to forget that request context needs to be considered server-side too. Remediation of this vulnerability involves ensuring that object level authorization is set up in the code to make sure that only a user with the correct permission can access and act on a requested object.
This is a broad category of vulnerabilities that can include the exposure of APIs on the public internet that are intended for internal usage only; the use of weak API keys or weak passwords; the use of credentials in URLs that may be subject to caching; lack of access token validation or failing to expire access tokens.
The measures appropriate to reduce these risks obviously depend on the exact vulnerability in question. However, in general, it should be ensured that standard libraries are used for authentication, token generation, and password storage. Consideration should be given to the use of 2FA where possible given the API’s intended usage; access tokens should be short-lived and the same measures such as rate-limiting authentication that you use on your front-end web application should be applied to your APIs also.
Because of the lack of an in-built MVC model APIs sit “closer” to data stores such as databases and often return large data blocks in a rawer format (occasionally the entire data object), leaving it to client-side code to sort, filter or select the record they are interest in. However, if an attacker calls the API directly rather than accessing the data object through the intended client-side code, then they have access to the entire data object, possibly including sensitive data for all other users.
This is equivalent to web application security weakness CWE-602 “Client-Side Enforcement of Server-Side Security” and the protection mechanisms are the same – to ensure that security checks and filtering for user-specific data that are performed client side are performed server side too.
APIs are obviously vulnerable to many of the same DoS and brute force attacks as web applications. They are less vulnerable in some respects since the data processing – and hence server load – they perform is lower. However, in some respects they are more vulnerable since the API sits “closer” to the database and pulls data in a more direct way. This can be exploited by attackers if the code is vulnerable in that a simple request for an object can be manipulated via URL parameters to fetch and retrieve massive data sets. For example:
https://www.example.com/api/getUsers?startId=1&recordCount=10000000
However, due to the nature and speed of API’s, a lack of rate-limiting can lead to further issues in the form of data harvesting, brute-force attacks on authentication endpoints and on endpoints with Broken Object Level Authorization.
The solution to this vulnerability is to ensure that APIs: define proper rate limiting and provide sensible upper-bound limits on payload sizes.
Broken function-level authorization is when web applications fail to appropriately restrict sensitive functions to the correct authorized users. Unlike broken object-level authorization, this flaw refers specifically to when unauthorized users can access sensitive or restricted functions they should not have access to.
There are a couple of different variants of this vulnerability, which refer to the ability for non-privileged users to access unintended or restricted functions of the API. These are mainly influenced by the privilege model in use by an application (https://appcheck-ng.com/privilege-escalation).
In an API a trivial example might be, an administrative function may be exposed simply by navigating to a different URL, e.g.:
Unprivileged – GET /api/v1/users/111122 HTTP/1.1
Privileged – GET /api/v1/users/all HTTP/1.1
In another variant, the HTTP verb/method can itself be substituted to access functionality that should not be accessible. For example:
Unprivileged – GET /api/v1/users/111122 HTTP/1.1
Privileged – DELETE /api/v1/users/111122 HTTP/1.1
Unprivileged – GET /api/v1/users/111122 HTTP/1.1
Privileged – DELETE /api/v1/users/111122 HTTP/1.1
https://www.example.com/application?action=createUser&userID=daniel&role=admin
APIs may be vulnerable to a similar vulnerability if the server-side code fails to adequately filter on permitted object properties received from users in different contexts by manually manipulating the input payload in a POST request to include an unexpected permission assignment:
{"user": {
"name": "daniel",
"role": “admin”
}
}
In order to prevent this vulnerability, it is important that developers precisely define schemas permitted in different API methods and that they do not blindly trust incoming data and objects received from the client side.
This is an extremely broad category of vulnerabilities including those common to web application servers, such as a lack of patching, weak SSL/TLS configuration, missing security headers, and information exposure via error messages output in server responses etc.
Companies will likely already have policies and processes in place to ensure patching and locate configuration flaws, and these same controls, including vulnerability scanning, should be applied to APIs, both internal and public.
Injection flaws, such as SQL injection and Command Injection are established risks that are generally well known to developers from traditional web application endpoints. They occur when untrusted data passed in by a client or user as part of a request are sent in an unvalidated and unfiltered form to an interpreter on the server, where they are used directly as part of a command or query. The vulnerability is certainly less common in APIs, but the same risks remain and the risks of some – such as XML Entity Injection – may be increased in XML-based SOAP APIs in particular.
The solution for preventing against injection attacks is well known but include strictly defining all input data types and schemas, and subjecting received data to strict validation, filtering, and sanitisation; as well as ensuring that interaction with databases is mitigated using measures such as parameterized queries.
The vulnerability describes that fact that some API instances or methods may be inadvertently exposed to attackers. In the simplest example, a non-production instance such as staging may be exposed to the internet. However, a more subtle and frequently observed vulnerability is that a production API may contain methods still that are un-maintained and that developers do not believe are exposed any longer, but maybe found by attackers. Either functionality is left in to maintain backwards compatibility, and then forgotten about, or else the functionality is removed in the front-end client code, but the corresponding functionality is left in place in the API through oversight.
Protective measures include the use of more robust internal documentation, thorough code review, or the use of technical controls such as API firewalls.
“Insufficient logging and monitoring” is relatively self-explanatory, but if coupled with missing or ineffective integration with incident response and SIEM systems, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data.
It is important that developers ensure that sensitive data is not recorded in logs, and that logs record key details such as the requesting IP for all requests and are properly integrated with SIEM systems in order to permit accurate and timely incident detection.
So how can AppCheck help you in securing your APIs?
AppCheck includes specific API scanning technology that is able to build up a map of a scanned API using WSDL and OpenAPI/Swagger files, seeded targets and similar technologies, to ensure that the API is fully modelled and scanned.
AppCheck supports API authentication methods including API access keys to ensure that APIs can be authenticated against, and all methods fully probed for vulnerabilities.
AppCheck includes API-specific vulnerability checks written by our in-house penetration testers, to detect previously unknown vulnerabilities from first principles.
AppCheck help you with providing assurance in your entire organisation’s security footprint. AppCheck performs comprehensive checks for a massive range of web application vulnerabilities – including SQL injection and other database security weaknesses – from first principle to detect vulnerabilities in in-house application code. Our custom vulnerability detection engine delivers class-leading detection of database vulnerabilities and includes logic for multiple detection methods (including Time Delay Detection, Error Detection, Out of Band Detection and Boolean Inference) as well as a range of database products and platforms (including Oracle, PostgreSQL, SQLite, MSSQL, MySQL and Azure).
The AppCheck Vulnerability Analysis Engine provides detailed rationale behind each finding including a custom narrative to explain the detection methodology, verbose technical detail, and proof of concept evidence through safe exploitation.
AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network, and cloud infrastructure. AppCheck are authorized by the Common Vulnerabilities and Exposures (CVE) Program as a CVE Numbering Authority (CNA).
As always, if you require any more information on this topic or want to see what unexpected vulnerabilities AppCheck can pick up in your website and applications then please contact us: info@localhost
No software to download or install.
Contact us or call us 0113 887 8380
AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network and cloud infrastructure. AppCheck are authorized by te Common Vulnerabilities and Exposures (CVE) Program aas a CVE Numbering Authority (CNA)
