Les 25 erreurs de programmation les plus dangereuses
Comme chaque année, le CWE vient de publier la liste des 25 erreurs de programmation les plus dangereuses pour l’intégrité de vos systèmes ou de vos applications. Si toutes ces vulnérabilités ne s’appliquent pas forcément au développement web, elles sont tout de même intéressantes à étudier, ne serait-ce que pour se former aux bonnes pratiques de développement.
Mauvaises interactions entre les composants
Ces vulnérabilités concernent les manières dont les données sont envoyées et reçues par des composants, modules, programmes, processus, threads ou systèmes.
- Mauvais filtrage des données envoyées par les utilisateurs.
- Mauvais encodage ou échappement des données en sortie.
- Injections SQL.
- Cross Site Scripting (ou XSS).
- Injection de commandes directement exécutables par le système d’exploitation (system() ou exec()).
- CSRF (prononcez sea surf pour avoir l’air cool).
- Race conditions.
- Divulgation d’informations dans les messages d’erreur (comme le PATH dans lequel est installée votre application web).
Mauvaise gestion des ressources
Ces vulnérabilités concernent la manière dont les applications ne gèrent pas correctement la création, l’utilisation, le transfert et la destruction des ressources systèmes.
- Buffer overflow.
- Modifications externes de données d’état.
- Modification externe des chemins d’accès ou des fichiers en lecture / écriture.
- PATH non limité.
- Injections de code (eval()).
- Téléchargement et exécution de code sans réel contrôle d’intégrité.
- Mauvaise libération de ressources (double free()…).
- Mauvaise initialisation.
- Erreurs de calcul (off by one, division par zéro).
Protections foireuses
Il s’agit de modes de protection souvent mal utilisés, contournés, ou purement ignorés par les développeurs.
- Absence d’ACL.
- Utilisation d’un algorithme de chiffrement cassé.
- Mots de passes codés en dur dans les applications(!).
- Mauvaises permissions sur les ressources les plus critiques.
- Exécution de programmes avec des permissions trop élevées (le bonheur des CGI en root).
- Prise des mesures de sécurité côté client.
Voilà, c’est tout, avec, peut-être, à l’avenir, des articles distincts sur chacune de ces vulnérabilités, si vous êtes suffisamment nombreux à être intéressés.
