Pruebas de penetración de aplicaciones web
Gjethe prueba las aplicaciones web como las abordan los atacantes: inicios de sesión y sesiones, acceso entre usuarios y roles, tratamiento de entradas, pagos y lógica de negocio. Las pruebas siguen las directrices de OWASP, cada hallazgo incluye evidencias y una corrección, y una nueva prueba confirma que los problemas han desaparecido.
- Primera consulta gratuita
- Presupuesto por escrito para su proyecto
- Pagos fraccionados por hitos, con flexibilidad
De un vistazo
- Standards
- OWASP Top 10, OWASP ASVS, WSTG
- Enfoque
- Control de acceso, lógica, exposición de datos
- Enfoque
- Normalmente caja gris con cuentas de prueba
- Resultado
- Informe, correcciones y nueva prueba
Definition
Qué es las pruebas de penetración de aplicaciones web?
La prueba de penetración de aplicaciones web es una evaluación de seguridad manual de un sitio web o aplicación web que intenta eludir sus controles, alcanzar datos que no debería exponer y hacer un mal uso de sus funciones, con el fin de encontrar y corregir puntos débiles explotables.
La mayoría de los problemas graves de las aplicaciones web no son exóticos. Un usuario que puede ver la factura de otro cliente cambiando un número en la barra de direcciones. Una acción de administrador que comprueba el menú pero no la petición que hay detrás. Un restablecimiento de contraseña que puede reutilizarse. Todo esto parece normal en la superficie; simplemente la aplicación confía en lo que no debe. Encontrarlos requiere un tester que entienda cómo debe funcionar la aplicación y que compruebe deliberadamente si las reglas se aplican en el servidor, y no solo se ocultan en la interfaz.
¿Para quién es?
Productos SaaS
Varios clientes comparten un mismo sistema, por lo que la separación entre cuentas debe ser hermética.
Tiendas online y sistemas de reservas
El proceso de pago, los descuentos, las existencias y los pagos son objetivos habituales de abuso.
Portales con datos personales
Los portales de clientes, pacientes o socios deben mostrar a cada persona solo su propia información.
Equipos antes de un lanzamiento importante
Una prueba antes del lanzamiento es el momento más barato para encontrar problemas estructurales.
Qué está incluido y qué se queda usted
Qué incluye
- Mapeo de páginas, funciones y roles de usuario
- Pruebas de autenticación y de restablecimiento de contraseña
- Gestión de sesiones y revisión de tokens
- Pruebas de control de acceso entre usuarios y roles
- Pruebas de tratamiento de entradas e inyección
- Comprobaciones del tratamiento de salidas y del lado del cliente
- Revisión de la subida y descarga de archivos
- Pruebas de lógica de negocio y abuso de flujos de trabajo
- Revisión de la exposición de datos sensibles
- Revisión de cabeceras de seguridad, cookies y TLS
- Revisión de scripts de terceros y dependencias
- Informe con evidencias, correcciones y una nueva prueba
Lo que recibe
Se entrega al final. Suyo para siempre.
- Informe de pruebas de la aplicación web
- Hallazgos asignados a las categorías de OWASP
- Descripción clara de cada problema confirmado
- Plan de corrección priorizado
- Informe de la nueva prueba
Qué comprobamos siempre en una aplicación web
- ¿Puede un usuario leer o modificar los datos de otro?
- ¿Puede un usuario normal acceder directamente a funciones de administrador?
- ¿Se pueden eludir o reutilizar los inicios de sesión?
- ¿Caducan correctamente los restablecimientos de contraseña y las invitaciones?
- ¿Se trata alguna vez la entrada del usuario como código o consultas?
- ¿Pueden los archivos subidos causar daño en el servidor o a otros usuarios?
- ¿Se pueden manipular precios, cantidades o pasos del flujo de trabajo?
- ¿Contienen las respuestas datos que la página nunca muestra?
Por qué los problemas de control de acceso son el hallazgo más común
El control de acceso roto ocupa el primer puesto del OWASP Top 10 por una razón. Los frameworks gestionan automáticamente muchas tareas de seguridad, pero no pueden saber qué registros pertenecen a qué cliente ni qué botones puede pulsar un responsable. Esas reglas viven en su código, escritas función por función, y basta con que falte una comprobación.
Lo probamos de forma sistemática: repetimos las peticiones importantes como otros usuarios y otros roles, con los identificadores cambiados, para ver si el servidor aplica la regla o si solo la interfaz oculta la opción. Es un trabajo meticuloso y repetitivo, y de él salen muchos de los hallazgos graves de las aplicaciones modernas.
Áreas del OWASP Top 10 que cubrimos
| Área | Ejemplo de lo que comprobamos |
|---|---|
| Control de acceso roto | Ver o editar registros de otros usuarios |
| Fallos criptográficos | Datos sensibles enviados o almacenados sin la protección adecuada |
| Injection | Consultas o comandos construidos a partir de la entrada del usuario |
| Diseño inseguro | Flujos de trabajo que pueden abusarse por diseño |
| Configuración de seguridad incorrecta | Páginas de depuración, ajustes por defecto, errores demasiado detallados |
| Componentes vulnerables | Bibliotecas desactualizadas con puntos débiles conocidos |
| Fallos de autenticación | Gestión débil de inicios de sesión, sesiones o restablecimientos |
| Integridad del software y de los datos | Actualizaciones inseguras o código de terceros no fiable |
| Registro y supervisión | Ataques que pasarían desapercibidos |
| Server-side request forgery (SSRF) | El servidor accede a direcciones que controla un atacante |
Probar las partes de una aplicación que los escáneres pasan por alto
Los escáneres automáticos son buenos detectando entradas reflejadas y patrones conocidos, pero no entienden para qué sirve su aplicación. No pueden saber que un código de descuento solo debería aplicarse una vez, que una factura en borrador no debería poder pagarse o que un agente de soporte debería ver los tickets pero no modificar la facturación. Esas reglas son específicas de su negocio, e infringirlas es exactamente como se produce el abuso real.
Dedicamos la mayor parte de una prueba de aplicación web a este lado humano: leer cómo debe funcionar cada función y comprobar después si el servidor lo aplica realmente cuando llega una petición desordenada, con un valor cambiado o desde la cuenta equivocada. Es más lento que un análisis y mucho más útil, porque llega a los problemas que cuestan dinero y confianza y no a los que una herramienta habría señalado de todos modos.
Cómo funcionan las pruebas de penetración de aplicaciones web, paso a paso
Cada paso tiene un resultado claro que puede revisar. Los plazos se acuerdan en su presupuesto.
- 1
Alcance
Aplicación, entornos, roles y cuentas de prueba acordados por escrito.
- 2
Mapa
Cada página, petición y rol catalogados antes de empezar las pruebas.
- 3
Probar
Pruebas manuales en las áreas de OWASP y en su lógica de negocio.
- 4
Verificar
Cada hallazgo confirmado con cuidado, con evidencias seguras del impacto.
- 5
Informe
Hallazgos, niveles de riesgo y correcciones que sus desarrolladores pueden seguir.
- 6
Repetición de pruebas
Correcciones verificadas e informe actualizado.
Herramientas y qué determina su presupuesto
El precio depende de su proyecto y se acuerda en su presupuesto. Esto es lo que lo hace variar.
| Factor | Por qué importa |
|---|---|
| Tamaño de la aplicación | Más páginas, formularios y endpoints implican más que mapear y probar. |
| Roles e inquilinos | Cada rol y cada límite entre clientes multiplica las pruebas de control de acceso. |
| Workflows | Los pagos, las aprobaciones y los procesos de varios pasos requieren pruebas de lógica cuidadosas. |
| Entorno | Una copia estable del entorno de pruebas agiliza las pruebas; una producción frágil exige más cuidado. |
| Acceso al código fuente | Una revisión de caja blanca junto con las pruebas aporta profundidad y esfuerzo adicional. |
| Área | Tools |
|---|---|
| Proxy de pruebas | Burp Suite, OWASP ZAP, herramientas de desarrollo del navegador |
| Discovery | herramientas de descubrimiento de contenido, herramientas de subdominios |
| Support | Postman, scripts a medida |
| Orientación | OWASP WSTG, OWASP ASVS, OWASP Top 10, CVSS |
Errores habituales que evitar
Lo que vemos fallar con más frecuencia y cómo lo evita un buen proyecto.
Ocultar botones en lugar de comprobar permisos
Si el servidor no verifica cada petición, cualquiera que encuentre la dirección puede usar la función.
Confiar en los valores del navegador
Los precios, los ID de usuario y los roles enviados por el navegador pueden cambiarse; debe decidirlos el servidor.
Mensajes de error demasiado detallados
Las trazas de pila y los errores de base de datos entregan a los atacantes un mapa de su sistema.
Probar con una sola cuenta
Sin cuentas de varios usuarios y roles, los problemas de control de acceso quedan ocultos.
Preguntas frecuentes
¿Necesitan nuestro código fuente?
No, la mayoría de las pruebas de aplicaciones web son de caja gris con cuentas de prueba. El acceso al código fuente nos permite ir más a fondo y es útil para aplicaciones críticas.
¿Pueden probar una aplicación de una sola página creada con React o Vue?
Sí. La interfaz se ejecuta en el navegador, así que nos centramos en las API que hay detrás, donde deben tomarse las decisiones de seguridad reales.
¿Prueban en producción o en el entorno de pruebas?
En cualquiera. El entorno de pruebas es más seguro cuando replica fielmente la producción. Si probamos en producción, acordamos ventanas horarias y evitamos acciones que puedan afectar a clientes reales.
¿Crearán pedidos o correos reales?
Solo cuando se acuerde. Usamos cuentas de prueba y modos de pago de prueba, y limpiamos los datos de prueba que creamos.
¿Cómo valoran el riesgo?
Cada hallazgo recibe una valoración basada en la facilidad con que podría explotarse y en lo que podría ganar un atacante, usando CVSS cuando procede junto con el impacto en el negocio explicado en lenguaje claro.
¿Es suficiente cubrir el OWASP Top 10?
Es una base sólida. También probamos la lógica de negocio específica de su empresa, que ninguna lista genérica cubre por completo.
¿Pueden volver a probar después de que corrijamos las cosas?
Sí, se incluye una nueva prueba de los hallazgos y el informe se actualiza con los resultados.
¿Pueden también corregir los problemas?
Sí. Como equipo de desarrollo podemos implementar las correcciones o revisar las de su equipo antes de la nueva prueba.
Servicios relacionados
Pruebas de penetración
Pruebas de seguridad autorizadas y acotadas, con un informe de correcciones.
Pruebas de seguridad de API
Pruebas REST y GraphQL frente al OWASP API Top 10.
Revisión de código seguro
Revise su código en busca de fallos de seguridad antes del lanzamiento.
Evaluación de vulnerabilidades
Identifique, priorice y planifique las correcciones de debilidades conocidas.
Aplicaciones web y SaaS
Portales, paneles y productos por suscripción.
Seguridad web
Refuerzo de la seguridad, limpieza de malware y revisiones de seguridad.
Pruebas de penetración de aplicaciones web por sector
Descubra qué expone realmente su aplicación web.
Cuéntenos qué necesita. Recibirá una valoración honesta, un plan claro y un presupuesto por escrito. La primera consulta es siempre gratuita.
- Qué ocurre después
- 1Usted nos cuenta qué necesita
- 2Nos proponemos responder en 24 horas con preguntas
- 3Recibe un presupuesto por escrito para su proyecto