¿Qué es una Prueba de Penetración Web o PenTest Web?
Una prueba de penetración web o un PenTest a aplicaciones web es un ejercicio que consiste en encontrar vulnerabilidades en
sitios web públicos y privados empleando técnicas que emplean los atacantes en tecnologías Web.
Básicamente consiste en "hackear" el sitio o aplicación web de las organizaciones antes de que un atacante lo haga y
dependiendo de lo que se encuentre se dan una serie de recomendaciones para eliminar o reducir las vulnerabilidades
encontradas.
¿Qué tipos de pruebas se realizan en un Hackeo Ético a aplicaciones Web?
Las pruebas que realizamos también llamadas Test de Penetración van en dos direcciones. La primera el OWASP Top 10 2023:
1. Control de acceso fallido (Broken Access Control): Las restricciones sobre lo que pueden hacer los usuarios autenticados a menudo no se aplican correctamente. Los atacantes pueden aprovechar estos fallos para tener acceso a funciones y / o datos no autorizados como, acceder a las cuentas de otros usuarios, ver archivos confidenciales, modificar los datos de otros usuarios, cambiar los derechos de acceso, etc.
2. Fallos criptográficos (Cryptographic Failures): Ocurren cuando los datos en tránsito o almacenados pueden ser vistos en texto claro, no se ha hecho la implementación de controles de cifrado o se han implementado algoritmos criptográficos débiles u obsoletos. Los atacantes pueden realizar distintos ataques, desde interceptar el tráfico poniendo en riesgo los datos del usuario hasta descifrar contraseñas obtenidas de una base de datos atacada.
3. Inyección (Injection): Los fallos de inyección, como la inyección de SQL, NoSQL, Command Injection y LDAP, ocurren cuando se envían datos que no son de confianza a un intérprete como parte de un comando o consulta. Los datos hostiles del atacante pueden engañar al intérprete para que ejecute comandos no deseados o acceda a los datos sin la debida autorización.
4. Diseño inseguro (Insecure Design): Al diseñar una aplicación web no se ha implementado un plan de seguridad desde el inicio del desarrollo, lo que da paso a vulnerabilidades en la propia naturaleza de la aplicación. Puede ser que la implementación sea completamente segura, pero si en la construcción del mismo desarrollo no se han considerado los riesgos a los que podría estar expuesto, sería un objetivo relativamente fácil para los atacantes.
5. Configuración incorrecta de seguridad (Security Misconfiguration): La mala configuración de seguridad es el problema más común. Esto suele ser el resultado de configuraciones predeterminadas inseguras, configuraciones incompletas o ad hoc, almacenamiento en la nube abierta, encabezados HTTP mal configurados y mensajes de error detallados que contienen información confidencial. No solo se deben configurar de forma segura todos los sistemas operativos, marcos, bibliotecas y aplicaciones, sino que también se deben parchear / actualizar de manera oportuna.
6. Componentes vulnerables u obsoletos (Vulnerable and Outdated Components): La aplicación puede tener componentes que estén desactualizados, su ciclo de vida haya terminado, tengan vulnerabilidades, entre otras más, esto representa un riesgo tanto para el correcto funcionamiento de la aplicación como para los datos procesados y almacenados en ella; este tipo de componentes pudieran ser, sistemas operativos, librerías, dependencias, API’s, framework’s, por mencionar algunos.
7. Errores de identificación y autenticación (Identification and Authentication Failures): Cuando las funciones encargadas y relacionadas con la autenticación, administración de sesiones o verificación de identidad de los usuarios no están correctamente implementadas, ya sea por no existir protocolos de autenticación o la protección de ellas es ineficiente, la aplicación web corre el riesgo de sufrir ataques relacionados con estas vulnerabilidades o errores. Los usuarios podrían ser víctimas de robo de sesiones, denegaciones de servicio o robo de identidad, entre muchos más.
8. Fallos en la integridad del software y los datos (Software and Data Integrity Failures): Si la aplicación web actualiza automáticamente sus dependencias, bibliotecas, plugins, etc; sin que las fuentes de donde las obtienen sean correctamente verificadas, representa un riesgo de que los atacantes puedan tener acceso no autorizado, inyectar código malicioso o comprometer el sistema.
Así mismo, la aplicación web puede quedar vulnerable a deserialización insegura que a menudo conduce a la ejecución remota de código. Incluso si los fallos de deserialización no dan como resultado la ejecución remota de código, se pueden usar para realizar ataques de replay, de inyección y de escalada de privilegios.
9. Bitácoras y monitoreo de seguridad insuficientes (Security Logging and Monitoring Failures): El registro y la supervisión insuficientes, junto con la falta o la integración ineficaz de la respuesta a incidentes, permiten a los atacantes vulnerar aún más los sistemas, tener acceso a otros recursos en la infraestructura de la aplicación, mantener la persistencia, manipular, extraer o destruir datos. La mayoría de los estudios de infracciones muestran que el tiempo para detectar un incidente de seguridad o ‘hackeo’ es de más de 200 días, generalmente detectados por partes externas en lugar de procesos internos o monitoreo.
Esto además de poner en riesgo los datos de la organización como de los usuarios, pone en riesgo la reputación de dicha organización y en casos donde se maneje información sensible se podría ser acreedor a multas y sanciones.
10. Server-Side Request Forgery (SSRF): Esta vulnerabilidad ocurre cuando una aplicación web permite a los usuarios enviar recursos del lado del servidor, como lo es una URL sin que estos sean validados correctamente. Aunque la aplicación web este detrás de un WAF, u otro recurso de control de acceso, esto no impide que pueda ser comprometida la aplicación y/o el servidor. Un atacante puede aprovechar esta vulnerabilidad para hacer escaneos de puertos abiertos, enumeración de servicio o usuarios y en casos más graves ejecución de código remoto y escalada de privilegios.
La segunda vertiente va más allá de OWASP, por ejemplo, la siguiente lista sin limitarse a:
- CWE Top 25, OWASP Top 10 2017, 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.
¿Cuál es el coste de una Prueba de Penetración Web o Pentesting Web?
El coste varía de acuerdo al tamaño, tecnologías y complejidad de la aplicación. Contáctanos para más información.
¿Qué informes se entregan después de un PenTest Web?
Klbrs entrega dos informes, uno ejecutivo y uno técnico. Los cuales se entregan de preferencia 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 a 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 podemos dar servicio?
A pesar de estar basados en Madrid podemos presentar servicios a 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.