Receta para el desastre: estrategias que priorizan las API y dejan la seguridad para el final

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

La demanda de API no deja de crecer. Ya sea porque contribuyen a impulsar la economía digital al hacer posibles las aplicaciones móviles o porque aumentan internamente la productividad mediante iniciativas de automatización y orquestación, las API están por todas partes.

Muchas organizaciones han adoptado el grito de guerra digital «¡Primero las API!». De hecho, la mayoría (el 60 %) de los encuestados en el informe de Cloud Elements Estado de la integración de API en 2018 pone una API a disposición de cualquier desarrollador. Y está dando sus frutos. Un asombroso 85 % de las organizaciones obtiene al menos algunos ingresos de las API y de las implementaciones relacionadas con ellas. La mayoría (el 59 %) genera entre el 11 % y el 50 % de los ingresos de su organización. Más de una de cada diez (el 11 %) obtiene más de la mitad de sus ingresos únicamente de las API. (El creciente valor de las API de MuleSoft)

Pero permítame recordarle que ponen sus API a disposición de CUALQUIER desarrollador. No de cualquier desarrollador con buenas intenciones, sino de cualquiera.

El carácter abierto de la economía actual de las API es una de las razones por las que resulta lamentable que una estrategia que prioriza las API vaya acompañada con demasiada frecuencia de otra que deja la seguridad para el final.

Es relativamente fácil encontrar una auténtica avalancha de incidentes de seguridad relacionados con API que afectan a organizaciones de gran relevancia. Ya sean mencionados por Forbes o descubiertos por nuestro propio equipo de F5 Labs, estas organizaciones han sufrido brechas de seguridad relacionadas con API que podrían haberse evitado mediante prácticas y herramientas de seguridad ampliamente conocidas.

Nuestro propio Ray Pompon, evangelista principal de investigación de amenazas de F5 Labs, señaló en su investigación sobre la seguridad de las API:

«…se pueden observar patrones asociados a los mismos problemas clásicos de seguridad de las aplicaciones que siempre hemos tenido: atacantes que obtienen acceso mediante ataques de fuerza bruta o credenciales robadas. Además, una vez autenticados en la API, los atacantes aprovecharon los permisos excesivamente amplios que se les habían asignado».

Fuente: <https://www.f5.com/labs/articles/threat-intelligence/reviewing-recent-api-security-incidents>

Los mismos problemas clásicos. Porque, al fin y al cabo, las API suelen implementarse como URI transportados mediante HTTP que contienen una carga útil de datos JSON o XML. Algo que no difiere demasiado de un URI transportado mediante HTTP que contiene una carga útil de datos de formulario enviados mediante POST.

Y no olvidemos que una API no es más que una interfaz para el código. Un código que, según las Estadísticas de seguridad de aplicaciones de WhiteHat, presenta una media de 39 vulnerabilidades por cada 100 000 líneas de código (LOC). Aunque ese dato corresponde a una aplicación tradicional. La cifra asciende a 180 por cada 100 000 LOC si la interfaz (API) se implementa mediante una arquitectura de microservicios. En cualquier caso, son muchas vulnerabilidades.

Una API presenta las mismas vulnerabilidades que su equivalente, la aplicación web. Eso significa que requiere la misma atención en materia de seguridad que una aplicación web.

Sin embargo, hoy en día no se concede a la seguridad de las API la misma importancia que a la de las aplicaciones web, al menos a juzgar por las pruebas existentes, que ponen de manifiesto el deficiente enfoque adoptado en las pruebas de seguridad. Una encuesta informal de SmartBear reveló que solo el 12 % de los encuestados realizaba pruebas de seguridad «exhaustivas» en sus API. Casi el doble —el 23 %, para ser exactos— no realizaba NINGUNA PRUEBA DE SEGURIDAD DE LAS API. Esto coincide con una investigación más formal realizada por SmartBear que reveló que el 80 % de los encuestados prueba sus API.

Lo que aún deja un 20 % que no lo hace.

Priorizar las API es una excelente forma de participar en la economía digital y transformar tanto el negocio como las operaciones en máquinas digitales ágiles y eficientes. Pero dejar la seguridad para el final es una forma estupenda de convertir todo eso en un amargo hashtag que sea tendencia en Twitter*. Y nadie quiere eso.

Por tanto, si va a priorizar las API —y debería hacerlo—, también debe otorgar a la seguridad un papel de primer orden. No acepte una estrategia que deje para el final la seguridad de sus API.

Estos son algunos pasos sencillos para empezar:

1. Si existe, pruébalo.
2. Si hay datos introducidos por el usuario, no te fíes de ellos.
3. Si hay un inicio de sesión de usuario, protéjalo contra ataques de fuerza bruta y de relleno de credenciales.
4. Ten en cuenta la necesidad de mantener y aplicar parches a los sistemas y servicios en los que se sustenta tu API. Sus vulnerabilidades también afectan a tu API.

Mantente a salvo ahí fuera.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie