L’EXPERTISE TECHNIQUE 10 000 ARTICLES

& SCIENTIFIQUE DE RÉFÉRENCE 1 000 FICHES PRATIQUES

EXTRAIT
ISSU DE L’OFFRE

Sécurité des systèmes d'information

Audits de sécurité et Web - Méthodologies, outils

et retour d'expérience

par Laurent BUTTI

RÉSUMÉ

L'audit est une brique nécessaire de l'implémentation de la roue de Deming, représentative du cycle d'amélioration continue.
Dans un contexte Web, l'audit de sécurité doit vérifier que les phases amont sont bien implémentées en vue d'émettre les
recommandations nécessaires pour corriger des vulnérabilités éventuellement découvertes. Cet article présente les
principales approches et outils utilisés lors des audits de sécurité techniques dans le domaine des applications Web.

ABSTRACT

Auditing is an essential step when implementing Deming wheel. In a Web context, security audits have to check that prior
phases are correctly implemented in order to improve them thanks to appropriate recommendations. This article aims at
presenting main principles and recommended tools for technical security audits related to Web applications.

En savoir plus Techniques de l’Ingénieur

sur nos conditions 33 (0)1 53 35 20 20

d’abonnement ? infos.clients@teching.com

Document téléchargé le : 06/10/2023 | © Techniques de l'Ingénieur | Tous droits réservés

Audits de sécurité et Web
Méthodologies, outils et retour d’expérience

par Laurent BUTTI

Expert sécurité Orange

1. Contexte et évolutions logicielles.................................................... H 5 135 - 2

1.1 Failles applicatives des sites Web ........................................................... — 2
1.2 Évolutions logicielles en cours ................................................................ — 3
2. Risques de sécurité Web ..................................................................... — 4
2.1 À propos .................................................................................................... — 4
2.2 OWASP Top 10 — 4
3. Techniques et outils d’audit .............................................................. — 10
3.1 Recherche de vulnérabilités Web ............................................................ — 10
3.2 Différents objectifs et classes d’outils..................................................... — 10
3.3 Web Scanners ........................................................................................... — 11
3.4 Anayse de code source ............................................................................ — 12
3.5 Proxies intrusifs ........................................................................................ — 13
3.6 Modules navigateurs ................................................................................ — 13
3.7 Détails sur le Web Scanner Open Source w3af — 13
3.8 Détails sur le proxy intrusif Burp Proxy .................................................. — 17
3.9 Détails sur l’extension navigateur XSS-Me — 19
3.10 Détails sur l’outil DOMinatorPro — 19
3.11 Résumé sur les outils ............................................................................... — 21
4. Retour d’expérience ............................................................................. — 21
4.1 Problématiques rencontrées lors des audits .......................................... — 21
4.2 Conclusion................................................................................................. — 21
Pour en savoir plus ......................................................................................... Doc. H 5 135

es applications Web sont intrinsèquement vulnérables aux attaques venant

L de l’extérieur de par leur exposition. Afin de sensibiliser le lecteur à ces
problématiques, sont présentées quelques statistiques. Issues des études de
WhiteHat Security et TrustWave, elles illustrent les principales classes de
vulnérabilités rencontrées dans le domaine de la sécurité Web. Cet article aura
pour tâche d’expliciter la majeure partie de ces vulnérabilités qui seront
décrites dans la section « Risques de sécurité Web ».

Copyright © – Techniques de l’Ingénieur – Tous droits réservés H 5 135 – 1

AUDITS DE SÉCURITÉ ET WEB _________________________________________________________________________________________________________

1. Contexte et évolutions Nota : se reporter au Pour en savoir plus pour disposer d’une liste de sites Web
spécialisés à consulter.

