🫀OWASP API Security Top 10 and Beyond!

The OWASP API Security Top 10 was originally released in December 2019 and was driven by several key factors.

  1. The Rapid Rise of APIsAPIs power the flow of one of the world's most valuable resources, data. A business no longer needs to specialize in all aspects of creating software, instead, they can use the features of software shared by other companies. Historically, the issue with doing this was the disconnected nature of different programming languages. Web application programming interfaces allowed for a common method to consume or provide data across the Internet. Since the widespread adoption of web APIs, organizations have been enabled to leverage the functionality of other applications. Instead of having to develop custom software for maps, GPS, payment processing, authentication, communication, and much more, developers can leverage APIs to use the functionality of other applications that specialize in that given area. APIs are a major business enabler, which explains the global rapid adoption.

  2. A Major Gap in SecurityThe final factor that compounded the effects of the other two is the fact that the tools and techniques of the past were not effective at detecting API-related vulnerabilities. The tools and techniques that were used for enterprise vulnerability management programs, web application scanners, and traditional network security monitoring tools were not designed to handle the unique challenges posed by APIs. As a result, many organizations were not adequately prepared to defend against API attacks, leaving them vulnerable to data breaches.

  3. A New Leading Attack VectorOften, when it comes to the rapid adoption of new technologies, security is an afterthought. APIs are no different. The rapid adoption of APIs led to a new attack vector that exposes data application functionality. Public, Internet-facing, APIs often bypassed all of the security measures that had grown with businesses over the past decade. An attacker no longer needs to go through the classic MITRE cyber kill chain (bypass the firewall, gain entry to the network, pivot to a system containing data, and then exfiltrate that data). Instead, an attacker can use an insecure API and have direct access to sensitive data.

In response to the massive adoption of APIs, the security gaps introduced by API providers, and the new wave of API-related security incidents, the OWASP API Security Project published its Top 10 list.

  • Es por ello que existe el OWASP API top 10 en respuesta a poder proteger las API’s de todo el mundo bajo un estandar y de esta manera contrarrestar un poco la inseguridad tan alta de las aplicaciones con sus API’s a día de hoy.

Mapped to External Sources

The OWASP API Security risks are associated with references to external sources. These sources include Common Weakness Enumeration (CWE), other OWASP projects, and National Institute of Standards and Technology (NIST) guidance. Most of the references involve CWEs. CWEs are a list of common software and hardware vulnerabilities developed by the community and hosted by MITRE. Each CWE is identified by a unique identifier or CWE-ID. This identifier can be used to refer back to a specific vulnerability.

OWASP Top 10

External Reference

API1:2023 Broken Object Level Authorization

API2:2023 Broken Authentication

API3:2023 Broken Object Property Level Authorization

API4:2023 Unrestricted Resource Consumption

API5:2023 Broken Function Level Authorization

API6:2023 Unrestricted Access to Sensitive Business Flows

API6:2023 Server Side Request Forgery

API9:2023 Improper Inventory Management

API10:2023 Unsafe Consumption of APIs

Update to the API Security TOP 10:

Se han hecho muchos cambios y actualizacion en pro a la seguridad de las APIS top 10

  • BOLA,BFLA, SECURITY MISCONFIGURATION: Son de los breaches más comunes en bug bounty reports disclosures.

  • El proposito de OWASP API 10 no es darle y definirle a las organizaciones cuales son los riesgos que tienen, sino proveerles una guía detallada SOBRE las métodologías que deben seguir y tener presente para poder evaluar el riesgo asociado dentro de su compañía.

  • Y la clasica ecuación para el riesgo es: Riesgo=Likelihood*Impact “Likelihood:Probabilidad”

Quiz:


API 1: Broken Object Level Authorization “BOLA”

  • Broken object-level authorization (BOLA) vulnerabilities occur when a user is able to access other users' data due to the flaws in authorization controls validating access to data objects.

  • Cuando no se poseen los suficientes controles para reforzar los controles de autorización.

¿Pero que pasa si modifico el ID por 2728? y obtengo automaticamente la info de otro user, ahi entran este tipo de vulnerabilidades.

Quiz BOLA:

API 2: Broken Authentication:

  • Es la debilidad que posee una API para no validar que un usuario es quien dice ser en la API, osea Pepito es un user que se hace pasar por CARLOS que es admin, y se autentica como carlos, ahi está el GAP o hueco de seguridad.

  • Por que pasan los errores de autenticacion? por errores o politicas debiles como la de arriba:

  • Issues que vienen con la Authentication: (Insuficentes tokens randomicos “entropía pobre”, vulns en el proceso de registro, password reset process, multi factor authentication features.)

Soluciones o medidas de sanitización →

Quiz:

API 3: Broken Object Property Level Authorization: BOPLA

  • Mass asignment entonces ocurre cuando podemos añadir mucho mas parametro de los que se esperaba en una request y de esta forma generar un comportamiento inesperado o hasta escalar privilegios. EJM →

Soluciones o prevenciones a tener en cuenta de BOPLA:

Quiz:

API 4: Unrestricted Resource Consumption:

“consumo de resourc.. sin restricciones”: Los rate limits mal establecidos para que te hagas una idea felipe, hubo un massive data breach a TRELLO la compañia por una api mal expuesta la cual se podia consultar sobre un correo y devolvia la info de ese email, bueno buscaron millones de correos y los enviaron consecutivos a la api y pudieron extraer millones de datos de muchos users registrados a trello.

  • Number of operations to perform in a single API client request (e.g. GraphQL batching)

  • Number of records per page to return in a single request-response

  • RapidAPI: le ayuda a las compañias a poder manejar el numero de requests de sus API’s de una forma más segura y adecuada, mejorando significativamente y previniendo los costos asociados a la infraestructura de la misma.

Quiz:

API 5: Broken Function Level Authorization: BFLA

  • Es una vulnerabilidad donde las funciones de la API tienes controles insuficientes, mientras que BOLA trata sobre acceder a data BFLA es sobre alterar o eliminar esa Data. Acordemos del ejemplo de bumble

  • Si se puede eliminar con el metodo DELETE pero está permitida es por el user admin, asi que:

Quiz:

API 6: Unrestricted Access to Sensitive Business Flows:

  • Es cuando una API permite acceder libremente a acciones críticas del negocio, sin verificar adecuadamente si el usuario debería poder hacerlo.

  • Es el riesgo y vulnerabilidad de un atacante poder ser capaz de identificar y explotar flujos funcionales de la API, si es vulnerable el atacante podría aprovechar la estructura y el flujo de las peticiones para obstaculizar a otros usuarios.

Quiz:

API 7: Server Side Request Forgery:

  • Sin embargo para el caso de out of band, debemos tener un server externo el cual tendremos que especificar para que nos pueda llegar la speticiones o lo que intentemos ya que de esta forma es como funcionan los SSRF Ciegos fuera de banda.

Quiz:

API 8: Security Misconfiguration:

Security Misconfiguration represents a catch-all for many vulnerabilities related to the systems that host APIs. When an API's security is misconfigured it can be detrimental to the confidentiality, integrity, and availability of the API provider's data. Due to the wide variety of flaws that could exist, the impacts of an exploited security misconfiguration can range from information disclosure to data breach.

Ejemplos:

  • Security misconfigurations are really a set of weaknesses that includes misconfigured headers, misconfigured transit encryption, the use of default accounts, the acceptance of unnecessary HTTP methods, a lack of input sanitization, and verbose error messaging.

For example, if the API’s supporting security configuration reveals an unpatched vulnerability, there is a chance that an attacker could leverage a published exploit to easily pwn the API and its system.

A lack of input sanitization could allow attackers to upload malicious payloads to the server. APIs often play a key role in automating processes, so imagine being able to upload payloads that the server automatically processes into a format that could be remotely executed or executed by an unsuspecting end-user.

Attackers will often attempt to find unpatched flaws, common endpoints, or unprotected files and directories to gain unauthorized access or knowledge of the system.

