← Todas las guías
WebMetodología defensivaIntermedio28 min

Web hacking: cómo razonar sobre las clases de fallo

Una lectura práctica del OWASP Top 10: seguir una petición, localizar límites de confianza, documentar evidencia reproducible y comprobar la corrección.

1 · Sigue la petición completa

Dibuja el recorrido: navegador, CDN o proxy, framework, autenticación, autorización, lógica de negocio, base de datos y respuesta. En cada salto pregunta qué dato entra, quién lo controla, qué transformación ocurre y qué decisión de confianza se toma. La vulnerabilidad suele aparecer en la frontera entre dos supuestos.

Ficha de una prueba
Precondición | Rol | Petición | Decisión esperada | Resultado | EvidenciaCuenta A | alumno | GET /api/reports/42 | solo propietario | 403 | captura + request-id

2 · Aprende clases de fallo, no una lista de payloads

Control de acceso

El servidor permite leer o cambiar algo que el rol actual no posee. Prueba objetos propios y dos cuentas de laboratorio.

Configuración

Valores por defecto, interfaces de administración, errores verbosos, cabeceras o permisos de nube amplían la superficie.

Cadena de suministro

Dependencias, proceso de build, artefactos y actualizaciones no verificadas introducen confianza externa.

Criptografía e identidad

Datos sin protección adecuada, recuperación débil, sesiones largas o controles MFA incompletos.

Inyección

Una entrada se interpreta como instrucciones porque falta parametrización, validación por contexto o separación de datos.

Diseño y errores

El flujo permite abuso aunque el código «funcione», o un estado excepcional salta controles y deja datos incoherentes.

3 · Diseña pruebas pequeñas y comparables

Cambia una sola variable cada vez. Compara invitado, usuario A, usuario B y administrador de laboratorio. Registra petición y respuesta completas, pero elimina tokens y datos personales del informe. Detente cuando la hipótesis queda demostrada; no conviertas una prueba en recolección.

4 · Informa para que otra persona pueda corregir

  1. Condición: rol, cuenta y estado inicial.
  2. Pasos mínimos: una secuencia reproducible sin secretos.
  3. Resultado e impacto: qué límite se rompe y a quién afecta.
  4. Evidencia: request-id, captura recortada y respuesta saneada.
  5. Corrección: control server-side y prueba automatizada que previene regresión.

5 · El retest verifica la causa, no solo el síntoma

Repite el caso original, variantes del mismo límite y una operación legítima para evitar falsos arreglos y regresiones. Un mensaje 403 no basta si los datos ya se enviaron. Cierra cuando el control vive en el punto correcto y la prueba queda incorporada al ciclo de entrega.

Glosario

OWASP Top 10

Documento de concienciación que agrupa riesgos críticos habituales en aplicaciones web.

Inyección

Fallo en el que datos no confiables alteran la sintaxis o intención de un intérprete.

Control de acceso

Reglas que determinan qué identidad puede realizar una acción sobre un recurso.

Prueba de concepto

Demostración mínima y reproducible que confirma un fallo sin ampliar innecesariamente el impacto.

Retest

Comprobación posterior destinada a verificar que la corrección elimina la causa y no solo el síntoma.

Ver más guías
Web hacking: cómo razonar sobre las clases de fallo | Cubix Academia