> For the complete documentation index, see [llms.txt](https://chubu.gitbook.io/chubu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://chubu.gitbook.io/chubu/vulnerabilidades-en-web-apps/business-logic-flaws.md).

# Business Logic Flaws

Fallos de la lógica de negocio

Las **vulnerabilidades de lógica de negocio** no son bugs técnicos clásicos (como XSS o SQLi), sino errores en **cómo la aplicación debería comportarse**.

&#x20;Surgen cuando:

* Los devs hacen **suposiciones incorrectas** sobre el usuario.
* Se confía demasiado en **validaciones del lado cliente**.
* No se consideran **flujos alternativos o abusivos**.

{% hint style="info" %}
El atacante no rompe el sistema… lo usa “correctamente” pero de forma inesperada.
{% endhint %}

## Metodología básica

#### 1. Mapear la app (recon lógico)

* Navegar toda la app (“spidering”)
* Identificar flujos completos:
  * Registro → Login → Compra → Reembolso

Herramientas útiles:

* Burp Suite (Spider / Proxy)

## Puntos críticos a auditar

* Formularios
* APIs / Web Services
* Recuperación de contraseña
* Registro de usuario
* Tokens / hashes / datos compartidos

## Técnicas de detección

### 1. Validación débil de inputs

* Salirse de rangos:
  * ratings: `-1`, `0`, `6`
* Saltar validaciones client-side (proxy)
* Subir archivos con extensiones inesperadas

### Manipulación de funcionalidades

#### Reviews / ratings

* Postear sin comprar (bypass “verified”)
* Múltiples reviews → race condition
* Suplantar otros usuarios
* Falta de CSRF

***

#### Cupones

* Reutilización de cupones
* Race condition con cupones “single-use”
* HTTP Parameter Pollution / Mass Assignment
* Aplicar cupones a productos no válidos

***

#### Carrito

* Cantidades negativas
* Cantidades > stock
* Manipular wishlist ↔ carrito entre usuarios

***

#### Envío

* Costos negativos
* Forzar envío gratis

***

#### Moneda (arbitraje)

* Comprar en USD → reembolsar en EUR
* Ganancia por conversión

***

#### Features premium

* Acceso directo a endpoints premium
* Flags booleanos (`isPremium=true`)
* Manipulación con Match & Replace
* Revisar:
  * Cookies
  * LocalStorage

***

#### Reembolsos

* Refund pero mantener acceso
* Race condition → múltiples refunds
* Repetir cancelaciones

***

#### Comentarios / threads

* Spam ilimitado
* Bypass límite (race condition)
* Suplantación de identidad

### Manipulación de parámetros

* Modificar:
  * precios
  * roles
  * estados (`isAdmin`, `isPremium`)
* Agregar parámetros ocultos:
  * Mass Assignment
* Alterar respuestas:
  * Bypass 2FA

## Patrones típicos de vulnerabilidad

* Confianza en el cliente
* Falta de validación server-side
* Estados inconsistentes (race conditions)
* Lógica mal definida en:
  * pagos
  * permisos
  * flujos de negocio

## Vectores principales de explotación

***

### &#x20;A. Race Conditions&#x20;

**Patrón:**

```
check → use
```

**Ataque:**

* Mandar requests paralelas antes de que cambie el estado

**Targets típicos:**

* Cupones
* Reembolsos
* Registro
* Likes / votos
* Stock

**Herramientas:**

* Burp Suite (Intruder / Turbo Intruder)

**Ejemplo:**

```
POST /apply-couponcoupon=DISCOUNT50
```

→ Enviar 20 requests simultáneos

### B. Violación de flujo (workflow bypass)

Saltar pasos obligatorios:

Ejemplo:

```
/cart → /checkout → /payment → /confirm
```

&#x20;Probar:

* Ir directo a `/confirm`
* Reutilizar requests viejas
* Cambiar estados manualmente

***

### &#x20;C. Manipulación de valores críticos

Campos típicos:

```
{  "price": 100,  "discount": 0,  "shipping": 10,  "total": 110} Ataques:
```

* `price=1`
* `shipping=-10`
* `total=0`

&#x20;Si el backend no recalcula → vuln crítica

***

### D. Mass Assignment / Overposting

Enviar más campos de los esperados:

```
{  "username": "user",  "role": "admin",  "isPremium": true}
```

&#x20;Buscar:

* Campos ocultos
* IDs internos
* Flags booleanos

***

### &#x20;E. HTTP Parameter Pollution (HPP)

```
coupon=AAA&coupon=BBB
```

&#x20;Posibles efectos:

* Bypass validaciones
* Aplicar múltiples valores

***

### &#x20;F. Currency / Price Logic

* Cambiar moneda en medio del flujo
* Reembolso en otra currency
* Desincronización frontend/backend

***

### &#x20;G. Control de acceso lógico (no técnico)

NO es un IDOR clásico.

&#x20;Ejemplo:

* Usuario básico accede feature premium porque:
  * flag manipulable
  * estado mal validado

***

### &#x20;H. Estado inconsistente

Ejemplo:

* Cancelás suscripción
* Recibís refund
* Seguís teniendo acceso

&#x20;Bug = falta de sincronización de estado

## Superficies críticas (donde mirar SIEMPRE)

***

### &#x20;Pagos

* Total manipulable
* Repetición de transacción
* Reembolso múltiple

***

### &#x20;Cupones

* Reuso
* Race condition
* Aplicación indebida

***

### &#x20;Carrito

* Cantidades negativas
* Overflow de stock
* Precios congelados

***

### &#x20;Auth / registro

* Multi cuentas
* Email no verificado
* Bypass de pasos

***

### &#x20;Contenido generado

* Suplantación
* Límites bypass
* Spam via race

***

### &#x20;Uploads

* Validación solo client-side
* Extensiones raras
* Mixed content

## Técnicas concretas (playbook)

***

### &#x20;Manipulación sistemática

Interceptar con:

* Burp Suite

Luego:

#### 1. Eliminar campos

```
{}
```

#### 2. Duplicar campos

```
price=100&price=1
```

#### 3. Cambiar tipos

```
"price": "0""price": null
```

#### 4. Valores extremos

* `-1`
* `999999999`
* `0`

***

### &#x20;Race condition básica

* Enviar requests en paralelo
* Usar:
  * Turbo Intruder
  * Repeater en múltiples tabs

***

### &#x20;Replays

* Repetir requests sensibles:
  * `/refund`
  * `/apply-coupon`
  * `/checkout`

***

### &#x20;Lógica inversa

Pensar:

* ¿Qué NO debería ser posible?
* ¿Qué pasa si:
  * repito?
  * cambio orden?
  * omito pasos?

***

## &#x20;6. Indicadores de vulnerabilidad

* Validación solo en frontend
* Flags booleanos (`true/false`)
* IDs predecibles
* Falta de revalidación server-side
* Respuestas inconsistentes

***

## &#x20;7. Casos reales simplificados

***

#### &#x20;Coupon reuse

* Backend valida solo una vez
* Race condition → múltiples usos

***

#### &#x20;Negative shipping

```
"shipping": -50
```

→ total negativo

***

#### &#x20;Premium bypass

```
"isPremium": true
```

→ acceso sin pagar

***

#### &#x20;Refund abuse

* Refund aprobado
* Endpoint no invalida acceso

***

## &#x20;8. Workflow práctico.

1. Mapear app (proxy + spider)
2. Identificar flujos críticos
3. Interceptar requests clave
4. Manipular:
   * valores
   * parámetros
5. Probar:
   * race conditions
   * replays
6. Validar impacto:
   * económico
   * acceso
   * integrida