logicielles
La figure 1 décrit l’ensemble des classes de vulnérabilités les
plus courantes des sites Web qui ont été auditées par la société
Whitehat Security. Nous pouvons constater que de nombreuses
failles dépassent un taux de 20 % de présence, ce qui est tout à fait
inquiétant. La figure 2, quant à elle, repose sur les mêmes
principes, mais les données sont issues de la société TrustWave.
Des corrélations entre ces deux études sont observables.
Comme, par exemple, sur la présence forte des failles de type
« Cross-Site Scripting » et « Cross-Site Request Forgery ». La des-
cription complète de chacune de ces failles sera réalisée au § 2.
Par ailleurs, le document détaillé de l’étude de Whitehat
Security souligne que :
– les organisations de taille importante ont le nombre
moyen de vulnérabilités par application le plus élevé (13
contre 11 pour le meilleur) ;
– les organisations de taille importante ont le taux de mise
en place des correctifs le moins élevé (54 % contre 62 % pour
le meilleur).
Ces résultats pourraient s’expliquer par la complexité de
mise en œuvre des préceptes de sécurité dans la chaîne
complète, lorsque l’organisation est de taille importante.
1.1 Failles applicatives des sites Web
Les applications Web sont la cible de nombreuses attaques, avec
des impacts importants sur les sites Web attaqués (perte d’image
de marque, compromission de données métiers ou de données
clients...).
En effet, les failles applicatives sur les services Web sont à la
fois :
– les plus exposées, de par leur accessibilité depuis tout
l’Internet ;
– les moins protégées par l’infrastructure, car seuls les pare-feu
applicatifs sont capables, en partie, de détecter et/ou prévenir
l’exploitation de ces failles de sécurité orientées Web ;
– peuvent héberger des données sensibles, telles que des
données clients, ou représentent un vecteur de business important
comme, par exemple, le commerce électronique.
Les Google Dorks présentés au § 2.2.1, les scans récurrents via
des outils automatisés de recherche de vulnérabilités comme pré-
sentés au § 3.3, les attaques manuelles ciblées, et bien d’autres,
nous permettent de constater que la moindre faille de sécurité
exposée peut être rapidement découverte, puis exploitée. Le
contexte de l’Internet actuel fait que tout site Web est forcément
une cible, que ce soit par des mécanismes automatisés (vous êtes
alors un parmi d’autres) ou de manière plus ciblée (activisme,
intelligence économique...). Il suffit de se rappeler des épisodes

Percentage likelihood that at least one serious* vulnerability will appear in a website

55 %
53 %

33 %
26 % 26 %
23 % 22 %

14 % 13 %
11 % 11 % 9% 8% 7% 4%
Information Cross-Site Content Brute force Cross-site Fingerprinting Insufficient Session URL Insufficient Directory Abuse of Prédictable SQL HTTP
Leakage Scripting Spoofing Request Transport Fixation Redirector Authorization Indexing Fonctionality Resource injection Response
Forgery Layer Abuse Location Splitting
Protection

Figure 1 – Prévalence des classes de vulnérabilités (Crédit Whitehat Security )

Top 10 Application Vulnerabilities

Percentage of Applications
RANK* Finding
Cntaining Vulnerability

1 SQL Injection 15 %
2 Miscellaneous Logic Flaws 14 %
3 Insecure Direct Object Reference 28 %
4 Cross-Site Scripting (XSS) 82 %
5 Faillure to Restrict URL Access 16 %
6 Cross-Site Request Forgery 72 %
7 Other Injection 7%
8 Insecure File Uploads 10 %
9 Insecure Redirects 24 %
10 Various Denial of Service 11 %

Figure 2 – Prévalence des classes de vulnérabilités (Crédit TrustWave )

H 5 135 – 2 Copyright © – Techniques de l’Ingénieur – Tous droits réservés

_________________________________________________________________________________________________________ AUDITS DE SÉCURITÉ ET WEB
ciblant Sony et d’autres, menant alors à des compromissions de
données personnelles. Mais aussi, de consulter la base de réfé-
rence qui recense tout un ensemble d’incidents rendus publics,
pour rapidement prendre conscience des risques inhérents à
l’exposition sur Internet.
Parmi quelques exemples publics récents, nous pouvons citer les
plus notoires :
– LinkedIn s’est fait dérober une partie de la base de mots de
passe composée d’environ 6 millions de ses utilisateurs en juin 2012 ;
– LivingSocial s’est fait dérober les données personnelles de près
de 50 millions de ses utilisateurs en avril 2013 ;
– Twitter.com et New York Times se sont faits compromettre
leur nom de domaine par la « Syrian Electronic Army » en août 2013 ;
– la compromission du compte Facebook de Mark Zuckerberg
(son fondateur) par un individu voulant être récompensé financiè-
rement par la découverte de la faille qui a été finalement exploitée en
août 2013 ;
– Vodafone Germany s’est fait dérober les informations bancaires
d’environ 2 millions de ses clients en septembre 2013.
Nous sommes en permanence inondés de ces avis de sécurité
qui ne représentent, bien entendu, que la partie visible de
l’iceberg. Bon nombre de failles de sécurité sont exploitées
silencieusement, et ce n’est qu’a posteriori qu’elles sont parfois
découvertes...
Vis-à-vis des applications Web, le Verizon Data Breach
Investigation Report de 2012 fait état que :
« Web applications abound in many larger companies, and
remain a popular (54 % of breaches) and successful (39 % of
records) attack vector ».
1.2 Évolutions logicielles en cours
Dans ce contexte hostile, les services Web doivent cependant
évoluer sans cesse (figure 3). Ce qui est nécessaire pour survivre
dans un contexte extrêmement concurrentiel. Ces évolutions logi-
cielles sont forcément sensibles, puisqu’elles peuvent à tout
moment introduire des failles de sécurité. Or, seule l’intégration
des préceptes de sécurité dans un cycle de vie logiciel peut mener
à une réduction des risques liés à des failles fonctionnelles ou à
des failles d’implémentation.
Typical rate of production application code change in the organization's website.
(By Industry)
Banking 14 % 29 %
Financial
27 % 36 %
Services
Healthcare 17 % 17 % 33 %
Insurance 33 %
Retail 20 % 20 % 20 %
Technologie 4 % 28 % 36 %
Figure 3 – Évolutions logicielles par industrie (Crédit WhiteHat Security )
Copyright © – Techniques de l’Ingénieur – Tous droits réservés
Il est donc nécessaire de prendre en compte les aspects sécurité
à toutes les étapes du cycle de vie logiciel (Software Development
Life-Cycle ).
Sur le plan technique et organisationnel, une approche classique
est de réaliser des audits de code source récurrents par des outils
d’analyse de code source statique (« boîte blanche ») durant les
phases de développement et de qualification. Cette approche peut
être avantageusement complétée par des outils en « boîte noire »
qui apportent une autre vision (celle-ci plus proche de la vue de
l’attaquant) de l’architecture auditée (une fois l’application stable
déployée dans un environnement réaliste).
Ce ne sont, bien sûr, qu’une partie de l’implémentation de la
sécurité dans le cycle de vie logiciel. De nombreuses publications
décrivent les principes plus en profondeur, comme le Microsoft
Software Development Life-Cycle, le Building Security In Maturity
Model et le Open Software Assurance Maturity Model (Consulter la
liste de nombreux sites Internet dans le Pour en savoir plus ).
Fluidifier ce cycle de développement logiciel consiste à s’aider
d’outils automatiques afin de dégrossir le travail des auditeurs
sécurité. Ils pourront alors se concentrer sur les parties où les
outils sont reconnus comme étant non efficaces. Les coûts
humains étant souvent bien plus élevés que les coûts d’acquisition
ou de fonctionnement des outils, le but est de couvrir plus
efficacement une plus grande surface d’applications !
Encadré 1 – Découverte des failles de sécurité en amont
Découvrir des failles de sécurité en amont, durant les pha-
ses de développement ou de qualification, et donc les corriger
au plus tôt, est évidemment moins coûteux que de les corriger
en phase de production. En effet, c’est effectivement moins
coûteux de corriger en amont si l’on part du principe que
toute faille de sécurité peut être exploitée (et dans ce cas, ren-
trent en compte les coûts de gestion d’incident, les impacts
juridiques, contractuels et légaux...). De la même manière,
appliquer un correctif en urgence sur des applications en
production induit des coûts importants humains, et des
risques supplémentaires en termes de disponibilité de
l’application. Il ne faut pas se priver de toute possibilité de
découverte de vulnérabilité en amont des développements !
De nombreuses études corroborent cet état de fait, dont celle
du NIST qui estime que les coûts de correctifs, après mise en
production, sont environ six fois plus élevés que si le correctif
avait été mis en œuvre durant la phase de développement.
43 % 14 %
At least daily
18 % 9% 9% Weekly
33 % Monthly
67 % Quarterly
10 % 30 % Annually or less
Each website is different
28 % 4%
H 5 135 – 3
AUDITS DE SÉCURITÉ ET WEB _________________________________________________________________________________________________________
Les points décrits dans l’encadré 1 sont assimilés dans une
organisation où le cycle de développement logiciel est suffisam-
ment mature. Ce n’est malheureusement pas la généralité. L’audit
de sécurité peut être réalisé pour certaines « fausses bonnes
raisons », telles qu’être conforme à une exigence réglementaire ou
contractuelle. Malheureusement, dans ce dernier cas, la volonté de
respecter les aspects contractuels supplante la volonté réelle
d’avoir un niveau de sécurité en amélioration continue.
Toutefois, dans ce contexte d’insécurité, les audits de sécurité de
ses applications Web, mais aussi de ses infrastructures et organi-
sations, semblent nécessaires afin de réduire les risques. Mais tout
est une question de coûts et de moyens mis en œuvre pour assu-
rer un bon niveau de sécurité des applications Web. Le niveau de
sécurité dépend d’un tout, que ce soit au niveau :
– des développements applicatifs ;
– de la configuration des accès ;
– du socle d’hébergement.
Par conséquent, un audit complet est toujours nécessaire afin de
couvrir un maximum de risques. Les aspects organisationnels ne
sont pas à négliger, bien au contraire, puisqu’eux seuls permettent
de garantir un niveau de sécurité conforme aux attentes (les réfé-
rentiels) dans le temps.
Cet article aborde tout d’abord les risques de sécurité Web, puis
les techniques et outils de recherche de vulnérabilités Web, et
enfin un retour d’expérience.
Remarque
Le lecteur est invité à se reporter à l’article [H 5 130] où sont
recensées de nombreuses notions relatives au domaine de l’audit
de sécurité technique lesquelles ne sont alors pas reprises ici.
2. Risques de sécurité Web
Cette partie présente les principales classes de risques de sécurité
Web. Tout d’abord sont abordés leurs principes, mais aussi, sur cer-
taines classes de risques les plus courantes, le fonctionnement plus
de détaillé de l’exploitation de telles failles de sécurité.
2.1 À propos
L’Open Web Application Security Project (OWASP ) est une
communauté ouverte dont le but est de développer et maintenir
des outils et documents destinés à aider les organisations à
concevoir et développer des applications Web sécurisées.
Cette communauté est financée par la fondation OWASP depuis
2001, avec l’objectif de rendre indépendants les travaux de la
communauté vis-à-vis de toute pression commerciale. Le finance-
ment de cette fondation est réalisé grâce à une participation
financière des nombreux membres qui la composent (entreprises
et individuels). Pour information, la fondation a disposé d’un
budget 2012 d’un peu plus de 900 000 $.
Parmi les différents travaux engagés par l’OWASP, nous
pouvons citer le « OWASP Top 10 » qui est la référence sur les
risques les plus importants en sécurité des applications Web. Ne
présentant « que » les 10 risques les plus importants, il est à noter
que tous les types de vulnérabilités Web ne sont pas présents
dans ce document. La première édition avait été rendue publique
en 2003. Nous disposons aujourd’hui de la 5e version sortie en
2013. Ce document a pour but d’éduquer les entités réalisant du
développement Web, afin de les sensibiliser sur les risques les
plus critiques, tout en donnant les informations nécessaires pour
implémenter des mesures correctives ou préventives.
Dans le domaine du développement d’applications sur mobiles
qui est maintenant incontournable, l’OWASP a aussi diffusé un
H 5 135 – 4 Copyright © – Techniques de l’Ingénieur – Tous droits réservés
« OWASP Top 10 Mobile Risks » prenant en compte les nouvelles
problématiques de sécurité qui en découlent.
Enfin, l’institut System Administration, Networking, and Security
(SANS ) a publié un recensement des erreurs les plus dangereuses
dans le développement, appelé le « CWE/SANS Top 25 Most
Dangerous Software Errors ». Généraliste, il complète efficace-
ment le Top 10 OWASP qui, lui, est orienté Web.
Nota : consulter les adresses des sites Internet dans le Pour en savoir plus.
2.2 OWASP Top 10
Le « OWASP Top 10 » est composé des risques suivants :
– A1 Injection ;
– A2 Broken Authentication and Session Management ;
– A3 Cross-Site Scripting (XSS ) ;
– A4 Insecure Direct Object References ;
– A5 Security Misconfiguration ;
– A6 Sensitive Data Exposure ;
– A7 Missing Function Level Access Control ;
– A8 Cross-Site Request Forgery (CSRF ) ;
– A9 Using Components with Known Vulnerabilities ;
– A10 Unvalidated Redirects and Forwards.
La tableau 1 représente l’évolution entre l’OWASP Top 10 2010
et l’OWASP Top 10 2013. Nous constatons que la liste évolue avec
des catégories qui apparaissent et d’autres qui sont parfois mutua-
lisées. Le but est en effet d’être le plus cohérent possible avec les
évolutions constatées dans le domaine de la sécurité applicative
Web, d’où ces évolutions.
Dans cette partie, nous décrirons l’ensemble de ces classes de
risques, exemples à l’appui. Ce qui donnera au lecteur une exhaus-
tivité des failles de sécurité les plus présentes dans un contexte
Web. Nous en profiterons pour détailler avec précision certaines
vulnérabilités très répandues.
Top 10 OWASP (traduction française)
Une traduction française est disponible sur le site OWASP
(dont l’adresse Web figure dans le Pour en savoir plus ).
Cependant, pour des raisons de simplicité et d’ubiquité, nous
garderons la terminologie anglaise pour les titres des
différentes catégories de risques.
2.2.1 A1 Injection
« Une faille d’injection, telle l’injection Structured Query
Langage (SQL ), Operating System (OS ) et Lightweight Directory
Access Protocol (LDAP ), se produit quand une donnée non fiable
est envoyée à un interpréteur en tant qu’élément d’une commande
ou d’une requête. Les données hostiles de l’attaquant peuvent
duper l’interpréteur afin de l’amener à exécuter des commandes
fortuites ou accéder à des données non autorisées. » (source : Top
10 OWASP, traduction française).
Toutes les classes d’injection sont donc présentes dans cette
catégorie. Cela étant, les injections de commandes sont tout de
même de plus en plus rares. Subsistent par contre, de manière
assez importante, les injections SQL.
■ Détails sur l’injection SQL
L’injection SQL est une classe de vulnérabilités consistant à
détourner des requêtes SQL légitimes via une injection de code
SQL qui sera alors interprétée et exécutée par la base de donnée.
Plus généralement, comme toute faille liée à l’injection, il s’agit de
mélanger des « données » avec du « code ». Dans le cas de
 L’EXPERTISE TECHNIQUE
