En un entorno cada vez más interconectado, las APIs desempeñan un papel fundamental al facilitar la comunicación y el intercambio de datos entre diferentes aplicaciones y servicios. Sin embargo, debido a su naturaleza expuesta y su amplio acceso, las APIs se convierten en un objetivo atractivo para los atacantes. Por lo tanto, es crucial asegurar que tus APIs estén protegidas adecuadamente y sean inmunes a posibles ataques y vulnerabilidades.
Nuestro objetivo principal es identificar posibles debilidades en tus APIs, descubrir vulnerabilidades y ayudar a fortalecer la seguridad de tu sistema. Al realizar pruebas de penetración exhaustivas, podremos evaluar la resistencia de tus APIs ante distintos escenarios de ataque, garantizando la confidencialidad, integridad y disponibilidad de los datos que se transmiten a través de ellas.
Metodología de las pruebas de penetración
Nuestro enfoque se basa en una metodología rigurosa y ampliamente reconocida. Comenzaremos por realizar una revisión exhaustiva de tus APIs, comprendiendo los diferentes puntos de entrada y funcionalidades disponibles. A continuación, procederemos a identificar posibles vectores de ataque, analizando aspectos como la autenticación, la validación de entradas, la gestión de sesiones y la protección contra ataques de inyección, entre otros.
Una vez identificados los posibles puntos débiles, procederemos a ejecutar pruebas de penetración utilizando técnicas y herramientas avanzadas. Estos escenarios de ataque simulados nos permitirán evaluar la seguridad de tus APIs y descubrir vulnerabilidades que podrían ser explotadas por atacantes reales. Trabajaremos en estrecha colaboración con tu equipo de desarrollo y seguridad, compartiendo los hallazgos y brindando recomendaciones claras y concisas para abordar las vulnerabilidades identificadas.
¿Qué tipos de pruebas se realizan en un Hackeo a APIs?
Las pruebas que realizamos van en dos direcciones. La primera el OWASP API Top 10 2023:
1. Autorización a nivel de usuario rota: Las APIs suelen revelar puntos finales que gestionan identificadores de objetos, lo que genera una amplia superficie de vulnerabilidad en cuanto al control de acceso a nivel de objeto. Es necesario tener en cuenta las verificaciones de autorización a nivel de objeto en cada función que acceda a una fuente de datos utilizando la identificación del usuario.
2. Autenticación rota: Frecuentemente se cometen errores al implementar los mecanismos de autenticación, lo cual brinda a los atacantes la posibilidad de comprometer los tokens de autenticación o aprovechar fallos en la implementación para asumir temporal o permanentemente las identidades de otros usuarios. Cuando se ve afectada la capacidad de un sistema para reconocer al cliente o usuario, se pone en riesgo la seguridad general de la API.
3. Autorización a nivel de propiedad de objetos rota: Esta categoría fusiona los riesgos API3:2019 de exposición excesiva de datos y API6:2019 de asignación masiva, y se centra en la causa fundamental: la falta de validación o una autorización incorrecta a nivel de propiedad del objeto. Esto resulta en la divulgación o manipulación de información por parte de personas no autorizadas.
4. Consumo de recursos sin restricciones: Para atender las solicitudes de la API se necesitan recursos como el ancho de banda de la red, la CPU, la memoria y el almacenamiento. Los proveedores de servicios ofrecen otros recursos adicionales, como correos electrónicos, SMS, llamadas telefónicas o validación biométrica a través de integraciones API, los cuales se pagan por solicitud. Los ataques exitosos pueden resultar en una denegación de servicio o un incremento en los costes operativos.
5. Autorización de nivel de función rota: Las políticas de control de acceso complicadas, que involucran jerarquías, grupos y roles diversos, y una distinción poco clara entre funciones administrativas y regulares, suelen dar lugar a fallos de autorización. Al aprovechar estas deficiencias, los atacantes pueden obtener acceso a los recursos y/o funciones administrativas de otros usuarios.
6. Acceso sin restricciones a flujos comerciales confidenciales: Las APIs que son vulnerables a este riesgo presentan una exposición en su flujo comercial, como la compra de una entrada o la publicación de un comentario, sin considerar cómo esta funcionalidad podría perjudicar al negocio si se utiliza de forma excesiva y automatizada. Esto no siempre se debe a errores en la implementación.
7. Falsificación de solicitudes del lado del servidor: Las vulnerabilidades de falsificación de solicitud del lado del servidor (SSRF) pueden producirse cuando una API accede a un recurso remoto sin validar adecuadamente el URI proporcionado por el usuario. Esto permite que un atacante manipule la aplicación para enviar una solicitud a un destino inesperado, incluso cuando dicho destino esté protegido por un firewall o una VPN.
8. Configuración incorrecta de seguridad: Las APIs y los sistemas que las respaldan a menudo incluyen configuraciones complejas diseñadas para hacer que las APIs sean altamente personalizables. Sin embargo, los ingenieros de software y DevOps pueden pasar por alto estas configuraciones o no seguir las mejores prácticas de seguridad al configurarlas, lo que puede dar lugar a diversas formas de ataques.
9. Gestión de inventario inadecuada: Las APIs suelen tener una mayor exposición de puntos finales en comparación con las aplicaciones web tradicionales, lo que resalta la importancia de contar con una documentación adecuada y actualizada. Asimismo, es fundamental realizar un inventario completo de los hosts y versiones de API implementadas para mitigar problemas como versiones obsoletas de API y la exposición de puntos finales de depuración.
10. Consumo no seguro de APIs: Los desarrolladores suelen depositar una mayor confianza en los datos recibidos de las APIs de terceros en comparación con las entradas de los usuarios, lo que a su vez los lleva a adoptar estándares de seguridad más débiles. Para comprometer las APIs, los atacantes suelen enfocarse en los servicios integrados de terceros en lugar de intentar comprometer directamente la API objetivo.
La segunda vertiente va más allá de OWASP, por ejemplo, la siguiente lista sin limitarse a:
- OWASP API Top 10 2019, 2013, no porque ya no aparezcan en el nuevo Top 10 quiere decir que ya no sucedan en la actualidad simplemente quiere decir que ya no son tan frecuentes.
- Authentication Vulnerabilities.
- Directory Traversal.
- Business Logic Vulnerabilities.
- Informacion Disclosure.
- Access Control.
- File Upload Vulnerabilities.
- XML External Entity Attack (XXE).
- Cross-Site Request Forgery (CSRF).
- Insecure Direct Object Reference (IDOR).
- Cross-Origin Resource Sharing (CORS).
- Cross-Site Scripting (XSS).
- Clickjacking.
- DOM-Based Vulnerabilities.
- WebSockets.
- Insecure Deserialization.
- Serve-Side Template Injection.
- Web Cache Poisoning.
- HTTP Host Header Attack.
- HTTP Request Smuggling.
- OAuth Authentication.
- Subdomain TakeOver.
- Y muchas más vulnerabilidades que sean descubiertas.
¿Qué informes se entregan después de un PenTest Web?
Klbrs entrega dos informes, uno ejecutivo y uno técnico, los cuales se entregan preferiblemente en dos sesiones distintas,
pues cada uno tiene diferente audiencia y propósito:
Informe Ejecutivo:
Cómo se puede intuir en el nombre, el informe ejecutivo se entrega a los ejecutivos de la organización y se explica en lenguaje no técnico los riesgos identificados y la mejor forma de solucionarlos. De esta forma
la alta dirección podrá tomar decisiones informadas y aplicar sus presupuestos basado en riesgos.
Informe Técnico:
El informe técnico se entrega al área de sistemas de la organización, donde se explica en detalle cada vulnerabilidad identificada, cómo se identificó y cuál es la mejor manera de solucionarlas. Con esta información
la parte técnica podrá resolver los riesgos con base en la retroalimentación que brindan nuestros ingenieros, la alta dirección y sus objetivos y experiencia propia para que la organización saque el máximo provecho de las pruebas.
Siempre tratamos de ir más allá de una simple recomendación de libro, nos tomamos el tiempo de conocer a la organización, su tecnología y los retos a los que se enfrentan para recomendar las mejores soluciones
y damos seguimiento a las vulnerabilidades encontradas. Además tienes acceso a nuestro boletín mensual de clientes donde damos más consejos de seguridad, cursos de concienciación, cursos prácticos de herramientas,
descuentos con nuestros socios, etc.
¿En qué provincias de España prestamos servicio?
A pesar de estar basados en Madrid podemos presentar servicio en cualquier provincia del país, siempre y cuando puedan descargar una máquina virtual y darnos el acceso para podernos conectar y realizar las pruebas necesarias.
¿Podemos realizar pruebas fuera de España?
Sí claro, hemos realizado pruebas en diversos países de Latinoamérica, Estados Unidos, Asia y Europa.
