Télécharger le Numéro « Spécial 2013 »




Recherche :

Les 25 erreurs de programmation les plus dangereuses

Le rapport 2009 CWE/SANS des 25 erreurs de programmation les plus dangereuses est une liste des erreurs de programmation les plus importantes pouvant fragiliser la sécurité des logiciels, On les trouve fréquemment, et elles sont aisées à trouver et aisées à exploiter. Elles sont dangereuses car elles permettent souvent aux attaquants de prendre le contrôle total du logiciel, voler des données, ou empêchent le logiciel de fonctionner,

 

Ce rapport que vous pouvez consulter dans son intégralité sur notre site est issu de la collaboration entre les instituts SANS, MITRE et un grand nombre d'experts en matière de sécurité logiciel aux USA et en Europe. Elle s'appuie sur le développement des 20 vecteurs d'attaque SANS (http://www.sans.org/top20) et sur la liste des faiblesses les plus communes (CWE) développée par MITRE (http://cwe.mitre.org), MITRE assure la maintenance du site web CWE, avec l'aide de la division sur la sécurité informatique du département US de la Sécurité Intérieure, Cette liste présente des descriptions détaillées des 25 erreurs de programmation avec les solutions pour les éviter ou en diminuer les conséquences. Le site CWE contient également des informations sur plus de 700 erreurs de programmation additionnelles et les erreurs d'architecture qui peuvent permettre d'en exploiter les vulnérabilités.

 

Le but principal de la liste des 25 est d'éduquer les programmeurs afin d'éviter  les erreurs à la source, et d'éliminer les problèmes les plus fréquents avant même la distribution du logiciel. Cette liste sera un outil qui permettra aux programmeurs d'éviter les erreurs majeures qui sont la plaie de cette industrie. Les utilisateurs de logiciel .pourraient utiliser la liste afin d'exiger  des logiciels plus surs. Finalement les responsables des développements et CIO peuvent utiliser la liste afin de contrôler l'évolution de la sécurité des logiciels.

 

La liste des 25 est organisée en 3 catégories. Voici un extrait de la catégorie 'Interaction non sécurisée entre composants':

 

CWE-20: Mauvaise validation des entrées

 

Résumé

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



Présentation

C'est le tueur numéro un des logiciels sains. Vous vous attirez des ennuis si vous ne vérifiez pas que les entrées sont conformes aux spécifications. Par exemple une entrée numérique ne doit pas pouvoir contenir de lettres. Ou le prix d'une voiture neuve ne saurait être un Euro, même dans l'économie d'aujourd'hui. Les applications ont souvent des contraintes beaucoup plus complexes que ce simple exemple. Une mauvaise validation des entrées entrainera des vulnérabilités quand les attaquants modifieront les valeurs de manière imprévue. La plupart des vulnérabilités actuelles pourrait être éliminées ou au moins réduite rien qu'en validant correctement les entrées.


Prévention et atténuation des conséquences

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.

 

CWE liées

CWE-184: liste noire incomplète

CWE-74: Injection

CWE-79: Script multi-sites (XSS)

CWE-89: Injection SQL

CWE-95: Injection Eval

 

Type d'attaques

CAPEC-ID:

 

Pour consulter le rapport dans son intégralité

Dans Programmez!
Créer des applications hybrides avec PhoneGap
Aujourd’hui, les développeurs cherchent à réduire le temps de déploiement de leurs applications mobiles et ainsi à prendre un avantage sur leurs concurrents. L’objectif de cet article est de vous faire découvrir une approche alternative pour booster...
Logiciels embarqués : créer des produits techniques innovants
La majorité des produits manufacturés embarquent des logiciels. Découvrez les défis liés au passage du matériel au logiciel et l’approche à adopter afin d’accélérer l’innovation.
Lire le livre blanc PTC
Hack in Paris
L’événement dédié aux professionnels de la sécurité informatique. Formations et conférences : tests d'intrusion, recherche de vulnérabilité, guerre de l'information, etc . Du 17 au 21 juin 2013, Centre de conférences de Disneyland Paris.
Info et inscription
Près de 4000 offres d'emploi
+ les annonces Premium de programmez.com
Consulter l’espace emploi
Les tutoriels
Les offres d'emploi
Ched de projet MOA MOE décisionnel
CDI | LCD CONSULTANTS | Paris XV-75015 |
Ingénieur d'étude expérimenté Java/J2EE H/F
CDI | Experis IT | Nantes |
Superviseur Systèmes & Réseau H/F
CDI | C2S | Boulogne-Billancourt-92100 |
Consultant Microsoft BI
CDI | GROUPE ON-X | Paris |
Consultant (e) C# / ASP .Net / Finance (Taux)
CDI | GROUPE ON-X | Paris |
Responsable d'Agence / Ingénieur d'Affaires (H/F)
CDI | Adelius | Paris |
Technicien Helpdesk (H/F)
CDI | OSIATIS | Vélizy-Villacoublay-78140 |
Consultant JAVA
CDI | GROUPE ON-X | Paris |
Ingénieur JAVA EE GWT (H/F)
CDI | SFEIR | Neuilly-sur-Seine-92200 |
Ingénieur d'études et développements Delphi H/F
CDI | SULLY GROUP | Paris XI |

Les forums
Les livres
Programmez.com - 2013 - Tous droits réservés
Développement - WEB - ASP - PHP - C++ - Delphi - Java - Magazines - Ressources - Forum - Télécharger - Video - Emploi - Campus - .Net - Tutoriels

Le présent site Web est édité par Go 02, Sarl inscrite au RCS de Paris sous le N° 411321366 et dont le siège social est au 21 rue de Fécamp 75012 Paris.
Adresse de courrier électronique :diff@programmez.com

Le directeur de la publication du site www.programmez.com est Jean-Claude Vaudecrane en qualité de gérant de la sarl GO 02

Le portail du décideur informatique en entreprise : Solutions & Logiciels