1.3.1 [Reto] – curl como herramienta de auditoría

Tu equipo ha sido contratado para auditar el control de acceso de una aplicación web interna.
La aplicación funciona correctamente “a simple vista”, pero la empresa sospecha que usuarios autenticados podrían acceder a recursos que no les pertenecen.

Tu misión no es romper nada, sino demostrar con evidencias técnicas si los controles de acceso están bien implementados… o no.

---

Objetivos del proyecto

Al finalizar la práctica, el alumno será capaz de:

• Comprender OWASP Top 10 – A01: Broken Access Control
• Usar curl como herramienta de auditoría (no como navegador)
• Simular usuarios, sesiones y roles
• Detectar fallos de:
  • IDOR
  • Falta de autorización
  • Bypass por método HTTP
  • Acceso a rutas protegidas
• Generar evidencias reproducibles para un informe técnico

---

Escenario

Infraestructura

• Servidor: Apache + PHP (o similar)
• Base de datos: MySQL / MariaDB
• Aplicación web con:
  • Login y sesión
  • CRUD de “Pedidos” o “Reservas”
  • Dos roles:
    • usuario
    • admin

Endpoints de ejemplo

(ajústalos a tu app con otros nombres)

Función	Endpoint
Login	/login.php
Perfil usuario	/api/profile.php
Listar pedidos	/api/orders.php
Ver pedido	/api/order.php?id=ID
Modificar pedido	/api/order.php?id=ID (PUT)
Borrar pedido	/api/order.php?id=ID (DELETE)
Panel admin	/admin/dashboard.php

---

Preparación del entorno

Comprobar curl

curl --version

Crear carpeta de trabajo

mkdir auditoria_a01
cd auditoria_a01

---

Reconocimiento pasivo (sin login)

Acceso a recursos protegidos sin autenticar

curl -i http://servidor/api/orders.php

Anota:

• Código HTTP
• ¿Redirige a login?
• ¿Devuelve datos?

📌 Si devuelve datos → indicio crítico de A01.

---

Intento directo a panel admin

curl -i http://servidor/admin/dashboard.php

Resultado esperado:

• 401 o redirección a login
  Resultado peligroso:
• 200 OK

---

Autenticación y gestión de sesión

Login como usuario normal

curl -c cookies_user.txt \
     -d "username=usuario1&password=1234" \
     http://servidor/login.php

Comprueba que se crea cookies_user.txt.

---

Acceso autenticado

curl -b cookies_user.txt -i http://servidor/api/profile.php

---

OWASP A01 en acción (Broken Access Control)

---

IDOR – Acceso a pedidos de otros usuarios

Pedido propio

curl -b cookies_user.txt -i \
"http://servidor/api/order.php?id=1"

Pedido ajeno

curl -b cookies_user.txt -i \
"http://servidor/api/order.php?id=2"

Vulnerabilidad A01 si:

• Ambos devuelven 200 OK
• Se muestran datos de otro usuario

---

Enumeración automática de IDs

for i in 1 2 3 4 5; do
  curl -s -o /dev/null \
  -w "ID=$i STATUS=%{http_code} SIZE=%{size_download}\n" \
  -b cookies_user.txt \
  "http://servidor/api/order.php?id=$i"
done

Patrón típico A01:

• Todos los IDs responden con 200
• Tamaños distintos → datos distintos

---

Bypass por método HTTP (PUT / DELETE)

Intento de modificación

curl -X PUT \
  -H "Content-Type: application/json" \
  -d '{"status":"CANCELLED"}' \
  -b cookies_user.txt \
  -i \
  "http://servidor/api/order.php?id=2"

Intento de borrado

curl -X DELETE \
  -b cookies_user.txt \
  -i \
  "http://servidor/api/order.php?id=2"

📌 A01 crítico si:

• Usuario normal puede modificar/borrar pedidos ajenos

---

Acceso a funciones admin con usuario normal

curl -b cookies_user.txt -i \
http://servidor/admin/dashboard.php

Resultado correcto:

• 403 Forbidden
  Resultado vulnerable:
• 200 OK

---

Headers manipulables (prueba de confianza indebida)

curl -b cookies_user.txt \
  -H "X-Role: admin" \
  -i \
  http://servidor/api/profile.php

📌 Si el rol cambia → fallo grave de diseño.

---

Evidencias para informe

Guardar headers y cuerpo

curl -b cookies_user.txt \
  -D evidencia_headers.txt \
  -o evidencia_body.txt \
  -w "STATUS=%{http_code}\nTIME=%{time_total}\n" \
  "http://servidor/api/order.php?id=2"

---

Evidencia mínima reproducible

curl -s -o /dev/null \
  -w "STATUS=%{http_code}\n" \
  -b cookies_user.txt \
  "http://servidor/api/order.php?id=2"

Esto es oro puro para un informe técnico.