Over 10 years we help companies reach their financial and branding goals. Engitech is a values-driven technology agency dedicated.

Gallery

Contacts

411 University St, Seattle, USA

+1 -800-456-478-23

Auditoría
BLOG-img-web-cloudappi-seguridad

Estrategias y soluciones para mitigar las vulnerabilidades

API Owner Fundamentals

Bienvenidos al tercer blog de la serie del API Owner Fundamentals de la Fundación APIAddicts, curso pionero en su certificación y que este año ha sido realizado por algunos de nuestros warriors.

Hoy hablaremos de la Seguridad en las APIs, su importancia y los aspectos a tener en cuenta para evitar fallos cruciales. Así que comencemos por el principio…

¿Por qué es tan importante la seguridad en las APIs?

Con la evolución hacia las APIS, los problemas de seguridad que aparecen son distintos.

BLOG-icon-web-cloudappi-14

No se trata de una aplicación de escritorio o un servlet que esté sirviendo la información, sino que un servidor da punto de entrada que me permiten exponer información. Las metodologías identificadas para servir a la seguridad de los sistemas tradicionales no sirven para este nuevo formato de: Distintas tecnologías llevan a problemas diferentes.

Una buena praxis es considerar las APIs como abiertas, no en el sentido de que puede consumirlas cualquiera, sino que se trata de una dirección y un puerto accesibles desde la internet. Aunque no estén publicadas o expuestas y requieran de algún tipo de credenciales son accesibles para cualquier conectada a la red de redes.
En materia de seguridad se dice que el riesgo 0 no existe, sino que existen diferentes grados de riesgo. Incluso para un API que se define para consumo únicamente interno también presenta riesgo. La gestión de seguridad se basa en conocer y proteger los diferentes canales. En el ámbito de la seguridad el paradigma cambia ya no se trata de generar un perímetro para proteger los sistemas, sino proteger los datos en sí.

APISECURITY-CLOUDAPPI

OWASP TOP 10

Este documento seguirá este TOP 10 recogido por la OWASP como esqueleto para explicar brevemente las posibles correcciones, buenas prácticas y brechas que existen al realizar un desarrollo utilizando la tecnología API.

Principios de seguridad

1. Si no conoces, no proteges

2. Las APIs internas deben ser tratadas como si fueran públicas

3. Marcar el nivel de sensibilidad y asegurar el control en el acceso de nuestras entradas a los diferentes datos

Trump es un actor poderoso, pero hasta a él le hackearon la cuenta de Twitter y por lo visto aumentó la calidad de su lenguaje por un breve periodo de tiempo. Esto se debe a que el sistema de Twitter tenía una brecha al haber permitido que ciertos usuarios fueran “super superadmin”. Un usuario con capacidad hasta para escribir tweets como si fuera otro usuario. Mediante la coacción de uno de los usuarios con este nivel de privilegios, se hizo sencillo para los crackers hacerse pasar por él. 

4 Riesgos de Seguridad

1. Protección de datos

APISECURITY-2-blog

Puntos a revisar para cuidar este tipo de riesgo en datos es los resets de las credenciales, tener claro que codificado no es equivalente a encriptado (sí un dato puede estar bajo las dos transformaciones).

Y, en especial, desde el principio del proyecto API asegurar que la arquitectura sea basada en datos acotados, es decir, siguiendo las necesidades esperadas por el cliente.

En el diagrama siguiente vemos que una API responde con los datos que necesita el usuario (círculos verdes) pero envía también datos que no son necesarios para las funciones del cliente (circulo rojo). Esto permite llegar a información que en sí misma no se debería tener acceso desde un endpoint específico, pero además, también podría servir para acceder a credenciales (caso UBER).

Esto ocurre a menudo, si se piensa solo en el formato de entrada de un sistema que está cerrado y es bien conocido sin valorar la diferente casuística que puede producirse. Para que esto no nos ocurra es importante conocer el formato de entrada de los datos. En el diagrama siguiente la bola roja identifica el dato inesperado.

BLOG-img-web-cloudappi-13
INJECTION-1-blog

2. Authorization

A nivel de autorización se identifica en el ranking de la OWASP brecha la conocida como BOLA o Broken Object Level Access Control. Se debe a que un usuario puede llegar a obtener información sin necesidad de autenticarse dentro del sistema.

Suele estar relacionado con que el acceso a los datos de los diferentes endpoint son sencillos de adivinar, por ejemplo una secuencia numérica. De tal modo que si conozco cómo acceder a cierto endpoint me es sencillo llegar a otro.
Si no se está controlando el número de peticiones que lleva a cabo un usuario, es sencillo que este pueda probar hasta encontrar una relación entre los endpoints que le permitan llegar a información a la que no debería tener acceso.
AUTHORITATION-blog

3. Authentication

TLS

Normal TLS: Me conecto a través de un navegador, éste revisa el TLS del servidor al que intento conocerme. El navegador mira al servidor. revisa su certificado y si confía en él: . se conecta 

Mutuo TLS: Además de lo anterior, el servidor exige un certificado y realiza el mismo procedimiento que el navegador para permitir la conexión.

En ambos casos existen los llamados Certificator Authority, que emiten el documento que certifica la autenticidad de “quién soy”.

JWT

El JSON web token se trata de un sistema de securización pero cuenta con algunos problemas derivados del mal uso (no se encripta) o de problemas que ha mostrado la tecnología. Como que todos los JWT con la definición de un campo a None permitía padar el payload.

OAuth

El usuario y la contraseña no son un buen sistema de autenticación, es codificado no encriptado. Del mismo modo el OAuth token prueba que tienes la llave de acceso no quién eres, algo así como la tarjeta de hotel. OAuth no es una prueba de quién está llamando: yo soy “Joni” y quiero acceder a mis recursos. Un Token como el Basic o el Bearer es más costoso para el consumidor, se pasa el secret pero da más seguridad que el OAuth.

4. Rate Limit

Relacionado con esto, se comienza a considerar inseguro el sistema con SMS, ni tampoco los parámetros de los headers o queries por poder encontrarse sin problema en los logs.

Conclusiones

Además es un factor fundamental que debemos tener en cuenta durante todo el proceso de APIficación. Hay que pensar en cómo hackear nuestros propios sistemas para poder estar preparados para todo y machacar con lo que no estamos esperando, solo así podremos proteger los datos más sensibles.

// ¿Quieres mejorar la seguridad de tus APIs?

¡Habla con nuestros expertos!

Leave a comment

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *