Header Ads Widget

Ticker

6/recent/ticker-posts

Soluciones basadas en identidad y abuso de API móviles

 


Las amenazas de API están a nuestro alrededor. Los ciberataques están aumentando y cada día vemos nuevos informes de exploits en los titulares. Estas vulnerabilidades podrían dejar a una empresa expuesta a los piratas informáticos, que pueden aprovechar las API para atacar y anular sistemas o hacer un mal uso de los datos del usuario. Y a medida que aumenta el valor de las API en nuestra vida diaria, estos puntos de contacto se vuelven cada vez más críticos.

Las API también son el núcleo de muchas aplicaciones móviles . Hoy en día, gracias a los diseños de desarrollo independientes del cliente, la mayoría de las aplicaciones móviles se comunican con una API interna como backend. Pero si se ve comprometida, dicha conexión podría ser desastrosa, especialmente para sectores sensibles, como la banca en línea .

Entonces, ¿cuáles son algunas de las amenazas más comunes que enfrentan nuestras API? Bueno, OWASP hace un buen trabajo al enumerar las principales vulnerabilidades en esta área. Los problemas comunes incluyen inyección, autenticación rota, sobreexposición de datos, control de acceso roto, configuraciones incorrectas, administración inadecuada de activos, etc.

Curiosamente, muchas amenazas de API se reducen a un problema con los permisos y el acceso: ¿Quién es la parte solicitante? ¿Se les permite acceder a estos datos? ¿Qué prueba pueden ofrecer para demostrar quiénes dicen ser? Muchos en el espacio de las API argumentan que un mayor énfasis en cómo manejamos la identidad del cliente   podría ayudar a solucionar muchas de estas amenazas. Este es un tema que cubrimos ampliamente en nuestro libro electrónico, identidad y API .

Entonces, en nuestro evento complementario, LiveCast: Identidad y API , incorporamos a dos expertos en seguridad de API. David Stewart , Approov , cubrió las amenazas y vulnerabilidades modernas de API que existen dentro del espectro móvil y otros entornos. Jacob Ideskog , Curity , también trazó la historia de la seguridad basada en la identidad y examinó el papel de los estándares de identidad dentro de nuestras medidas de seguridad.

 

¿Qué es el abuso de API?

Cuando hablamos de abuso de API, nos referimos a algún tipo de acceso no autorizado con intenciones nefastas. Los piratas informáticos abusan de las API por muchas razones: podría ser para acceder a una cuenta bancaria y liquidar su contenido. Podría ser para lavar fondos ilegales, extraer datos de un sitio minorista o abrumar los servidores.

Acciones aparentemente menos dañinas aún podrían afectar el negocio. Por ejemplo, supongamos que un pirata informático utiliza un campo de API expuesto para abrir una nueva cuenta en un sitio de transmisión para capturar recompensas. Un caso de uso único puede no afectar mucho las cosas, pero un bot que automatice esto en miles de cuentas podría causar serios problemas. “Si hay una forma de jugar con el sistema o causar problemas, alguien lo hará”, dijo Stewart.

Una cosa oscura sobre trabajar en seguridad API es que siempre hay muchos ejemplos de hacks de los que sacar, bromeó Stewart. Recientemente, un pirata informático utilizó un punto final "privado" de  Mcdonald's para crear un mapa de los restaurantes con máquinas de helado rotas. Si bien esto puede parecer inocente y bastante divertido, daña la reputación de la marca. (Las empresas a menudo asumen indocumentado = privado, pero obviamente este no es el caso).

Se dispara la actividad móvil y digital

Los dispositivos móviles son una vulnerabilidad clave y un canal importante que proteger, dijo Stewart, especialmente porque estas aplicaciones podrían tener acceso a una gran cantidad de datos comerciales. Sin embargo, con el móvil, es difícil rastrear la fuente de la persona que llama. “El canal móvil es la API más difícil de proteger”, dijo Stewart. "Cualquier transacción de API que provenga de una aplicación móvil no es confiable".

Según Stewart, es importante considerar la identidad de la organización y no necesariamente solo quién . Cuando se trata de dispositivos móviles, debe mantener fuertes límites de API, tener cuidado con los bots y demostrar más allá de toda duda que los clientes están autenticados antes de manipular los datos del usuario.