& SCIENTIFIQUE DE RÉFÉRENCE

Besoin de consulter les articles de l’offre :

“Sécurité des systèmes d’information” Abonnez-vous !

AU SOMMAIRE

 Méthodes pour mettre en place une politique de sécurité

en entreprise.

 Outils pour identifier et contrôler les différents types d’intrusions,

et pour prévenir les attaques.

 Informations pratiques pour garantir l’intégrité des données

en transit, sécuriser les accès Internet.

 Les dernières évolutions en matière de services mobiles

et d’authentification des utilisateurs et des machines.

DÉTAIL DE L’OFFRE ET SOMMAIRE COMPLET À RETROUVER SUR LE SITE

www.techniques-ingenieur.fr

De la conception au + de 10 000 articles

520 bases
prototypage, jusqu’à de référence
documentaires,
et 1 000 fiches
l’industrialisation, réparties
pratiques
Techniques de l’ingénieur dans 85 offres
opérationnelles
est l’outil de référence pour
sécuriser le développement 3 000 QUIZ
de vos projets industriels, 1280 auteurs 340 000
DANS + DE 1 000
contribuent utilisateurs
optimiser vos flux de ARTICLES
chaque année de techniques- INTERACTIFS
production et accélérer à enrichir ingenieur.fr
votre innovation produit. cette ressource chaque mois

NOS ÉQUIPES SONT Par téléphone Par email

À VOTRE DISPOSITION  33 (0)1 53 35 20 20  infos.clients@teching.com

www.techniques-ingenieur.fr