> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qaos.machdel.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Injection
> XSS, injection SQL/NoSQL et vulnérabilités d'extraction de paramètres ORM causées par des entrées utilisateur non assainies atteignant les magasins de données ou la sortie rendue.
Les vulnérabilités d'injection se produisent lorsque les entrées utilisateur non fiables sont interprétées comme du code ou de la logique de requête plutôt que comme des données. Elles vont du cross-site scripting (XSS) qui exécute du JavaScript dans les navigateurs des victimes à l'injection de base de données qui expose tout votre magasin de données.
***
## user-input-not-filtered
Élevé
**Description**
Les champs de saisie ne nettoient pas ni n'échappent les données fournies par l'utilisateur avant de les rendre sur la page, rendant l'application vulnérable aux attaques de **Cross-Site Scripting (XSS)**.
**Importance**
Le XSS permet aux attaquants d'injecter du JavaScript arbitraire dans les pages de votre application. Cela peut être utilisé pour :
* Voler les cookies de session (même sans contournement HttpOnly via XSS stocké)
* Rediriger les utilisateurs vers des sites de phishing
* Exfiltrer silencieusement des données de formulaire (enregistrement de frappe)
* Défigurer l'application
* Attaquer d'autres utilisateurs qui consultent la page infectée
**Comment QAOS le détecte**
L'agent identifie les champs de saisie qui reflètent le contenu utilisateur (champs de recherche, formulaires de commentaires, champs de profil, paramètres URL rendus sur la page) et soumet des charges utiles de test XSS. Il observe si la charge utile est exécutée, rendue sans échappement ou stockée et affichée à d'autres visiteurs.
Charges utiles de test utilisées :
```javascript theme={null}
">
javascript:alert(1)
```
**Comment corriger**
**Ne faites jamais confiance aux entrées utilisateur.** Appliquez l'encodage de sortie approprié au contexte :
```javascript theme={null}
// Encoder les entités HTML (prévenir l'injection HTML)
const encoded = input
.replace(/&/g, '&')
.replace(//g, '>')
.replace(/"/g, '"')
// Utiliser une bibliothèque comme DOMPurify pour le contenu HTML enrichi
import DOMPurify from 'dompurify'
element.innerHTML = DOMPurify.sanitize(userContent)
```
Utilisez une Content Security Policy (CSP) comme mesure de défense en profondeur :
```http theme={null}
Content-Security-Policy: default-src 'self'; script-src 'self'
```
***
## hostile-data-used-in-query
Élevé
**Description**
Les entrées contrôlées par l'utilisateur sont utilisées directement dans la construction de requêtes sans paramétrage, permettant aux attaquants de modifier la logique de requête et d'extraire des enregistrements non autorisés.
**Importance**
Un seul champ de recherche injectable peut exposer toute votre base de données. Les charges utiles d'injection SQL comme `' OR 1=1 --` contournent les clauses WHERE. Les charges utiles d'injection NoSQL comme `{"$ne": null}` retournent tous les enregistrements. C'est systématiquement la cause n°1 des violations de données à grande échelle.
**Comment QAOS le détecte**
L'agent identifie les champs de recherche, de filtre et de requête, puis soumet des charges utiles d'injection et observe les changements de réponse :
```
Normal : /users?search=alice → retourne 1 utilisateur
Attaque : /users?search=' OR 1=1-- → retourne tous les utilisateurs
```
**Comment corriger**
**Utilisez toujours des requêtes paramétrées.** Ne concaténez jamais les entrées utilisateur dans des chaînes de requête :
```python theme={null}
# INCORRECT — vulnérable à l'injection
query = f"SELECT * FROM users WHERE name = '{user_input}'"
# CORRECT — requête paramétrée
cursor.execute("SELECT * FROM users WHERE name = %s", (user_input,))
```
```javascript theme={null}
// MongoDB — éviter l'injection directe d'opérateurs
const users = await User.find({ name: req.query.name }) // potentiellement dangereux
// Utiliser la validation + liste d'autorisation d'opérateurs
```
***
## untrusted-data-concatenation-dynamic-query
Élevé
**Description**
Des requêtes dynamiques sont construites en concaténant plusieurs valeurs d'entrée non fiables, permettant à des fragments injectés comme `&showAll=true`, `&fields=password` ou `?filter[$gt]=0` de modifier le comportement de la requête et d'exposer des données non autorisées.
**Importance**
Même lorsque les entrées individuelles sont partiellement assainies, combiner plusieurs valeurs contrôlées par l'utilisateur dans une seule expression de requête crée des opportunités d'injection. Les vulnérabilités d'assignation massive dans les ORM entrent dans cette catégorie.
**Comment QAOS le détecte**
L'agent teste les pages basées sur des filtres en injectant des paramètres de requête supplémentaires comme `showAll=true`, `fields=password,ssn,salary` ou `filter[$ne]=null` pour vérifier si l'application les passe aveuglément à la couche de données.
**Comment corriger**
Utilisez une **liste d'autorisation** explicite de paramètres et d'opérateurs acceptés. Ne passez jamais directement des fragments de requête bruts des entrées utilisateur à un ORM ou un constructeur de requête :
```javascript theme={null}
// Définir explicitement les champs de filtre autorisés
const ALLOWED_FILTERS = ['name', 'status', 'createdAt']
const safeFilter = {}
for (const key of ALLOWED_FILTERS) {
if (req.query[key]) safeFilter[key] = req.query[key]
}
const results = await Model.find(safeFilter)
```
***
## orm-parameter-extraction-in-url
Élevé
**Description**
Les paramètres URL sont passés directement à une requête ORM sans validation, permettant l'injection d'opérateurs de style MongoDB (`[$ne]`, `[$gt]`, `[$regex]`), de fragments SQL ou de paramètres d'assignation massive qui exposent des enregistrements supplémentaires ou des champs cachés.
**Importance**
L'injection ORM via les paramètres URL est particulièrement courante dans les applications Node.js utilisant Mongoose ou Sequelize, où `req.query` est passé directement à `Model.find()`. Cela peut contourner tout contrôle d'accès et exposer chaque enregistrement dans la collection.
**Comment QAOS le détecte**
L'agent ajoute des suffixes d'injection aux paramètres URL sur les pages avec des listes de données :
```
/users?id[$ne]=invalid → MongoDB : correspond à tous les utilisateurs où id ≠ "invalid"
/products?name[$regex]=.* → MongoDB : correspond à tous les produits
/orders?showAll=true → contournement par assignation massive
/users?fields=name,email,ssn → injection de champs
```
**Comment corriger**
Assainissez les paramètres de requête avant de les passer à votre ORM. Rejetez toute entrée contenant des opérateurs `$` ou une syntaxe de tableau :
```javascript theme={null}
const mongoSanitize = require('express-mongo-sanitize')
app.use(mongoSanitize()) // supprime $ de toutes les entrées
// Ou valider manuellement
if (typeof req.query.id !== 'string') throw new Error('Paramètre invalide')
```
***
## orm-parameter-extraction-in-form
Élevé
**Description**
La même vulnérabilité d'injection ORM que ci-dessus, mais exploitée via des **soumissions de formulaires** (paramètres du corps POST) plutôt que des chaînes de requête URL.
**Importance**
Les paramètres du corps POST reçoivent souvent moins de scrutin que les paramètres URL, surtout dans les frameworks qui utilisent des parseurs de corps qui convertissent automatiquement la notation de formulaire `name[$ne]=x` en objets imbriqués `{ name: { $ne: 'x' } }`.
**Comment QAOS le détecte**
L'agent soumet des formulaires avec des paramètres de corps modifiés contenant des charges utiles d'injection ORM et observe si la réponse inclut des données auxquelles il ne devrait pas avoir accès.
**Comment corriger**
Appliquez le même assainissement aux paramètres du corps POST qu'aux chaînes de requête. Utilisez `express-mongo-sanitize` ou l'équivalent pour votre framework, et validez toutes les entrées par rapport à des schémas explicites en utilisant des outils comme Zod, Joi ou Pydantic.