Aller au contenu principal

6. Security Considerations (Considérations de sécurité)

Problèmes de limite de taille​

La plupart des types définis par les champs structurés n'ont pas de limite de taille ; par conséquent, des champs extrêmement grands peuvent constituer un vecteur d'attaque (par exemple, pour les attaques de consommation de ressources).

Atténuation​

La plupart des implémentations HTTP limitent la taille pour atténuer ces attaques :

  • Taille d'un champ individuel
  • Taille de la section d'en-tête entière
  • Taille de la section de pied de page entière

Pratiques recommandées​

Les implémentations devraient (SHOULD) :

  • Définir des limites de taille de champ raisonnables
  • Surveiller la taille totale des en-têtes
  • Enregistrer des alertes pour les valeurs de champ anormalement grandes
  • Envisager de rejeter les requêtes/réponses trop volumineuses

Attaques par injection de champ​

Une partie capable d'injecter de nouveaux champs HTTP peut modifier la signification d'un champ structuré.

Risque​

Dans certains cas, cela entraînera un échec d'analyse, mais ne peut pas échouer de manière fiable dans tous les cas.

Stratégies de défense​

  1. Contrôle d'accès strict : Limiter qui peut définir les champs HTTP
  2. Validation de l'intégrité des champs : Utiliser des signatures ou HMAC
  3. Principe du moindre privilège : Limiter la portée sémantique des champs

Signification de sécurité de la rigueur d'analyse​

Pourquoi l'analyse stricte est une fonctionnalité de sécurité​

Scénario : Valeur de champ construite de manière malveillante

Analyseur tolérant :
Input: key="value\x00hidden"
Peut analyser : key="value"  (ignore le contenu après l'octet nul)
→ Données cachées peuvent contourner les vérifications de sécurité

Analyseur strict :
Input: key="value\x00hidden"
Résultat : Échec d'analyse, ignore le champ entier
→ Pas d'ambiguïté, limites de sécurité claires

Avantages de sécurité​

  1. Prévention de l'injection : La validation stricte empêche les attaques par injection
  2. Élimination de l'ambiguïté : Toutes les implémentations se comportent de manière cohérente
  3. Échec précoce : Découvre les problèmes aux points de contrôle des limites
  4. Prévisibilité : Les attaquants ne peuvent pas exploiter les différences d'analyse

Attaques par confusion de type​

Les implémentations doivent (MUST) effectuer une vérification de type stricte et ne pas tenter de convertir automatiquement les types.

// Vérification de type stricte correcte
const field = parseItem(fieldValue);
if (field.type !== 'integer') {
  return null;  // Ignorer le champ entier
}

Exemples d'attaques par consommation de ressources​

Attaque 1 : Liste extrêmement longue​

Example-List: 1, 2, 3, ..., 100000  # 100,000 membres

Défense :

const MAX_LIST_SIZE = 1024;  // Exigence minimale RFC
if (list.length > MAX_LIST_SIZE) {
  throw new Error('List too large');
}

Attaque 2 : Chaînes extrêmement longues​

Example-String: "AAAA...AAAA"  (100MB)

Défense : Limiter la longueur des chaînes à une valeur raisonnable (par exemple, 8192 caractères).

Pollution des paramètres​

Les clés de paramètres doivent (MUST) être uniques dans leur portée. Les clés en double provoquent un échec d'analyse.

const params = new Map();
for (const [key, value] of parsedParams) {
  if (params.has(key)) {
    throw new Error('Duplicate parameter key');
  }
  params.set(key, value);
}

Liste de contrôle de sécurité​

Lors de l'implémentation de champs structurés, assurez-vous de :

  • Limiter la taille des champs
  • Limiter le nombre de membres List/Dictionary
  • Limiter la longueur des String/Token
  • Limiter la taille des Byte Sequence
  • Valider strictement tous les types
  • Rejeter les clés en double
  • Enregistrer les entrées anormales
  • Tester les cas limites
  • Ne pas essayer de "réparer" les entrées erronées
  • Ignorer le champ entier en cas d'échec

Points clés​

  1. Limites de taille : Les implémentations doivent (MUST) limiter la taille des champs
  2. Risque d'injection : L'injection de champ peut modifier la sémantique
  3. Analyse stricte : La rigueur est une fonctionnalité de sécurité
  4. Sécurité des types : La vérification de type stricte empêche les attaques par confusion
  5. Responsabilité de l'implémentation : Ajouter des limites de sécurité raisonnables
  6. Défense en profondeur : Combiner plusieurs mécanismes de sécurité