Prévalence de la vulnérabilité

Élevée

Conséquences

Exécution de Code

Suppression de service

Perte de données

Coût de réparation

Faible

Facilité de détection

Facile à difficile

Fréquence des attaques

Souvent

Sensibilisation attaquant

Elevée

Conception et Architecture

Utilisez un cadre de validation des entrées tel Struts ou l'API de validation OWASP ESAPI. Si vous utilisez Struts, soyez conscient des faiblesses décrites dans la catégorie CWE-101

Comprendre toutes les possibilités de corruption de vos données d'entrée: paramètres, arguments, cookie et tout ce qui est lu en provenance du réseau, variable d'environnement, en-tête de requête et contenu, composants d'URL, courrier électronique, fichiers, bases de données, et tout système externe transférant des données à l'application. Validez les entrées dans des interfaces bien validées;

Assumez que toute entrées est malicieuse. Utilisez les mécanismes standards de validation des entrées pour vérifier les longueurs, types, syntaxe et règles de gestion avant d'accepter ou stocker les données. Un exemple de règle de gestion: « bateau » peut être correct car ne contenant que des lettres, mais non valide si vous attendiez une couleur ! Utilisez une stratégie d'acceptation des valeurs connues, rejetez toute valeur ne correspondant pas à vos critère ou transformez là en quelque chose qui convienne.

Dupliquez toutes les vérifications coté Client sur le Serveur pour éviter CWE-602. Ces vérifications non seulement diminuent le temps passé par le serveur pour les utilisateurs normaux qui ne connaissent pas le format de saisie. Les attaquants peuvent éviter ces mécanismes très simplement en interceptant les paramètres après la vérification coté Client, et les modifiant avant transmission au serveur. Ce devrait être simple à implémenter, et devrait éviter la probabilité d'utilisation de paramètres non sécurisés dans l'application. On ne doit pas ignorer les vérifications coté Client. Tout d'abord ils peuvent être utiles à la détection d'intrusion. Si le serveur reçoit des données qui auraient du être rejetées par le client, cela peut être un signe d'attaque. De plus les modèles AJAX nécessitent des validations d'entrées pour prévenir les problèmes DOM ou XSS.

Ne pas se baser uniquement sur des listes noires pour détecter les entrées malicieuses ou pour encoder les sorties (CWE-184). Il existe trop de méthodes différentes pour encoder un caractère donné, et vous pourriez oublier une variante.

Implémentation

Quand votre application combine des données venant de sources multiples, validez-les après leur intégration.  Les données individuelles peuvent être correctes, mais pas leur combinaison.

Soyez spécialement prudent pour la validation des données quand vous appelez du code qui dépasse les limites de langage, comme celle entre un code interprété et Un code natif. Cela pourrait provoquer une interaction imprévue entre les limites des langages. Vérifiez que vous ne violez aucune des attentes du langage avec lequel vous vous interfacez. Par exemple, alors que Java n'est pas sensible au dépassement de tampon, fournir un argument trop grand lors d'un appel à du code natif peut provoquer un dépassement de tampon.

Convertissez directement une entrée dans le type demandé par l'application, en utilisant par exemple une fonction de conversion de caractère en nombre. Après la conversion, vérifiez que le résultat est bien dans les bornes de validité et que l'intégrité multi-champs est bien maintenue.

Les entrées doivent être décodées dans le format de représentation interne de l'application avant d'être validées (CWE-180 et CWE-181). Vérifiez bien que votre application de décode pas la même entrée deux fois (CWE-174). Une telle erreur pourrait court-circuiter un schéma de liste de validation, en introduisant des valeurs dangereuses après la validation. Utilisez des bibliothèques telles OWASP ESAPI.

En échangeant des données entre les composants, vérifiez que les composants utilisent le même type de codage des caractères. Indiquer explicitement le codage à utiliser chaque fois que le protocole le permet.