"Incluso si su API no tiene ninguna vulnerabilidad, aún pueden abusar de usted", dijo Stewart. El tráfico podría estar emulando una fuente sin que necesariamente explote una vulnerabilidad en la API. Observa una amplia gama de scripts y entornos que se utilizan para llamar a las API. "¿Cómo se puede saber si un script lo está usando en comparación con las llamadas API genuinas?"

Los problemas relacionados con el abuso de las API móviles se están acelerando a raíz de la pandemia de COVID-19 . Un estudio reciente de McKinsey & Company encontró que el tráfico móvil aumentó a tres años antes de lo proyectado para 2020. Las transacciones digitales se han acelerado en todos los ámbitos, afectando a todos los sectores. Stewart ha notado un aumento constante en el tráfico móvil general para FinTech, Retail y un crecimiento explosivo en la atención médica en los últimos meses (también notó una caída significativa en las transacciones de transporte, lo cual tiene sentido).

En paralelo a este crecimiento, el abuso de API en escenarios móviles es desenfrenado. "El abuso ha aumentado proporcionalmente, si no más", dijo Stewart. Entonces, ¿cómo pueden las empresas repeler los ataques?

Plan de 5 pasos para proteger las API móviles

Para asegurar el canal móvil, Stewart recomienda un plan de 5 pasos. Estos consejos de seguridad podrían ampliarse fácilmente para proteger también otros casos de uso de API.

1. Bloquear bots maliciosos y scripts automatizados : el tráfico de bots es el mecanismo más común para abusar de las API. Para bloquear el uso automatizado, proteja las claves API a escala y demuestre que proviene de una instancia de aplicación genuina.
2. Rechazar aplicaciones que se ejecutan en entornos comprometidos : compruebe continuamente si las solicitudes se originan en entornos inseguros.
3. Llamadas API seguras : utilice la seguridad TLS y siga otras prácticas recomendadas de seguridad .
4. Autorice las acciones del usuario en el contexto de la aplicación : la autenticación de los usuarios es importante, pero no suficiente. Si autentica tanto al usuario como a la aplicación, disminuye significativamente el espacio de ataque.
5. Mantenga las capacidades de seguridad actualizadas con las amenazas emergentes: Agregue una capacidad por aire que busque controles ambientales y agregue nuevas detecciones de amenazas automáticamente.

Siguiendo estas pautas, Stewart cree que puede reducir las posibilidades de lo que pueden hacer los sombreros negros en un 90%. "Realmente necesita saber qué está usando su API, porque eso le permite diferenciar entre instancias de aplicaciones móviles genuinas en un buen entorno y algo que no lo está".

Explosión móvil y OAuth 2.0

Considere lo lejos que ha avanzado el desarrollo de aplicaciones móviles en la última década. Si recuerda, 2012 realmente vio una explosión de aplicaciones móviles: iOS tenía alrededor de 750,000 aplicaciones mientras que Android tenía alrededor de 600,000 aplicaciones. Simultáneamente, el universo API comenzó a expandirse. En este período, el cliente se volvió más delgado y la comunicación de la aplicación a la API de backend se volvió muy popular para las aplicaciones internas y de terceros.

A medida que las API se convirtieron en la esfera pública, 2012 también fue el año en el que se ratificó OAuth 2.0 . La comunidad de IETF diseñó OAuth para ser la respuesta para lograr que una aplicación se comunique con una API de una manera que conozcamos la aplicación y el usuario. OAuth define un proceso de uso de tokens de acceso para enviar esta información y delegar el acceso entre las partes.

Pero, como describió Ideskog, OAuth 2.0 no era perfecto. Los tokens de acceso tenían deficiencias y la especificación OAuth simplemente no se creó para todos los casos de uso, como las aplicaciones de una sola página . Hoy en día, un cliente podría ser un teléfono móvil, un navegador, un televisor, un servidor, un quiosco, un dispositivo IoT y otros tipos de dispositivos , lo que complica aún más los estándares de gestión de acceso. Las condiciones para cada dispositivo y servicio pueden variar extraordinariamente. Un servicio bancario puede tener una estrategia de administración de acceso muy diferente a una API de clima abierto, explicó Ideskog.

Afortunadamente, OAuth ofrece flexibilidad. "Está realmente diseñado como un marco", dijo Ideskog. "Está destinado a ser construido y mejorado". Sin embargo, la flexibilidad es un arma de doble filo ...

Especificaciones Grow

A medida que más empresas buscaban adoptar OAuth, comenzaron a complementarlo con otras especificaciones para otros casos de uso. Por ejemplo, se ha  introducido PKCE , una extensión del flujo del Código de autorización, junto con muchas otras extensiones OAuth . Los proyectos más nuevos como  OAuth.xyz se basan en una década de uso de producción de OAuth 2.0.

Estos esfuerzos han hecho que OAuth sea más portátil. Pero, si la especificación base de OAuth tiene otras 30 interpretaciones en la parte superior, fácilmente nos encontramos con problemas de interoperabilidad . OAuth 2.1 busca fusionar todas estas especificaciones relevantes en una sola especificación. Agruparlos podría mejorar la interoperabilidad, que “es importante para asegurar en toda la industria”, dijo Ideskog.

+ OpenID Connect para autenticación

OAuth ha sido fundamental para delegar el acceso a las API móviles. Sin embargo, omite "quién eres". Entonces, los autenticadores han sido una forma de responder a esta pregunta. Los métodos de autenticación incluyen SMS, verificación de correo electrónico, inicio de sesión de Facebook y otros. Originalmente, no existía un estándar que cubriera todas estas medidas de autenticación.

OpenID Connect ha surgido como una forma de unificar cómo iniciar y finalizar el flujo de autenticación. Proporciona una forma estándar de solicitar un inicio de sesión, una forma estándar de compartir y federar la información del usuario mientras permite que OAuth funcione debajo. Tener un estándar ayuda a atender los esquemas de autenticación de múltiples factores, que pueden involucrar escenarios de autenticación sin contraseña, como aplicaciones biométricas, llaveros o aplicaciones de autenticación.

Autenticación basada en API de hipermedia

Como describió Ideskog, "la autenticación es un viaje del usuario". Aunque existen entornos móviles y otros entornos matizados, el espacio de seguridad todavía está colgado en los navegadores. Sin embargo, los desarrolladores de dispositivos móviles no prefieren el navegador. Entonces, ¿cómo podemos confiar en las aplicaciones móviles como lo hacemos en el navegador?

Para construir un mecanismo de autenticación independiente de la plataforma y el dispositivo, Ideskog aboga por los hipermedia . Básicamente, tratar la autenticación en sí misma como una máquina de estado . Hypermedia, como saben muchos RESTafarians, es la base de las verdaderas API REST. Las API compatibles con hipermedia presentan enlaces en tiempo de ejecución en la respuesta de la API, lo que permite que la respuesta dicte procesos adicionales.

Si la autenticación impulsada por API, o el uso de API para resolver problemas de seguridad de API, le suena un poco meta, no está solo. Independientemente, este método podría ser clave para mejorar la reutilización con un estándar común en todos los casos de autenticación.

Reflexiones finales: una década en la seguridad de las API

Seguro que las empresas han avanzado mucho en sus esfuerzos de ciberseguridad. Hoy en día, proteger una empresa protegiendo su perímetro no tiene mucho sentido. "¿Dónde está el perímetro?" pregunta Stewart.

Ahora, en 2020, se estima que hay 2,2 millones de aplicaciones de iOS  2,7 millones de aplicaciones de Android  disponibles para los usuarios. La necesidad de una gran seguridad API en la esfera móvil se ha convertido en una preocupación omnipresente y debemos empezar a escuchar a los desarrolladores de dispositivos móviles.

La pandemia ha provocado un aumento del tráfico móvil y las actividades de los atacantes han aumentado en conjunto. Los días de los piratas informáticos solitarios que usaban sudaderas con capucha han terminado; ahora nos enfrentamos a operaciones de ciberataques altamente sofisticadas y bien financiadas. Las aplicaciones necesitan políticas de seguridad  para detectar la suplantación de identidad y garantizar que las solicitudes de API no solo emulan el comportamiento real.

Históricamente, el aumento en el uso de dispositivos móviles está íntimamente ligado tanto al aumento de la economía API como a los estándares de identidad relevantes. Pero el concepto de dispositivo se ha expandido. El desarrollo y la educación continuos para fomentar una mentalidad de seguridad serán fundamentales en el futuro.

Con muchos dispositivos nuevos y procesos de acceso variables, el espacio de estándares de administración de acceso ha estado luchando por mantenerse al día. Es de esperar que OAuth 2.1 pueda consolidar estas nuevas extensiones para aumentar la interoperabilidad. Además, el enfoque de autenticación propuesto basado en API podría contribuir en gran medida a lograr una plantilla de autenticación reutilizable. Por lo tanto, realmente habilita un paradigma de cualquier dispositivo y autenticación.

Publicar un comentario

0 Comentarios