API Security Hardening, como prevenir el Data Leak.

Actualizado: 30 de nov de 2018

Una API (Interfaces de programación de aplicaciones) es una especificación formal sobre cómo un módulo de un software se comunica o interactúa con otro. Corresponde a un conjunto de comandos, funciones y protocolos informáticos que permiten a los desarrolladores crear programas específicos simplificando en gran medida el trabajo ya que no tienen que escribir el código desde cero.

Con las API, las aplicaciones como Facebook, Twitter, e Instagram se pueden comunicar entre ellas sin que el usuario tenga que intervenir o incluso, percatarse.

Por ejemplo, cuando el usuario compra entradas a través de la página web de una sala de cine e introduce la información de su tarjeta de crédito, la web usa una API para enviar dicha información de forma remota a otro programa que verifica si los datos bancarios son correctos. Una vez que se confirma el pago, la aplicación remota envía la información al sitio web del cine y le da un «OK», por lo que esta página emite los tickets.

Sin embargo, muchas empresas ponen en producción API’s sin realizar las comprobaciones necesarias sobre su desarrollo, lógica de negocio y/o su seguridad.

Según nuestra experiencia en servicios de Pentesting y noticias recientes, podemos asegurar que una de las vulnerabilidades más importantes a nivel de impacto recae en las API, un ejemplo claro son las últimas brechas de seguridad a empresas importantes como:

• USPS de Amazon: 60.000.000
• Facebook: 50.000.000 cuentas
• Equifax: 143.000.000 cuentas
• T-Mobile: 2.000.000 cuentas
• Instagram: 6.000.000 cuentas
• Google+: 500.000 cuentas
• Paypal Venmo: 207.984.218+ transacciones
• Under Armour: 150.000.000 cuentas

Y muchos otros como Twitter, Blizzard, SalesForce, Ticketmaster, etc.

Tanto así que OWASP TOP 10 en su versión 2017 agrego:

En Chile también tenemos casos conocidos (uno en la Banca, otro en un servicio de Correo y el ultimo en una distribuidora de materiales de construcción), pero indudablemente hay muchos otros que están expuestos y seguramente aún no se han percatado.

A continuación comparto una serie de recursos y guías de buenas prácticas para que puedan revisar más información sobre como proteger y maximizar la seguridad de sus API.

API Security Checklist:

(Estaba escribiendo el checklist y llegue a este recurso que esta muy bueno)
https://github.com/shieldfy/API-Security-Checklist

Autenticación

1. No uses Basic Auth Usa autenticación estándar (e.g. JWT, OAuth).
2. No reinventes la rueda en autenticación, generación de tokens, almacenamiento de contraseñas. Usa los estándares.
3. Usa políticas de límite de reintentos (Max Retry) y funcionalidades de jailing en el Login.
4. Usa encriptación en toda la información que sea sensible.

JWT (JSON Web Token)

1. Usa claves aleatorias complejas (JWT Secret) para dificultar los ataques por fuerza bruta.
2. No extraigas el algoritmo del contenido. Fuerza el algoritmo en el backend (HS256 o RS256).
3. Haz que la expiración del token (TTL, RTTL) sea tan corta como sea posible.
4. No almacenes información sensible en el contenido del JWT, puede ser descodificado fácilmente.

OAuth

1. Siempre valida redirect_uri en el lado del servidor para permitir sólo ciertas URLs.
2. Trata siempre de intercambiar código y no tokens (no permitas response_type=token).
3. Usa el parámetro state con un hash aleatorio para prevenir CSRF en el proceso de autenticación OAuth.
4. Define el ámbito (scope) por defecto, y valida los parámetros de ámbito para cada aplicación.

Acceso

1. Limita las peticiones (Throttling) para prevenir ataques DDoS y de fuerza bruta.
2. Usa HTTPS en el lado del servidor para evitar ataques MITM (Man In The Middle Attack).
3. Usa la cabecera HSTS con SSL para evitar SSL Strip attack.

Entradas

1. Usa el método HTTP apropiado a cada operación: GET (lectura), POST (creación), PUT/PATCH (reemplazo/actualización), y DELETE (borrado), y responde con 405 Method Not Allowed si el método en la petición no es apropiado para el recurso.
2. Valida el content-type en la cabecera Accept de las peticiones (Content Negotiation), para permitir sólo los formatos soportados (e.g. application/xml, application/json, etc) y responde con 406 Not Acceptable si no hay coincidencias.
3. Valida el content-type de información enviada en base a la que aceptes (e.g. application/x-www-form-urlencoded, multipart/form-data, application/json, etc).
4. Valida las entradas que realizan los usuarios para evitar ataques comunes (e.g. XSS, SQL-Injection, Remote Code Execution, etc).
5. No utilices información sensible (credentials, Passwords, security tokens, or API keys) en la URL, en su lugar usa la cabecera estándar Authorization.
6. Usa un servicio de API Gateway para permitir almacenamiento en caché (caching), límite de peticiones (Rate Limit), Spike Arrest y el despliegue de APIs dinámicamente.

Procesamiento

1. Valida que todos los endpoints estén protegidos con autenticación para evitar romper el proceso de autenticación.
2. Debes evitar los recursos bajo un ID de usuario. Usa /me/orders en lugar de /user/654321/orders.
3. No uses IDs auto incrementales. Usa UUID en su lugar.
4. Si estas procesando archivos XML, asegúrate de deshabilitar el procesamiento de entidades para evitar ataques XXE (XML external entity attack).
5. Si estas procesando archivos XML, asegúrate de deshabilitar la expansión de entidades, para evitar un ataque Billion Laughs/XML bomb via expansión exponencial de entidades.
6. Utiliza CDN para subidas de ficheros.
7. Si lidias con grandes cantidades de información, utiliza Workers y Colas para procesar tanto cómo sea posible en segundo plano, y devuelve una respuesta rápido para evitar un bloqueo HTTP.
8. No olvides deshabilitar el modo Debug.

Salidas

1. Envía la cabecera X-Content-Type-Options: nosniff.
2. Envía la cabecera X-Frame-Options: deny.
3. Envía la cabecera Content-Security-Policy: default-src ‘none’.
4. Elimina cabeceras que dejen huellas – X-Powered-By, Server, X-AspNet-Version etc.
5. Fuerza content-type para tus respuestas, si devuelves un json entonces tu content-type es application/json.
6. No devuelvas información sensible cómo credenciales, contraseñas, tokens de seguridad.
7. Devuelve el código HTTP acorde a la operación completada. (e.g. 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed, etc).

CI & CD

1. Audita tu diseño e implementación con tests unitarios/integración y test coverage.
2. Usa procesos de revisión de código y evita la auto aprobación.
3. Asegura que todos los componentes de tus servicios se escanean estáticamente con un software AV antes de ir a producción, incluyendo librerías de terceros y dependencias.
4. Diseña un proceso de rollback para tus deploys.

Buenas Practicas:

• https://techbeacon.com/8-essential-best-practices-api-security
• https://www.twistlock.com/2018/06/04/7-api-best-practices/
• https://dzone.com/refcardz/rest-api-security-1?chapter=1
• https://blog.runscope.com/posts/best-practices-api-security-common-vulnerabilities

Y algo muy importante que no aparece en ninguno de los links más arriba….
«HAGAN ETHICAL HACKING».

Saludos.
Germán.

[email protected]