Cinco vulnerabilidades críticas de seguridad en API's

Cinco vulnerabilidades críticas de seguridad en API's

Las interfaces de programación de aplicaciones (API) son una parte fundamental del desarrollo de software moderno. Las organizaciones utilizan las API para mejorar la experiencia del usuario en sus productos y servicios. Casi todas las aplicaciones utilizan una API. Si bien las API son valiosas y necesarias para cualquier estrategia de transformación digital, también son objetivos de alto valor para los malos actores que buscan apoderarse de las cuentas, crear cuentas falsas o participar en el relleno de credenciales o el raspado de contenido. Los sectores, como el financiero y el sanitario, son los principales objetivos de los ataques basados en API debido a los datos de gran valor que ambos sectores recopilan, mantienen y divulgan. Dados los riesgos conocidos asociados con el despliegue de aplicaciones que utilizan APIs, las organizaciones deben proteger y asegurar las APIs que producen y consumen si pretenden mantener una postura de seguridad sólida.


Debilidades y vulnerabilidades en la seguridad de las API

Las debilidades de  API permiten a los atacantes aprovecharse de los activos digitales de una organización. Son similares a cualquier otro recurso accesible por Internet. Una vez que un atacante explota una debilidad de la API, las empresas corren el riesgo de sufrir daños financieros y de reputación, especialmente cuando se exponen datos sensibles. Varios de los ataques más notables y a gran escala se han debido a la explotación de la vulnerabilidad en APIs. En 2021, la debilidad de la API de Experian dio lugar a la exposición no autorizada de la información de las cuentas de los clientes, incluidas las puntuaciones de crédito. Un investigador descubrió que una API es directamente accesible sin autenticación. El investigador también descubrió que al introducir todos los ceros en el campo de la fecha de nacimiento, podía ver la puntuación de crédito de los individuos. El verano pasado, en 2021, un investigador encontró una vulnerabilidad en la API de Peloton que permitía el acceso no autorizado a la información personal identificable (PII por sus siglas en ingles) de los clientes, lo que dio lugar a graves críticas.


Estos ataques pusieron de manifiesto el impacto de las API inseguras o con fugas y los retos a los que se enfrentan las organizaciones para navegar por el panorama de las amenazas a la seguridad de las API. Cada vez está más claro que las herramientas de seguridad tradicionales no pueden proteger contra el actual panorama de amenazas.


Vulnerabilidades críticas en la seguridad de las API

Según el Top 10 de OWASP para 2021, las vulnerabilidades de seguridad más críticas de las API se encuentran en las siguientes cinco categorías:


  1. Control de acceso roto
  2. Fallos criptográficos
  3. Inyección
  4. Diseño inseguro
  5. Mala configuración de la seguridad

El control de acceso es un componente esencial en la seguridad de los datos. Esta técnica de seguridad determina quién puede ver o utilizar los recursos de una empresa. Los controles de acceso pueden consistir en vallas, cerraduras con llave, torniquetes y sistemas biométricos. Una mala implementación de los mecanismos de control de acceso puede conducir a un control de acceso roto. Los controles de acceso rotos pueden dar lugar a diversos tipos de escalada de privilegios (horizontal, vertical y "context-dependet"), lo que puede permitir a un mal actor obtener acceso privilegiado a los sistemas. Cuando un mal actor obtiene acceso privilegiado a un sistema, tiene acceso a datos sensibles que podrían ser revelados, modificados o destruidos. El OWASP Top 10: 2021 señala que el control de acceso roto es la categoría con el riesgo de seguridad de aplicaciones web más grave.


La categoría de fallos criptográficos, anteriormente categorizada por OWASP como exposición de datos sensibles, incluye vulnerabilidades relacionadas con la criptografía, que conducen a la exposición de datos sensibles. Los datos que se dejan sin cifrar corren el riesgo de quedar expuestos, y la exposición de datos sensibles puede perjudicar a las personas, dañar la reputación de la marca de una organización y provocar costosas multas.


Los fallos criptográficos pueden ocurrir cuando:


  1. Se utilizan algoritmos o protocolos criptográficos antiguos, débiles por defecto o en código antiguo.
  2. Se utilizan funciones hash depreciadas como MD5 o SHA1.
  3. Se utilizan funciones hash no criptográficas cuando son necesarias las funciones hash criptográficas.

La categoría de inyección consiste en que un atacante añada entradas, a veces código malicioso a un programa o aplicación alterando la ejecución de un programa. Además, una aplicación es vulnerable a un ataque cuando:


  • Los datos suministrados por el usuario no son validados, filtrados o saneados por la aplicación.
  • Las consultas dinámicas o las llamadas no parametrizadas sin escape de contexto se utilizan directamente en el intérprete.
  • Los datos hostiles se utilizan dentro de los parámetros de búsqueda del mapeo objeto-relacional (ORM) para extraer registros adicionales y sensibles.
  • Los datos hostiles se utilizan directamente o se concatenan.
  • El SQL o comando contiene la estructura y los datos maliciosos en consultas dinámicas o procedimientos almacenados.

El diseño inseguro se centra en los riesgos relacionados con los defectos de diseño y en un mayor uso del modelado de amenazas, los patrones de diseño seguro y las arquitecturas de referencia. OWASP afirma que el modelado de amenazas debe utilizarse para la autenticación crítica, el control de acceso y la lógica empresarial para mitigar los riesgos relacionados con los defectos de diseño y arquitectura.


En cuanto a la quinta categoría, los fallos de seguridad pueden provenir de configuraciones inseguras por defecto. Por ejemplo, una aplicación puede ser vulnerable si las cuentas por defecto y sus respectivas contraseñas siguen habilitadas y sin cambios. Las organizaciones que buscan prevenir las vulnerabilidades deben implementar un proceso automatizado para verificar la efectividad de las configuraciones y ajustes en todos los entornos.


Reactions

7

0

0

0

Access hereTo be able to comment

TheWhiteCode.com is not the creator or owner of the images shown, references are: