1. Logiciel IBM Décembre 2009
Rational
La voie vers une application sécurisée
Une liste de contrôle pour l’analyse de la sécurité du code source
2. 2 La voie vers une application sécurisée
Sommaire Il est reconnu qu’en détectant et en
2 I. Introduction corrigeant les vulnérabilités tôt sur
2 II. Les problèmes de coûts poussent les entreprises le cycle de développement des logiciels,
vers le développement sécurisé les organisations peuvent réduire
3 III. La voie vers des pratiques de développement de considérablement leurs risques et
code sécurisé
leurs coûts.
4 III. Les étapes vers le code sécurisé
Même si ces deux approches ont des effets positifs, les
11 IV. Application de la liste de contrôle pour l’analyse de
la sécurité du code source entreprises peuvent utiliser des outils d’analyse automatique
des vulnérabilités pour une approche plus systématique,
13 V. Annexe : Liste de contrôle pour l’analyse de la automatisée et efficace au développement de code. Ces
sécurité du code source outils d’analyse automatique des vulnérabilités améliorent
considérablement la vitesse et la précision du processus
I. Introduction d’analyse de code et peuvent être intégrés sans problème au
L’épidémie continue d’avertissements des brèches en matière cycle de développement. En effet, les meilleurs outils peuvent
de protection des données due aux lois actuelles sur la identifier les vulnérabilités à la ligne de code (LOC) près et
divulgation illégale des données souligne malheureusement fournissent des informations détaillées sur le type de faille
l’insécurité de nombreuses applications. Comment les rencontré, le risque qu’elle présente et la méthode à suivre
organisations peuvent-elles s’assurer que leurs applications pour la corriger.
sont sécurisées, éviter les retombées en termes de coûts et de
mauvaise publicité et empêcher de voir leur cours baisser en II. Les problèmes de coûts poussent les
bourse à cause de nombreux correctifs de sécurité ? Comment entreprises vers le développement de
faire pour ne pas avoir à expliquer aux consommateurs et aux code sécurisé
autorités réglementaires que du code défectueux à permis à La nécessité de créer du code sécurisé n’a jamais été aussi
des pirates de voler les informations sensibles, et peut-être les grande, compte tenu de l’apparition rapide des nouvelles
informations réglementées ? technologies, y compris les services Web et les Rich Internet
Applications, et de la nécessité de garantir l’intégrité des
La voie vers la création d’une application sécurisée commence applications existantes, héritées et en cours de développement
par un test rigoureux du code source pour détecter toutes les dans un monde axé sur les réseaux. Les entreprises continuent
vulnérabilités. Il faut également s’assurer que l’utilisation de à intégrer leurs systèmes chez leurs partenaires commerciaux
l’application ne compromet ou ne permet à personne de pour accélérer le partage des informations. Dans ces
compromettre la confidentialité et l’intégrité des données. conditions, les entreprises doivent s’assurer que leur code
est sécurisé pour protéger la confidentialité des données,
Cependant, pour les entreprises qui utilisent en interne des promouvoir la fidélité des clients, protéger les informations
applications construites sur-mesure, externalisées ou en open sensibles et maintenir l’intégrité opérationnelle.
source, vérifier que l’ensemble du code actuel et hérité est
sécurisé ne sera pas chose facile. La détection et l’éradication Un défaut sur un logiciel peut entraîner une divulgation des
des vulnérabilités en matière de sécurité ont toujours été des données. Une des pires divulgations de données survenues
tâches extrêmement difficiles. De nombreuses organisations dans le domaine de l’éducation est l’attaque portée en 2006 à
optaient pour une analyse de code manuelle, un processus la base de données de UCLA (University of California, Los
coûteux et mobilisant beaucoup de main-d’œuvre, ainsi que Angeles), qui contenait les informations personnelles de
pour l’ethical hacking, qui examine un sous-ensemble des
vulnérabilités potentielles d’une application.
4. 4 La voie vers une application sécurisée
B. La voie vers un développement sécurisé : comment III. Les étapes vers le code sécurisé :
rechercher les vulnérabilités
ce qu’il faut examiner
Le processus destiné à détecter les erreurs ne consiste pas
La technique la plus efficiente et efficace pour créer du code
seulement à définir le besoin de sécurité au cours du processus
source sécurisé est d’évaluer les applications existantes ainsi
de développement, mais aussi à examiner tous les endroits du
que le code en cours de développement à l’aide de cinq
code où des défauts de conception existent ou peuvent exister.
catégories de vulnérabilités de code :
Ces emplacements sont généralement beaucoup plus étendus
que les développeurs, même les meilleurs, ne le pensent.
1. Fonctions liées à la sécurité
Effectuer une analyse poussée du code source peut entraîner
2. Erreurs d’encodage et de validation des entrées/sorties
les testeurs dans des endroits inattendus.
3. Traitement des erreurs et journalisation des vulnérabilités
4. Composants non sécurisés
S’assurer que le code existant et le nouveau code sont
5. Erreurs de codage.
développés de manière sécurisée implique des processus et des
procédures de recherche des vulnérabilités ainsi que des outils
Suivre les problèmes de sécurité par le biais du code source
pour aider cette recherche. Quels sont les outils les plus
d’une application réduit considérablement la vulnérabilité de
efficaces pour développer des logiciels sécurisés ?
l’application et des données critiques qu’elle traite et protège.
L’analyse de code manuelle et l’ethical hacking sont des
Voici de plus amples informations sur chaque catégorie
approches couramment utilisées. Même si ces deux approches
d’erreurs :
sont utiles, aucune n’est suffisante pour traiter l’étendue des
erreurs de conception existantes et potentielles et donc pour 1. Fonctions liées à la sécurité
s’assurer que le code est sécurisé. L’analyse de code manuelle, Les applications sont la somme de nombreuses fonctions
par exemple, est longue et coûteuse. Repérer les lignes de code discrètes, qui semblent souvent inoffensives. Pourtant, une
qui contiennent des défauts ou qui peuvent donner lieu à des combinaison imprudente de ces fonctions, ou un manque de
erreurs opérationnelles est extrêmement difficile. L’ethical documentation concernant l’implémentation de ces fonctions,
hacking ne peut identifier qu’un petit sous-ensemble des peut facilement créer un risque de sécurité et entraîner des
erreurs qu’une application peut contenir. Même si cette divulgations de données personnelles, confidentielles, ou de
approche est utile pour mettre ces erreurs en évidence, elle l’intégrité du système.
n’offre qu’une vision incomplète de la sécurité globale de
l’application. Ce risque est accentué par l’utilisation répandue de langages
de programmation de haut niveau et de modules préconçus et
Compte tenu de l’étendue des erreurs de conception existantes de bibliothèques précompilées en particulier. Avec ces outils,
ou potentielles, selon les experts, les entreprises doivent les développeurs peuvent rapidement déployer des applications
utiliser des outils de détection des vulnérabilités de logiciel complètes ayant accès à de nombreux services et sources de
automatisés pour repérer tous les défauts potentiels. Ils données. Ces outils aident également à éviter de nombreux
s’accordent sur le fait que l’approche la plus efficace pour problèmes de sécurité, par exemple en retirant la gestion de la
les entreprises qui développent leurs propres logiciels est mémoire et les questions de contrôle des ressources aux
d’intégrer des analyseurs de vulnérabilité du code source dans développeurs qui utilisent des interfaces de haut niveau.
les processus de développement, d’intégration et de test des
applications. Seuls des outils de test de vulnérabilité du code Ces outils n’exigent pas une compréhension plus détaillée de
source de pointe et les pratiques de cycle de développement l’utilisation des services et des données de manière sécurisée,
de logiciel associées peuvent garantir efficacement que le code ni des conflits éventuels d’une telle utilisation avec les
est sécurisé. processus métier existants ou la sécurité des infrastructures
d’une entreprise. En conséquence, l’implémentation non
sécurisée de ces bibliothèques ou modules est en fait la cause
5. Logiciel IBM 5
de la majorité des problèmes de sécurité concernant les
applications actuelles. En outre, ces types d’erreurs de Un chiffrement inexistant
conception de sécurité sont souvent plus dangereux que les
Lors de l’évaluation de la sécurité du code, faites
types précédents de problèmes de codage, car les applications
particulièrement attention à la présence et à
d’aujourd’hui s’interfacent à la fois avec le back office des
l’implémentation d’un chiffrement correct. Détectez tout
entreprises et avec Internet, créant ainsi un conduit potentiel code manquant. Le non chiffrement des informations
pour la perte de données sensibles. sensibles a entraîné de nombreuses brèches de données.
Prenons par exemple l’incident qui a eu lieu aux Etats
Une identification complète de l’état de la sécurité d’une Unis, au Department of Veterans Affairs (le ministère
application doit comprendre une analyse des défauts de américain des anciens combattants) signalé en mai 2006.
conception critiques suivants : Une des applications du ministère a stockée les numéros
de sécurité sociale et les adresses personnelles de tous
a. Cryptographie faible ou non conforme les anciens combattants retraités L’ordinateur portable
Un des composants fondamentaux de la sécurité d’une d’un employé qui contenait ces informations a été volé,
mettant ainsi en danger les données de 38,6 millions
application est le chiffrement des données. Les données
d’anciens combattants.
personnelles ou sensibles sont embrouillées à des fins de
L’analyse du code peut aider à retrouver toutes les
protection. Si les pirates parviennent à casser les algorithmes informations sensibles stockées de manière non
de chiffrement, ils peuvent voler des données sensibles. sécurisée. La question que l’on peut se poser est
L’utilisation de générateurs de chiffres aléatoires faibles et pourquoi ces données étaient disponibles sur un
d’algorithmes cryptographiques non conformes est deux ordinateur portable ? Pourquoi ne pas passer des appels
vulnérabilités de chiffrement répandues qui permettent aux sécurisés à une base de données centralisée, protégée
pirates de voler des données sensibles. par des contrôles d’accès et un système de surveillance
rigoureux ? La réponse probable est qu’il était plus simple
Pour que le chiffrement soit efficace, le caractère aléatoire de de créer une application sur ordinateur portable stockant
la cryptographie sous-jacente doit être suffisamment fort pour les informations dans un format non sécurisé.
empêcher les pirates de deviner ou de reproduire facilement
les clés utilisées pour autoriser le partage des données. Les
chiffres aléatoires faibles ne sont pas assez aléatoires. Lorsque
b. Communications réseau non sécurisées
les chiffres moins aléatoires ainsi obtenus sont utilisés pour
Utiliser des méthodes légales pour envoyer ou recevoir des
former des clés, cet algorithme de chiffrement expose les
données sans documenter ni protéger ces processus peut
données chiffrées à la prédiction de nombres séquentiels et à
exposer des données critiques lors du transit, permettant
la mystification de session. Les développeurs doivent éviter les
ainsi aux pirates de les intercepter et de les lire facilement.
générateurs de chiffres aléatoires faibles.
Les développeurs doivent employer des protocoles de
communication réseau sécurisés, comme Secure Sockets Layer
Attention aux algorithmes cryptographiques non conformes.
(SSL), autant que possible et documenter soigneusement ces
Les algorithmes cryptographiques embrouillent les données et
processus.
seule une poignée d’algorithmes réellement sécurisés existe.
Ces derniers ont été évalués de manière approfondie par des
c. Vulnérabilités liées à la configuration de l’application
experts en cryptographie. Même pour ces experts, produire un
Les développeurs doivent s’assurer que les fichiers de
algorithme vraiment sécurisé et acceptable est extrêmement
configuration ou les options qui commandent leurs
difficile. D’où l’utilisation continue de triple DES, Blowfish et
applications sont également sécurisés. Autrement, un pirate
autres algorithmes usés. Il arrive même qu’on parvient
risque d’accéder à ces fichiers ou options non protégés, de les
ultérieurement à casser ces algorithmes. Quoi qu’il en soit,
manipuler et d’ajuster les propriétés ou les contrôles d’accès
suivez les recommandations des experts. D’autres algorithmes
du logiciel pour accéder à des données sensibles.
sont ou peuvent être suffisamment résistants pour empêcher
un pirate de décrypter des données chiffrées.
8. 8 La voie vers une application sécurisée
3.Traitement des erreurs et journalisation des révèlent aux utilisateurs de l’application. Évitez les applications
vulnérabilités qui s’intègrent à un serveur Web en affichant les erreurs sur le
Votre application présente-t-elle une défaillance progressive ? serveur. Un pirate extérieur peut se servir des informations
La gestion et la journalisation des erreurs sont des tâches ainsi divulguées pour accéder aux systèmes.
particulièrement difficiles pour les développeurs : qui peut
prévoir toutes les défaillances potentielles d’une application et b. Journalisation non sécurisée ou inadaptée
leurs répercussions ? Les fichiers journaux sont essentiels pour surveiller le
comportement d’une application, mais ils constituent
Le traçage de la gestion et de la journalisation des également de précieuses ressources pour les pirates. Ne rendez
erreurs d’une application est cependant capital. En effet, pas les fichiers journaux accessibles. Envisagez la journalisation
aujourd’hui, de nombreuses attaques réussissent en du comportement de l’application pour les applications qui
injectant des données erronées dans une application et en traitent des données sensibles, afin de vous assurer que les
profitant du comportement incorrect qu’elles provoquent pirates ne puissent pas couvrir leurs traces.
dans l’application.
4. Composants non sécurisés
Lorsque vous notez une application en fonction de sa gestion Du code vulnérable peut se retrouver dans une application,
des erreurs, évaluez d’abord ces deux aspects : par un acte malicieux, par inadvertance ou à cause de
mauvaises pratiques d’écriture de code. Par exemple, un
a. Traitement des erreurs non sécurisée pirate peut insérer du code malicieux dans une application
Une mauvaise gestion des erreurs peut fournir aux pirates pour contourner les mesures de sécurité existantes.
des informations cruciales pour lancer leurs attaques. Par Malheureusement, le code malicieux est souvent d’aspect
exemple, de mauvaises habitudes de gestion des erreurs identique au code non malicieux. Ces deux types de code
peuvent fournir des informations utiles concernant la manière peuvent permettre d’accéder à des réseaux et à des données et
dont une application traite les entrées, surtout si la gestion ils fonctionnent tous les deux généralement comme les autres
des erreurs consiste en une écriture personnalisée en fonction parties d’une application.
d’erreurs et d’éléments de données aux détails spécifiques.
Les développeurs doivent limiter la quantité de détails qu’ils Par conséquent, il est extrêmement difficile d’identifier
le code malicieux si l’évaluation des développeurs ne porte
que sur la fonctionnalité. Au lieu de cela, les développeurs
doivent se concentrer sur les emplacements. Commencez par
Web 2.0 : exposer l’insécurité sur le Web
identifier les types de fonctionnalités spécifiques (comme
La nature axée sur le Web du commerce moderne communication réseau, événements programmés et
permet d’accéder via le Web à plus de données que modifications des privilèges) puis mappez chaque type avec le
jamais auparavant. Les technologies comme AJAX
module d’application dans lequel il fonctionne. Recherchez les
permettent aux développeurs de logiciels d’accéder plus
inadéquations, comme une bibliothèque graphique exécutant
facilement aux informations et contribuent à améliorer
des opérations réseau sortantes ou des événements
considérablement l’expérience des utilisateurs finaux.
Mais ces technologies ne font pas grand chose pour programmés figés dans le code dans une application
régler les problèmes de sécurité. Les organisations majoritairement en temps réel. Ces inadéquations sont les
doivent se montrer particulièrement vigilantes quant à leur signes avant-coureurs d’intentions malicieuse.
qualité de code et à leurs vulnérabilités en termes de
sécurité à mesure qu’elles adoptent de nouveaux Aujourd’hui, les pratiques en matière de développement
outils et de nouvelles techniques de développement. d’applications impliquent une multitude de composants.
Une innovation du Web 2.0, par exemple, est le mashup Même si ce nombre élevé de composants aide à créer des
qui combine du contenu provenant d’un serveur hébergé
à des flux publiquement disponibles. Cependant, ces
nouvelles capacités ouvrent de nouvelles possibilités
d’attaque inter-sites. Lorsque les mashups Web 2.0 ne
sont pas réalisés de manière sécurisée, ils ouvrent la voie
à de nouvelles formes de phishing (ou hameçonnage) et
autres attaques.
9. Logiciel IBM 9
applications sécurisées plus rapidement, deux types Pour tout projet de logiciel, assurez-vous que tous les contrats
d’utilisation de composants entraînent d’importants risques stipulent l’utilisation exclusive de méthodes prises en charge.
de vulnérabilité : Pour les applications existent, trouvez les méthodes non prises
en charge, supprimez-les et remplacez-les par des méthodes
a. Méthodes Java Native Interface non sécurisées prises en charge.
Si les développeurs emploient des méthodes Java Native
Interface (JNI) non sécurisées dans leur code, les pirates 5. Erreurs de codage
peuvent accéder facilement aux ressources critiques, comme la Les erreurs de codage, également connues sous le nom
mémoire système ou environnement. d’erreurs d’implémentation, peuvent être causées par une
formation insuffisante des développeurs, par des délais trop
En quoi consistent les méthodes JNI ? Il s’agit de langages de serrés, par un manque de priorités en ce qui concerne les
plus haut niveau qui fournissent des interfaces pour vérifier exigences liées au projet ou par la réutilisation de code de
l’accès aux ressources. Par contraste, la méthode JNI est un qualité inconnue ou médiocre.
moyen plus basique d’accéder à ces ressources, car elle évite ce
type d’interfaces pour obtenir de meilleures performances. Lorsque des erreurs de codage existent dans les applications,
Comme le code est écrit sans contrôles au niveau de elles peuvent provoquer des comportements inattendus,
l’interface, le risque d’erreur de mauvais codage est comme donner le contrôle d’un système ou d’un processus à
extrêmement élevé. De manière générale, évitez d’utiliser des un pirate ou même arrêter une application. En raison des
méthodes JNI, sauf dans certains cas exceptionnels où les risques de sécurité inhérents aux erreurs de codage, ces erreurs
performances sont prioritaires. Localisez et testez toujours de doivent être supprimées du code, qu’il soit en cours de
manière approfondie les méthodes JNI utilisées. En outre, développement ou déjà en production.
vous devez prendre en compte le fait que les bibliothèques JNI
peuvent contenir des erreurs intégrées, en particulier lors Lorsque vous évaluez le code, recherchez ces vulnérabilités
d’une programmation en C ou C++, qui sont plus vulnérables liées au codage :
aux problèmes de dépassement de la mémoire tampon et de
concurrence critique. a. Vulnérabilités liées au dépassement de la mémoire
tampon
b. Méthodes non prises en charge Un dépassement de la mémoire tampon se produit lorsque la
Les développeurs prennent parfois des raccourcis et utilisent quantité de données copiées dans une mémoire tampon est
des méthodes ou des appels non pris en charge au cours du supérieure à la capacité de cette mémoire. Même si l’on
développement des applications. Utiliser des fonctions ou des comprend parfaitement les dépassements de mémoire tampon
routines non documentés peut produire des insécurités depuis plus de 20 ans, ils restent un problème courant et
cachées, qui permettent aux pirates d’attaquer une application. entraînent un risque extrêmement élevé. Les pirates peuvent
profiter de ce type de mauvaise gestion de la mémoire pour
charger et exécuter du code défaillant dans la mémoire de
l’ordinateur, ce qui permet aux pirates de prendre le contrôle
Comportement suspect
de tout le système;
Signes indiquant qu’une application peut contenir du code
malicieux Dans les langages structurés, comme C et C++, il existe
Signe Indique littéralement des centaines d’appels et de combinaisons
d’appels qui peuvent donner lieu à des erreurs d’allocation
Raw socket access Portes dérobées possibles
de mémoire et à une mauvaise compréhension des
Minuterie ou fonction Déclencheur comportements de l’application. Cette complexité crée des
d’obtention de l’heure conditions idéales pour les attaques par dépassement de la
Niveaux d’accès non
Modifications des privilèges autorisés mémoire tampon.
10. 10 La voie vers une application sécurisée
Dans les langages de plus haut niveau, comme Java, JavaServer Une vulnérabilité DoS est due à des erreurs d’implémentation
Pages (JSP), C#, .Net, les vulnérabilités sont beaucoup moins qui provoquent la consommation de ressources rares, limitées
nombreuses, car le langage et l’interprétation du moteur ou non renouvelables ou la destruction ou l’altération des
d’exécution traitent toute la gestion de la mémoire au niveau informations de configuration. Pour éviter ces conditions
inférieur, qui est donc protégée de toute influence par le d’échec, les développeurs doivent concevoir leurs applications
programmeur. Même dans ces langages de plus haut niveau, il pour fonctionner même dans les pires scénarios.
se peut que des appels parfois non documentés créent une
vulnérabilité de dépassement de la mémoire tampon à l’insu d. Vulnérabilités liées à l’augmentation des privilèges
du programmeur. Soyez très vigilant en matière de Dans de nombreux cas, le but ultime d’une attaque est
dépassement de la mémoire tampon pour les langages de l’augmentation des privilèges. Un utilisateur ayant des
plus haut niveau. informations d’authentification insuffisantes obtient un accès
privilégié, ce qui permet au pirate d’accéder à ces données et
b. Vulnérabilités liées à la chaîne de format des ressources confidentielles, et même de prendre le contrôle
Les vulnérabilités liées à la chaîne de format illustrent la de tout le système ou de le détruire, tout en restant classé
relation entre les erreurs d’implémentation et la qualité comme utilisateur de confiance.
globale d’une base de code. Les vulnérabilités liées à la chaîne
de format sont souvent considérées comme un type de Un pirate élève généralement ses privilèges en exploitant les
dépassement de la mémoire tampon, mais cette comparaison sections des programmes dans lesquelles une application
n’est pas entièrement correcte. Même si une vulnérabilité de délivre ou reçoit des privilèges de niveau supérieur. Parfois, les
chaîne de format peut produire un dépassement de la mémoire applications doivent créer des processus sous des utilisateurs
tampon, elle peut aussi entraîner l’exposition d’informations, différents ou avec des niveaux d’accès différents. La charge de
sans dépassement. la preuve incombe aux développeurs afin de s’assurer que le
processus d’augmentation des privilèges ne peut pas être
Lors du développement de code, une utilisation incomplète de exploité par des programmes malicieux. De même, le
certains appels peut entraîner des vulnérabilités de la chaîne processus de désaugmentation doit aussi être testé en
de format. Les bonnes pratiques en matière de codage profondeur.
impliquent l’utilisation cohérente de certains arguments,
comme les spécificateurs de champs. Si au lieu de cela, les Par exemple, lorsqu’un processus de priorité inférieure
développeurs élaborent du code à l’aide d’appels incomplets, redonne le contrôle à un autre programme doté de privilèges
ces appels ne sont pas suffisamment liés, ce qui permet aux plus élevés, l’application doit toujours vérifier la validité des
pirates d’insérer des données, des arguments ou des requêtes codes de retour, les conditions d’erreur et les opérations de
d’informations supplémentaires dans ces appels. Analysez tout diminution des privilèges déclenchées par les erreurs. Si une
le code à la recherche d’appels incomplets et corrigez ces de ces opérations échoue, les programmes peuvent continuer à
appels. fonctionner à des niveaux ou des privilèges différents de ceux
qui sont requis.
c. Erreurs DoS
Toute application qui donne accès à des données ou des
services critiques ne peut remplir que cette fonction lorsqu’elle
est exécutée. Les attaques DoS compromettent les applications
et affectent la livraison de données ou de services critiques.
11. Logiciel IBM 11
e. Concurrence critique IV. Application de la liste de contrôle pour
Deux processus peuvent partager le contrôle ou les l’analyse du code source
données. La concurrence critique désigne la compromission A. Des applications coupables jusqu’à ce qu’elles soient
de ce partage, qui découle généralement d’erreurs de prouvées innocentes
synchronisation, lorsqu’il existe un risque de conflits entre les Les cinq grands types de vulnérabilités de code décrits
processus et donc une vulnérabilité. Une faille classique précédemment représentent tous les risques les plus
interrompt une paire d’appels séquentiels qui doivent être probables et les plus dangereux contenus dans le code
exécutés automatiquement sans interruption par un autre fil existant et hérité. Les clients professionnels, les chefs de
ou processus sur la machine avec un troisième processus. projet de développement de logiciels et les développeurs
doivent s’assurer que tout le code est analysé afin d’identifier
Un exemple est la vérification combinée des droits d’accès à ces cinq catégories de vulnérabilités.
un fichier, suivie par un appel ultérieur visant à écrire ou à lire
ce fichier. En interrompant le processus entre les deux appels, Compte tenu de la multitude de risques posée par ces
un pirate peut réécrire ou modifier le fichier car ce vulnérabilités et par leur présence probable dans de
comportement est prévisible. Le pirate peut placer des nombreuses applications, les équipes de projet doivent traiter
informations inappropriées dans un fichier ou accéder à un toutes les applications qu’elles mettent en service, qu’elles
fichier inapproprié. créent ou qu’elles réévaluent avec beaucoup de scepticisme en
matière de sécurité. Cette attitude marque un changement
important par rapport à l’approche de développement
traditionnelle, qui consiste à analyser une application en se
Erreurs courantes liées au déni de service (DoS)
basant sur sa vitesse, ses fonctionnalités et sa convivialité.
DoS d’arrêt de l’application : Comment l’application
s’arrête-t-elle ? Certains auteurs d’applications, lorsqu’ils Aujourd’hui, les équipes de développement traitent chaque
implémentent la fonctionnalité de fermeture pour une application existante ou en cours de développement comme un
application le font de manière trop générale. Par exemple,
risque de sécurité avant que son innocuité puisse être prouvée.
si une application se ferme automatiquement en raison
Les équipes doivent réagir de la sorte à cause des risques que
d’erreurs d’entrée au moyen d’une fonction système de
représentent ces vulnérabilités pour l’entreprise. En effet,
sortie, un pirate peut provoquer une suite d’événements
similaire qui entraîne l’arrêt artificiel et intempestif de comme indiqué par un groupe de travail de l’Institute of
l’application. Electrical and Electronics Engineers (IEEE) étudiant le
DoS des connexions à la base de données non fermées : nouveau rôle de la sécurité dans le cycle de développement des
L’application se connecte-t-elle sans problème aux bases logiciels, les applications ont aujourd’hui un effet beaucoup
de données ? Pour autoriser l’accès d’un processus aux plus important sur l’approbation des clients, sur la stabilité et
données, l’application et la source de données doivent sur la rentabilité des entreprises à long terme.2
d’abord établir une connexion. Si ce processus est codé
incorrectement, la queue des requêtes de récupération Par conséquent, le groupe de l’IEEE recommande aux
peut devenir embouteillée et surchargée en raison des équipes de projet traditionnellement concentrées uniquement
tentatives de connexion échouées aux bases de données.
sur la satisfaction des demandes des clients d’apprendre à
communiquer le risque de sécurité aux sponsors en amont,
afin de justifier les exigences appropriées en matière de
budget et de projet. Même si ces changements sont peu
populaires, aujourd’hui, les menaces de sécurité et l’obligation
de protéger les informations sensibles et personnelles exigent
une concentration dédiée à la sécurité de la part de tous les
membres des équipes de projet.
12. 12 La voie vers une application sécurisée
B. Tests de vulnérabilité du code source risques de violations de données coûteuses, la réduction
Les outils de test de vulnérabilité du code source à eux des coûts liés au cycle de développement des logiciels, la
seuls ne suffisent pas à sécuriser un logiciel. Ces outils conformité à des normes plus strictes et l’obtention d’un
aident les développeurs et les analyseurs de code à évaluer avantage concurrentiel. Les entreprises doivent choisir l’outil
les applications, même celles qui contiennent des millions qui fonctionne le mieux avec leurs ressources de code
de lignes de code, pour identifier les vulnérabilités potentielles existantes et qui aide l’organisation à atteindre ses objectifs en
les plus dangereuses. Avec ces outils de test, les équipes de termes de cycle de développement de logiciels. Elles doivent
développement et de résolution peuvent classer leurs efforts également s’assurer que l’outil choisi couvre toutes les erreurs
par ordre de priorité et adopter une approche axée sur les de codage et tous les défauts de conception qui doivent être
risques pour améliorer la base de code, en commençant par les identifiés et éliminés pour créer une application sécurisée.
problèmes les plus critiques.
Les nombreuses violations de données exposées par les
La création d’applications sécurisées nécessite que les média à ce jour, qui sont souvent dues à des défauts de
organisations développent du code sécurisé et prévoient des code, soulignent la nécessité d’éradiquer les vulnérabilités
tests de vulnérabilité en continu. Pour toute application, la pour empêcher la divulgation d’informations sensibles ou
sécurité du code doit être une condition requise préalable à la réglementées par négligence ou par malveillance. Même pour
publication du code. L’explosion du nombre de menaces les organisations qui ne sont pas encore soumises à ces
ciblées doit faire des tests de vulnérabilité de la sécurité des réglementations, la croissance rapide en matière d’outils,
applications un passage obligé dans toutes les entreprises. de technologies et de langages de programmation plus
connectés, y compris les applications Web 2.0, rend toutes
Ce travail est pénible et compliqué car les applications les organisations qui utilisent ces technologies vulnérables.
complexes peuvent contenir des erreurs de codage et des Compte tenu des coûts considérables aussi bien financiers
vulnérabilités extrêmement complexes et difficiles à identifier. qu’en termes de réputation résultant des violations de
Les équipes d’analyse du code ont besoin d’outils d’analyse de données, les entreprises cherchent de plus en plus à trouver le
code sophistiqués. En effet, la nature technique et les causes moyen le plus efficient et efficace pour garantir la sécurité de
reconnues des erreurs d’implémentation et de codage poussent leur code source, pour développer des applications sécurisées
de nombreuses entreprises à faire de l’analyse du code le point et pour éliminer les bogues le plus tôt possible dans le
de départ logique de l’amélioration de la sécurité globale de processus de développement, bien avant la livraison du code.
l’application.
Les entreprises qui parviennent à intégrer efficacement
C. Choisir le bon outil les tests de vulnérabilité du code source à leurs pratiques
Lorsqu’il s’agit de choisir un outil automatisé de test de de cycle de développement de logiciels peuvent éviter les
vulnérabilité du code source à utiliser tout au long du cycle impacts négatifs des défauts de sécurité. Ces pratiques
de développement d’un logiciel, les organisations doivent améliorées débouchent sur des économies considérables pour
d’abord évaluer leurs ressources de développement de code les entreprises et pour les clients, les partenaires et les autres
existantes. Ces ressources comprennent l’expertise en sécurité acteurs qui utilisent leurs logiciels. Ces économies sont la
interne, les technologies et les partenaires de service ainsi que preuve de l’efficacité d’un programme de sécurité de code
leurs objectifs d’amélioration du cycle de développement de source.
logiciels. Ces objectifs peuvent impliquer la diminution du
nombre de correctifs de sécurité publiés, la réduction des
13. Logiciel IBM 13
V. ANNEXE : Liste de contrôle pour l’analyse de la sécurité du code source
Vérifier que les applications sont sécurisées commence par la recherche des vulnérabilités afin d’atténuer les risques qu’elles
posent pour l’application et l’intégrité des données :
Catégorie Vulnérabilité Risque
Fonctions liées à la sécurité Cryptographie faible ou non conforme Les pirates peuvent casser les algorithmes pour voler
des données sensibles
Communications réseau non sécurisées Les méthodes légitimes utilisées pour envoyer les
informations ne sont pas documentées ni protégées,
ce qui expose des données critiques
Vulnérabilités liées à la configuration de l’application L’accès aux fichiers ou options de configuration non
protégés permet de manipuler les propriétés ou les
données du logiciel
Vulnérabilités de contrôle d’accès Accès non autorisé aux données et aux ressources
confidentielles
Utilisation non protégée de la base de données et du Le piratage et la manipulation des appels aux bases
système de fichiers de données et aux systèmes de fichiers exposent les
données
Vulnérabilités de code dynamique Insertion réussie de commandes malicieuse dans les
applications qui chargent du code dynamique sans
validation appropriée
Chargement de code local La manipulation de ces appels au niveau du système
permet la manipulation, l’exposition et la destruction
des données
Vulnérabilité liée au stockage des données Les données stockées de manière non sécurisée
peuvent être volées facilement
Erreurs d’authentification Les pirates utilisent les informations d’authentification
d’utilisateurs légitimes pour voler ou pour manipuler
des données
Erreurs de validation des E/S Vulnérabilités liées à l’injection de langage SQL Envoi de commandes SQL directement aux bases de
et les erreurs d’encodage données pour voler ou manipuler des données
Vulnérabilités liées aux attaques XSS Les utilisateurs se font pirater leurs sessions à leur
insu, téléchargent des chevaux de Troie à leur insu ou
sont victimes d’arnaques par hameçonnage
Vulnérabilités liées à une injection dans le système Les pirates modifient ou abusent des commandes du
d’exploitation (OS) système d’exploitation pour contrôler les données et
les ressources
Manipulation des cookies personnalisés ou des Crée un niveau de confiance dont les pirates se
champs masqués servent pour lancer des attaques, comme une injection
de SQL ou une attaque XSS
14. 14 La voie vers une application sécurisée
Catégorie Vulnérabilité Risque
Traitement des erreurs et Traitement des erreurs non sécurisée Fournit aux pirates des informations utiles pour leurs
journalisation des vulnérabilités attaques
Journalisation non sécurisée ou inadaptée Les fichiers journaux accessibles divulguent des
informations utiles pour les attaques, tandis qu’une
journalisation inappropriée permet aux pirates d’effacer
leurs traces
Composants non sécurisés Code malicieux Du code d’apparence légitime inséré dans le logiciel
peut permettre aux pirates de contourner les mesures
de sécurité
Méthodes locales non sécurisées L’utilisation non contrôlée de méthodes locales permet
aux pirates d’accéder à des ressources critiques
comme la mémoire système ou environnement
Méthodes non prises en charge Les fonctions ou routines non documentées sont une
source d’insécurité cachée qui peut être exploitée
Erreurs de codage Vulnérabilités liées au dépassement de la mémoire Les pirates peuvent prendre en otage les ressources
tampon du système
Vulnérabilités liées à la chaîne de format Entraîne des dépassements de la mémoire tampon ou
l’exposition des données
Erreurs DoS Empêche le logiciel de fonctionner
Vulnérabilités liées à l’augmentation des privilèges Les pirates peuvent accéder aux données et aux
ressources confidentielles
Concurrence critique Contourner un processus d’application pour manipuler
des opérations
Utilisation de méthodes locales non sécurisées Peut sacrifier la sécurité au profit des performances,
donnant ainsi un accès non sécurisé à la mémoire
système ou environnement
Méthode non prise en charge Des opérations légitimes peuvent lancer des appels à
du code vulnérable à l’insu de l’utilisateur
