Si tienes una situación con una aplicación web y no sabes por dónde empezar, este hilo puede serte muy útil. Vamos a hablar de las diferentes fases de un pentesting de aplicaciones web y explorar una metodología específica para utilizar como referencia. Desde la parte de reconocimiento hasta un enfoque en cada aspecto de la aplicación y su arquitectura.
Reconocimiento: En esta fase, vamos a centrarnos en reconocer qué nos ofrece la aplicación, sus puntos de entrada, y si hay otras aplicaciones en el servidor web e incluso sus metadatos.
Nuestro objetivo es identificar cualquier información relevante sobre la aplicación:
- Google Hacking para identificar posibles contraseñas o archivos antiguos.- Identifica la versión y otra información importante del servidor web.
- Identificar dónde puede enviar datos el usuario.
- Obtener información sobre el marco implantado.
- Obtener una visión de la arquitectura externa (a nivel de infraestructura)
- Saber si se está utilizando una API Rest, SOAP, GraphQL, etc.
- Saber si se trata de una implantación local o en la nube.
Mecanismos de autenticación: Este enfoque va a ser clave, ya que muchas de las aplicaciones ofrecen mucha más funcionalidad una vez que el usuario se autentica. Por lo tanto, necesitamos entender cómo funciona este proceso y qué tipos de mecanismos ofrece (enlaces mágicos, SSO, correo electrónico, implementación de un segundo factor de autenticación). Por último, pero no menos importante, es clave entender cómo es el proceso de registro, así como el proceso de recuperación de la cuenta.
Otro aspecto importante a tener en cuenta en esta fase es comprender las funciones que ofrece la aplicación para realizar movimientos laterales y horizontales. Otras tareas interesantes para analizar en esta fase son:
- Políticas de contraseñas.
- Capacidad para realizar ataques de fuerza bruta.
- Existencia de cuentas/contraseñas autogeneradas o por defecto.
- Análisis del funcionamiento de Remember Me.
- Posibilidad de saltarse el 2FA restableciendo las contraseñas.
- Analizar cookies o testigos de sesión.
- Identificar tokens de aplicaciones, como CSRF.
- Identificar los IDOR (¿puede el usuario A acceder a los datos del usuario B?)
Validación de datos: El aspecto más importante de un sitio web es aquel en el que el usuario debe introducir datos en la aplicación. Esto hará que responda de forma diferente y ofrecerá nuevas funciones para seguir interactuando. Por lo tanto, los puntos de entrada merecen nuestra atención. Si la aplicación no sanea los datos entrantes , es muy probable que un usuario pueda enviar información maliciosa y explotar vulnerabilidades típicas, como Cross-Site-Scriptings o SQL Injections.
Hay muchas vulnerabilidades anidadas en la introducción de datos por parte de los usuarios. Estas son las más conocidas:
- inyecciones SQL (identificar conexiones a bases de datos para buscar información o, por ejemplo, en mecanismos de autenticación)
- Cross-Site-Scriptings (comprobar dónde se refleja la información enviada por el usuario).
- Inyecciones LDAP/XML/SSTI (comprender qué tipo de datos se envían a la aplicación y, en función de los resultados, explotar esta tecnología).
- Inyección de código (identificar funciones que potencialmente realizan llamadas al sistema operativo)
- Contrabando HTTP/Request
Lógica empresarial: Las fases anteriores se pueden prevenir fácilmente utilizando ORMs y siguiendo las mejores prácticas de desarrollo, o incluso utilizando un Web Application Firewall (WAF). Por lo tanto, entender la lógica de negocio y los flujos de la aplicación es clave a la hora de hacer un pentest. En nuestra experiencia, las vulnerabilidades más graves se identifican en esta fase, ya que están ligadas al núcleo del negocio.
Esta etapa dependerá mucho de lo que se esté auditando. Esto hará que las pruebas cambien radicalmente. A continuación, hay una serie de recomendaciones generales a tener en cuenta a la hora de realizar las pruebas:
- Utiliza fondos inexistentes o superiores a los que tienes.
- En un comercio electrónico, pruebe los métodos de pago (a veces se reflejan como una identificación) que no están implementados.
- Compras de prueba a precio 0.
- Intenta saltarte pasos.
- Muchas aplicaciones tienen límites de tiempo para las operaciones, intenta hacer pruebas de saturación.
- Intento de cargar archivos que la aplicación no espera.
Del lado del cliente: Según nuestra experiencia, a veces la mayoría de los controles están a nivel del cliente y no del servidor. Esto es extremadamente fácil de probar utilizando, por ejemplo, un proxy. Además, muchas aplicaciones dentro del código JavaScript o la tecnología que utilizan en el lado del cliente exponen credenciales, rutas internas o lógica de negocio que a veces no es visible a menos que inspeccione el código.