Security misconfiguration can happen at any level of the API stack, from the network level to the application level. Automated tools are available to detect and exploit misconfigurations such as unnecessary services or legacy options.

Security misconfigurations can not only expose sensitive user data, but also system details that can lead to full server compromise.

Quiz:

API 9: Improper Inventory Management:

Represents the risks involved with exposing non-production and unsupported API versions. When this is present the non-production and unsupported versions of the API are often not protected by the same security rigor as the production versions.

  • no tener un control adecuado sobre los activos relacionados con la API. Esto incluye versiones, endpoints, entornos, y servicios externos conectados.

Aqui lo que pasa es que si encontramos una api vieja como puede ser /v1/ y ya actualmente está es la API v/3/ por ejm si encontramos que en v1 tenemos endpoints que ya no existen en v3, son posibles endpoints que SI O SI podemos probar con el fin de ver si aun existen pero estan ocultos o si podemos encontrar debilidad, u know

Quiz:

API 10: Unsafe Consumption of APIs: third parties

Is the only item on the top ten list that focuses less on the risks of being an API provider and more on the API consumer. Unsafe consumption is really a trust issue. When an application is consuming the data of third-party APIs it should treat those with a similar trust to user input. By that, I mean, there should be little to no trust. So, data consumed from third-party APIs should be treated with similar security standards as end-user-supplied input. If a third-party API provider is compromised then that insecure API connection back to the consumer becomes a new vector for the attacker to leverage.

  • Unsafe Consumption of APIs: Cuando una aplicación cliente consume APIs externas sin validar ni filtrar correctamente las respuestas, confiando ciegamente en que esas APIs externas son seguras, están bien configuradas y nunca se comportarán mal.

Exploiting this issue requires attackers to identify and potentially compromise other APIs/services the target API integrated with. Usually, this information is not publicly available or the integrated API/service is not easily exploitable.

Developers tend to trust and not verify the endpoints that interact with external or third-party APIs, relying on weaker security requirements such as those regarding transport security, authentication/authorization, and input validation and sanitization. Attackers need to identify services the target API integrates with (data sources) and, eventually, compromise them.

The impact varies according to what the target API does with pulled data. Successful exploitation may lead to sensitive information exposure to unauthorized actors, many kinds of injections, or denial of service.

Summary

Most of the 2023 OWASP API Security Top 10 is about APIs and the API provider. An API can often serve as the path of least resistance for an attacker. So, if an attacker compromises a third-party API provider, then that third party's connections to other businesses can become an additional attack vector. If that API is over an unencrypted connection then an attacker would be able to capture sensitive data in clear text. If that third-party API isn't held to similar security standards as an Internet-facing API then it could also be vulnerable to injection, authorization, and other compromising attacks.

QUIZ:


Beyond the top Business Logic Flaws

  • The exploitation of business logic takes place when an attacker leverages misplaced trust or features of an application against the API. Identifying business logic vulnerabilities can be challenging due to the unique nature of each business. The impact of these vulnerabilities can range based on the severity of the vulnerable policy or feature.

Attack Vector Description

Business logic vulnerabilities are unique to each application and exploit the normal intended functioning of an application's business processes. They often require specific knowledge of the application's functionality and the flow of transactions or data. Since these vulnerabilities are specific to the business logic of each application, there's no one-size-fits-all approach to identifying them.

Security Weakness Description

Business logic vulnerabilities arise when the assumptions and constraints of a given business process aren't properly enforced in the application's control structures. This allows users to manipulate the application's functionality to achieve outcomes that are detrimental to the business. These weaknesses typically occur when developers fail to anticipate the various ways that an application's features can be misused or when they don't consider the wider context of the business rules. This is often due to a lack of comprehensive understanding of the application's business logic, a lack of input validation, or incomplete function-level authorization checks.

  • The experian PARTNER API leak in 2021 fue un GRAN EJEMPLO DE UNA API QUE FALLO:

Quiz:

Last updated