SlideShare a Scribd company logo
1 of 41
Download to read offline
OWASP Top 10 - 2010

rc1

Les 10 risques les plus critiques des
applications Web.
Sébastien Gioria (French Chapter
Leader & OWASP Global Education
Comittee Member)
sebastien.gioria@owasp.org
(english slides from Dave Wichers (COO, Aspect Security &
OWASP Boardmember) dave.wichers@owasp.org

)

Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the OWASP License.

The OWASP Foundation
http://www.owasp.org/
Qui suis-je ?
Consultant Sécurité au sein du cabinet de commissaires aux compte
Groupe Y (s.gioria@groupey.fr)
 Président du CLUSIR Poitou-Charentes
 OWASP France Leader & Evangéliste (sebastien.gioria@owasp.org)
 Membre du Comité OWASP d’Education


+12 ansd’expérience en Sécurité des Systèmesd’Information
Différentspostes de manager SSI dans la banque, l’assurance et
les télécoms
 Expertise Technique

PenTesting, Digital Forensics

S-SDLC

Gestion du risque, Architectures fonctionnelles, Audits

Consulting et Formation en Réseaux et Sécurité



Domaines de prédilection :
 Web 4.2 : WebServices, Insécurité du Web.


Quelssont les changements ?
On parle de risques, et non plus uniquement de
vulnérabilités.
• Le titre devient donc : “ Les 10 risques les plus critiques des applications Web”.

La méthodologie de calcul du risque de
l’OWASP Top 10
• Basée sur la méthodologie OWASP Risk Rating Methodology

2 risques ajoutés, 2 retirés
• Ajout: A6 – Mauvaise configuration
• Ex-A10 du Top10 2004 : Configuration non sécurisée

• Ajout: A8 – Redirections
• Très courant et très dangereux, et mal considéré

• Retiré: A3 – Execution de fichier malveillant
• Principalement une faille PHP…

• Retiré: A6 –Mauvaise gestion des erreurs et fuite d’informations
• Une faille très courante, ne générant que rarement un risque
Mapping Top10 2007 - Top 10 20
OWASP Top 10 – 2007 (Previous)

OWASP Top 10 – 2010 (New)

A2 – Injection Flaws

A1 – Injection

A1 – Cross Site Scripting (XSS)

A2 – Cross Site Scripting (XSS)

A7 – Broken Authentication and Session Management

A3 – Broken Authentication and Session Management

A4 – Insecure Direct Object Reference

= A4 – Insecure Direct Object References

A5 – Cross Site Request Forgery (CSRF)

= A5 – Cross Site Request Forgery (CSRF)

<was T10 2004 A10 – Insecure Configuration
Management>

+ A6 – Security Misconfiguration (NEW)

A10 – Failure to Restrict URL Access
<not in T10 2007>

A7 – Failure to Restrict URL Access

+ A8 – Unvalidated Redirects and Forwards (NEW)

A8 – Insecure Cryptographic Storage

A9 – Insecure Cryptographic Storage

A9 – Insecure Communications

A10 – Insufficient Transport Layer Protection

A3 – Malicious File Execution
A6 – Information Leakage and Improper Error Handling

-

<dropped from T10 2010>
<dropped from T10 2010>
Méthoded’évaluation du risque de l’OWASP Top 10

Exemplebasésur XSS
Threat
Agent

?

Attack
Vector

1
2
3

Weakness
Prevalence

Weakness
Detectability

Technical Impact

Easy

Widespread

Easy

Severe

Average

Common

Average

Moderate

Difficult

Uncommon

Difficult

Minor

2

1

1

2

1.3

*

Business
Impact

2

?

2.6Evaluation pondérée du risque
L’OWASP Top10 (2010 rc1)

http://www.owasp.org/index.php/Top_10
A1 – Injection
L’injection

• Envoyer à une application des données générant un comportement non
attendu.
Les Interpréteurs
• Utilisent les chaines et les interpretent comme des commandes
• SQL, OS Shell, LDAP, XPath, Hibernate, etc…
L’injection SQL est toujours commune

• Enormément d’applications y sont sensibles
• Même s’il est très simple de s’en affranchir….
Impact
• Souvent très sévère. Le plupart du temps l’ensemble des données de la base
sont lisibles ou modifiables.
• Cela peut même aller jusqu’au schéma de la base, les comptes ou un accès
OS….
ATTACK




App Server

Billing

Directories



Acct:5424-9383-2039-4029
Acct:4128-0004-1234-0293

3.L’application transfère les
données à la requête SQL

Web Server

Firewall

Hardened OS

Firewall

DB Table


"SELECT * FROM
Account Summary
Account:
accounts WHERE
SKU:
acct=‘’ OR 1=1-Acct:5424-6066-2134-4334
Acct:4128-7574-3921-0192
’"
1. L’application fourni un
formulaire
2. L’attaquant envoi son attaque
dans les données du formulaire

Custom Code

Network Layer

Human Resrcs



Web Services

HTTP
SQL
response
query


HTTP
request
APPLICATION

Legacy Systems

Databases

Communication
Knowledge Mgmt
E-Commerce
Bus. Functions

Administration
Transactions

Accounts
Finance

Application Layer

Exemple sur l’injection SQL

4. Le SGBD lance la requête
contenant l’attaqueet renvoie le
résultats à l’application.

5. L’application renvoie ce résultat
à l’utilisateur
A1 – Comment se protéger
 Recommandations
1. Se passer des interpréteurs,
2. Utiliser une interface permettant de préparer les requêtes (ex,
prepared statements, or les procédures stockées),
3. Encoder toutes les données fournies par l’utilisateur avant de les
passer à l’interpréteur
 Toujours effectuer une validation de type “white liste” sur les
données utilisateurs.
 Minimiser les privilèges dans les bases pour limiter l’impact de la
faille.

 References
 Plus de détails sur

http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
A2 – Cross-Site Scripting (XSS)
Se retrouve à chaque audit/pentest
• Des données venant d’un attaquant sont envoyé à l’innocent navigateur d’un
utilisateur

Ces données peuvent être
• Stockées en base,
• Réfléchies depuis une entrée d’une page Web (champ de formulaire, champ
caché, URL, …)
• Envoyé directement à un client Riche (Javascript, Flash, …)
Virtuellement toute application Web est vulnérable
• Essayez cela dans votre navigateur – javascript:alert(document.cookie)
Impact
• Vole des sessions utilisateur, de données sensibles, réécriter de la page Web,
reidrection vers un site d’hameconnage ou autre code malveillant
• De manière plus grave : installation d’un proxy XSS permettant à un attaquant
d’observer le poste client voir de forcer l’utilisateur vers un site particulier
Cross-Site Scripting Illustré
1

L’attaquant découvre le script vulnérable

La victime se rend sur la page

Custom Code

Le Script s’execute sur le
navigateur de la victime
sans qu’il ne le sache

3

L’attaquant recoit le cookie ou autre élément directement

Communication
Knowledge Mgmt
E-Commerce
Bus. Functions

2

Accounts
Finance

L’attaquant entre un script
malicieux sur la page
web(stocké) ou bien utilise un
lien(réfléchi) permettant
d’envoyer vers la page

Administration
Transactions

Application disposant
de faille XSS
A2 – Contremesures
 Recommandations
 Supprimer la faille 


Ne pas inclure de contenu fourni par l’utilisateur dans la page de
sortie !!!

 Défenses possibles
1. Encoder toutes les entrées et sorties utilisateurs (utilisez l’OWASP
ESAPI pour l’encodage de sortie)
http://www.owasp.org/index.php/ESAPI
2. Effectuer de la validation de type « white liste » pour les données
utilisateurs entrantes qui sont inclues dans une page.
3. Pour des grosses portions de code HTML fournie par un utilisateur,
utiliser le filtre OWASP Anti-Sammy de manière à nettoyer l’HTML
Voir: http://www.owasp.org/index.php/AntiSamy

 Référence
 Pour effectuer un encodage propre, ce référer à

http://www.owasp.org/index.php/XSS_(Cross Site Scripting) Prevention Cheat Sheet

(AntiSamy
A3 – Mauvaise gestion des sessions et de
l’authentification
HTTP est un protocole sans état
• Les identifiants doivent donc être passés a chaque requete.
• Il faut utiliser SSL pour toute authentification
Failles dans la gestion de l’authentification
• Des ID de sesisons sont utilisés pour maintenir la session dans HTTP car il ne le
peut lui.
• Cela suffit à un attaquant, c’est aussi interessant qu’un identifiant
• Les ID de sessions sont souvent exposés dans les sessions réseau, dans les
browsers (cookies), dans les logs, ….
Attention aux portes dérobées…
• Changement de mot de passe, se souvenir de mon passe, oubli de mot de passe,
questions secretes, logout, email, …
Impact
• Vol de session ou compromission de comptes utilisateur
www.boi.com?JSESSIONID=9FA1DB9EA...

Le site récrit l’URL
(i.e., mise dans l’URL de l’ID
de session)

3

5

L’attaquant peut utiliser le
JSESSIONID sur le site
boi.com pour son méfait

Custom Code

2

L’utilisateur clique sur un lien vers
http://www.hacker.com dans un forum

L’attaquant regarde les logs “Referer” sur
www.hacker.com
Et découvre le JSESSIONID

Communication
Knowledge
Mgmt
E-Commerce
Bus. Functions

Utilisateur envoie ses
identifiants

Accounts
Finance

1

Administration
Transactions

Illustration d’une mauvaise authentification

4
A3 – ContreMesure
 Vérifier l’architecture !
 L’authentification doit être simple, centralisée et standardisée
 Utiliser le mécanisme standard de gestion des cookies du
framework (ils sont globalement fiable)
 Utiliser constamment SSL pour protéger les identifiants de
connexion et de sessions

 Vérifier l’implémentation
 Oublier l’analyse automatique
 Vérifier le certificat SSL (SSLv2, renégociation, chiffrement
faible, …)
 Examiner toutes les fonctions relatives a l’authentification
 Vérifier que la déconnexion supprime bien la session !
 Utiliser l’OWASP WebScarab pour tester l’implémentation
(sessionIDanalysis)
A4 – Référencedirecte non sécuriséeà un
objet
Comment accéder aux données privées
• C’est une manière de renforcerles habilitations en lien avec
A7 – Mauvaise restriction d’accès à une URL
Des erreurs classiques
•
•
•
•

Attendre uniquement de l’utilisateur des accès à des objets autorisés ou
Cacher des références à des objets dans des champs cachés
… et ne pas renforcer les restrictions coté serveur.
Ceci n’est qu’une tentative de contrôle d’accès sur la présentation et ne
fonctionne pas !
• Un attaquant n’a qu’a modifier les valeurs des paramètres…
Impact
• Un utilisateur a accès à des données ou des fichiers normalemtn
interdits
Référence directe non sécurisée à un objet
illustrée
https://www.onlinebank.com/user?acct=6065

 L’attaquant note le
paramètre acct = 6065
?acct=6065
 Il modifie celui-ci de la
manière suivante
?acct=6066
 L’attaquant visualise un
autre compte.
A4 – Contre Mesure
 Eliminer la référence directe.
 La remplacer par une valeur temporaire aléatoire (e.g. 1, 2, 3)
 L’ESAPI fournit des fonctions pour cela
 IntegerAccessReferenceMap &RandomAccessReferenceMap

http://app?file=Report123.xls
http://app?file=1
http://app?id=9182374
http://app?id=7d3J93

Access
Reference
Map

Report123.xls
Acct:9182374

 Valider la référence directe à l’objet
 Vérifier que le contenu est correctement formaté.
 Vérifier que l’utilisateur a le droit d’effctuer l’accès à l’objet.
 Vérifier que le mode d’accès à l’objet est autorisé
(e.g., read, write, delete)
A5 – Cross Site Request Forgery (CSRF)
Cross Site Request Forgery
• C’est une attaque ou le navigateur de la victime génère une requête vers une
application Web vulnérable
• Cette vulnérabilité est causée par la capacité qu’on les navigateurs a envoyer
automatiquement des données d’authentification (session ID, IP address,
comptes de domaine windows, ..) dans chaque requête.
Imaginez
• Que se passerait-il si un hacker pouvait utiliser votre souris pour effectuer des
clicks sur votre site de banque en ligne a votre place.
• Que pourrait-il faire ?
Impact
• Initiation de transactions (transfert de fonds, logoff, modification de
données, …)
• Accès à des données sensibles
• Changement des mots de passes/identifiants
CSRF démystifié
 Le problème
 Les navigateurs Web incluent automatiquement la plupart des
identifiants dans chaque requête.
 Que cela soit des requêtes venant d’un formulaire, d’une image ou
d’un autre site.

 Tous les sites basés uniquement sur les identifiants
automatiques sont vulnérables
 Approximativement 100% des sites le sont…

 C’est quoi un identifiant automatique?
 Cookie de session
 Header d’authentification HTTP
 Une adresse IP
 Les certificats SSL client
 L’authentification de domaine Windows.
CSRF illustré
L’attaquant pose son piège sur un site internet (ou via un e-mail)
1

Communication
Knowledge
Mgmt
E-Commerce
Bus. Functions

Tout en étant logguer sur le site vulnérable, la victime
parcourt le site de l’attaquant.

Administration
Transactions

2

Accounts
Finance

Un tag chaché <img>
contient une attaque
vers un site vulnérable

Application vulnérable
au CSRF

Custom Code

3
Le tag <img> tag chargé
par le navigateur envoie
une requête GET
(contenant des identifiants
sur le site vulnérable)

Le site vulnérable ne
voie que des requêtes
légitimes et effectue
l’action demandée
A5 – ContreMesure
 Ajouter un jeton, non envoyé automatiquement, a toutes les requêtes
sensibles.
 Cela rend impossible pour l’attaquant de soumettre une requête valide.
 (sauf si en plus il y a une faille XSS)
 Ces jetons doivent être surs cryptographiquement.

 Options

 Stocker un seul jeton dans la session et l’ajouter a tous les formulaire et liens

 Champ caché: <input name="token" value="687965fdfaew87agrde"
type="hidden"/>
 Utiliser un URL : /accounts/687965fdfaew87agrde
 Utiliser un jeton de formulaire: /accounts?auth=687965fdfaew87agrde…

 Attention a ne pas exposer le jeton dans l’entete “referer”
 Utiliser de préférence un champ caché.
 Utiliser un jeton unique par fonction.
 Il est recommandé d’ajouter un second niveau d’authentification pour une
transaction sensible

 Ne pas laisser un attaquant stocker des attaques sur le site
 Encoder proprement les données d’entrées
 Cela permet de limiter la majorité des interpréteurs de liens

Voir www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet pour plus de détails
A6 – Mauvaise configuration
Les applications Web doivent faire confiance à une
fondation sécurisée
• On pense aux réseau, aux système et aux plateformes
• Il ne faut pas oublier les environnements de développement
Est-ce que votre code source est secret?
• Pensez a tous les endroits ou l’on trouve votre code source.
• La Sécurité ne doit pas se baser sur l’obscurité du code source.
Il faut étendre la gestion de la configuration a toutes les
parties de l’application
• Tous les identifiants doivent être changés sur les environnements de
production
Impact
• Installation d’une porte dérobée via un oubli de patch (serveur, réseau,…)
• Failles XSS exploitées due à l’oublie de patch dans les framework
• Accès non authorisé à des comptes , des données, ou des fonctionnalités
applicatives par défaut non utilisées mais accessibles a cause d’une
mauvaise configuration utilisateur
Communication
Knowledge Mgmt
E-Commerce
Bus. Functions

Administration
Transactions

Accounts
Finance

Mauvaise configuration illustrée

Database

Custom Code
App Configuration

Framework

Development

App Server
QA Servers
Web Server

Insider

Hardened OS
Test Servers

Source Control
A6 – Contre Mesure
 Vérifier la gestion de la configuration sécurité de vos systèmes.
 Ayez des guidelines de renforcement de la sécurité.
 L’automatisation est réellement utile dans ce cas

 Couvrir toute la plateforme et l’application
 Garder a l’esprit d’avoir des patchs pour TOUS les composants
 Cela inclue les librairies, et pas seulement l’OS, les serveurs et applications.

 Analyser l’impact sécurité des changements

 Pouvez vous effectuer des “masters” de votre configuration
applicative ?
 Mettre en place un reporting des builds dans le processus sécurité
 Si vous ne pouvez vérifier le configuration applicative, l’applicatif n’est
pas sécurisé

 Vérifier l’implémentation
 Les scans découvrent généralement les configurations par défaut et les
problèmes du à des patchs de retard
A7 – Mauvaise restriction d’URL
Comment protéger vous l’accès à une URL ?
• Cela concerne aussi le renforcement des l’habilitations tout comme
le paragraphe A4

Une erreur commune…
• N’afficher que les liens et menus authorisés dans les listes de choix.
• Une fois de plus, c’est du controle d’accès visuel, et cela ne fonctionne
pas.
• Il suffit de modifier les requêtes en allant diretement sur les pages
“non autorisées”
Impact
• Invocation de fonctions et de services non authorisées
• Accès a des données ou des comptes n’appartenant pas à l’utilisateur
• Elevation de privilèges et d’actions
Mauvaise restriction d’URLillustrée

https://www.onlinebank.com/user/getAccounts

 L’attaquant note
dansl’URLque le
rôleestaffiché
/user/getAccounts
 Il
modifiedirectementl’URL
(le rôle)
/admin/getAccounts, ou
/manager/getAccounts
 L’attaquant dispose de
privilègessupplémentaires
A7 – Contre Mesure
 Pour tout URL il faut 3 éléments :
 Restreindre l’accès aux seuls utilisateurs authentifiés (sauf si l’URL est publique).
 Renforcer les permissions basées sur les rôles ou l’utilisateue (si l’URL est privée)
 Bloquer toute requête à des pages non autorisées ( (e.g., fichiers de config, de
log, code source, etc.)

 Vérifier l’architecture
 Utiliser un modèle positif simple a tous les niveaux
 S’assurer d’avoir un modèle d’accès à tous les niveaux.

 Vérifier l’implémentation
 Oublier l’approche automatisée
 Vérifier que chaque URL de l’application est protégée par :
 Un filtre externe, comme en J2EE (web.xml)
 Ou par un morceau de VOTRE code – Voir la méthode ESAPI’ isAuthorizedForURL()

 Vérifier que la configuration du serveur n’autorise pas les requêtes vers les types
de fichiers ou extensions non autorisés.
 Utiliser un proxy type WebScarab pour forger des requêtes non autorisées.
A8 – Redirections et transferts non contrôlés
Les redirections sont communes dans une application WEB.
• Et fréquemment elles incluent des paramètres fournis par l’utilisateur dans l’URL
de destination.
• Si ces paramètres ne sont pas validés, un attaquant peut envoyer la victime vers
le site de son choix.

Les transferts(aka Transfer en .NET) sont eux aussi
communs
• Ils renvoient la requête vers une nouvelle page en interne de l’application.
• Parfois les paramètres déterminent la page cible.
• Si cela n’est pas validé, cela permet de parfois passer outre les mécanismes
d’autorisation et d’authentification.
Impact

• Rediriger la victime vers un site malveillant de type hameconnage.
• Il devient possible de passer outre les contrôles de sécurité et accéder à des
fonctions ou données non autorisées.
Redirection illustrée
L’attaquant envoi à la victime via un email ou une page
Web de son choix le lien.

Bus. Functions

E-Commerce

Knowledge Mgmt

Communication

Transactions

La vicitime clique sur le lien contenant une donnée
non validée.

L’application redirige
la victime vers le site de
l’attaquant

Administration

2

3

Finance

From: Internal Revenue Service
Subject: YourUnclaimedTaxRefund
Our records show you have an
unclaimedfederaltaxrefund. Please
click here to initiateyour claim.

Accounts

1

Custom Code

Request sent to vulnerable
site, including attacker’s
destination site as parameter.
Redirect sends victim to
attacker site

http://www.irs.gov/taxrefund/claim.jsp?year=2006
&… &dest=www.evilsite.com

Evil Site

4

Le site malveillant installe des
éléments sur le navigateur ou
récupére des données
Unvalidated Forward Illustrated
1

L’attaquant envoie sa charge sur une page vulnérable ou il a
accès
Request sent to
vulnerable page which
user does have access to.
Redirect sends user
directly to private page,
bypassing access control.

2

L’application autorise la
requête et continue vers
la page vulnérable

public void sensitiveMethod(
HttpServletRequest
request, HttpServletResponse
response) {
try {
// Do sensitive stuff here.
...
}
catch ( ...

Filtre

public void doPost( HttpServletRequest
request, HttpServletResponse response) {
try {
String target = request.getParameter( "dest" ) );
...
request.getRequestDispatcher( target
).forward(request, response);
}
catch ( ...

3

La page de transfert ne contrôle pas
le paramètre et renvoie l’attaquant
vers la page non autorisée, passant
outre le contrôle d’accès.
A8 – Contre Mesure
 Il y a des tonnes de solutions
1. Eviter au maximum les redirections et les transferts
2. Si il faut absolument les utiliser, ne pas utiliser les paramètres parvenant d’un
utilisateur pour définir l’URL/fonction cible.
3. Si vous “devez” utiliser les paramètres utilisateurs,
a)

Validez chaque paramètre pour vérifier qu’il est autorisé et valide par rapport à
l’utilisateur, ou alors
b) Utilisez une table de correspondance serveur entre les paramètres utilisateurs et les
pages à appeler.

 Pour les redirection, valider l’URL cible après la construction pour vérifier qu’elle
redirige bien vers un site autorisé !
 L’ESAPI peut vous aider :


Voir : SecurityWrapperResponse.sendRedirect( URL )



http://owasp-esapi-java.googlecode.com/svn/trunk_doc/org/owasp/esapi/filters/
SecurityWrapperResponse.html#sendRedirect(java.lang.String)

 Quelques réflexions sur les Transferts
 Idéallement, il faudrait appeler le contrôle d’accès pour être sur que l’utilisateur
est bien autorisé aà effecgtuer le transfert(très simple avec l’ESAPI…)
 Si vous utilisez des filtres externes (comme SiteMinder), cela ne sera pas simple
 La meilleure solution est de s’assurer que les utilisateurs qui ont accès à la page
initiale ont TOUS le droit d’accéder à la page cible….
A9 – Stockage Cryptographique non sécurisé
Le stockage de données non sécurisées
• Oubli d’identification des données sensibles
• Oubli d’identification de tous les entrepôts de stockage des
données sensibles.
• Bases de données, fichiers, répertoires, fichiers de logs, backup, …

• Oubli de mettre en place une protection correcte des données dans
tous les entrepots de stockages des données sensibles.

Impact
• Modification ou accès a des données confidentielles ou privées (carte
de crédits, données santés, données financières, …)
• Extrait de données secretes via d’autres failles (injection SQL, LDAP, …)
• Problème d’image de marque, d’image client et perte de confiance
• Long et couteux processus de vérification, investigation et retour a la
normale (forensics, lettres et dédommagements client, assurance, …)
1

La victime stocke son
numéro de carte de
crédit dans le système
via un formulaire

Accounts
Finance
Administration
Transactions
Communication
Knowledge
Mgmt
E-Commerce
Bus. Functions

Stockage non sécurisé illustré

Custom Code

4

Fichier de log

Une personne
malveillante interne
vole 4 millions de
carte de crédit
Les logs sont rendus
disponibles pour tous les
membres internes dans le
but du debug

3

Le gestionnaire des
erreurs loggue le numéro
de carte car la passerelle
de commerce est
indisponible.

2
A9 – ContreMesure
 Vérifier l’architecture
 Identifier toutes les données sensibles
 Identifier tous les entrepots de stockage des données
 S’assurer des attaques possibles sur comptes

 Utiliser un mécanisme de chiffrement approprié
 Chiffrement de fichier, de base, d’élément de la base.

 Utiliser correctement le mécanisme…
 Utiliser des algorithmes connus standard et surs.
 Générer, distribuer et protéger les clefs
 S’assurer de la capacité de changement régulier des clefs

 Vérifier l’implémentation
 Un algorithme sur est utilisé et c’est le bon algorithme pour la situation !
 Toutes les clefs, certificats, et mots de passe sont stockés et protégés correctement.
 Il existe une distribution propre des clefs et il est possible d’en changer facilement
A10 – Protection insuffisante lors du
transport des données
La transmission de données non sécurisée…
• Oubli de l’identification de TOUTES les données sensibles
• Oubli de l’identification de TOUTES les URLs/Pages ou les données
sensibles transitent.
• Sur le Web, vers les SGBD, vers les partenaires métiers, vers les réseaux
internes…

• Oubli de protéger les données à chacun de ces endroits…

Impact
• Modification ou accès a des données confidentielles ou privées (carte
de crédits, données santés, données financières, …)
• Extrait de données secretes via d’autres failles (injection SQL, LDAP,
…)
• Problème d’image de marque, d’image client et perte de confiance
• Long et couteux processus de vérification, investigation et retour a la
normale (forensics, lettres et dédommagements client, assurance)
Protection insuffisante lors du transport des
données illustré

Partenaire métier

Victimeexterne
Custom Code

Backend Systems

Employées
1
Vols de données
via le
réseauexterne
Attaquantexterne

2

Vol de données via le
réseau interne
Attaquant interne
A10 – ContreMesure
 Utiliser les mécanismes de protection appropriés
 Utiliser TLS pour tout transport de données sensible.
 Chiffrer les messages avant transmission.
 E.g., XML-Encryption
 Signer les messages avant transmission
 E.g., XML-Signature

 Utiliser les mécanismescorrectement !
 Utiliser des algorithmessurs ! (désactiver les vieilles versions de
SSL et les chiffrementsfaibles…)
 Gérercorrectement les clefs/certificats.
 Vérifier les certificats SSL avantl’utilisation.
 Voirhttp://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet
pour plus de details
En résumé : comment adresser ces risques
 Développer du code sécurisé !
 Suivre les bonnes pratiques du Guide OWASP sur la construction sécurisée d’une
application Web.
 http://www.owasp.org/index.php/Guide

 Utiliser l’OWASP Application Security Verification Standard comme un guide
permettant de définir les mécanismes de sécurité
 http://www.owasp.org/index.php/ASVS

 Utiliser les composants de sécurité standard et s’adaptant le mieux a votre
entreprise
 Par exemple utiliser l’OWASP ESAPI comme une fondation a VOS composants standards
 http://www.owasp.org/index.php/ESAPI

 Auditer les applications
 Faire appel a une équipe expérimentée pour analyser et auditer l’application.
 Auditer les applications vous-meme graçe aux guide de l’OWASP
 OWASP Code Review Guide:
http://www.owasp.org/index.php/Code_Review_Guide
 OWASP Testing Guide:
http://www.owasp.org/index.php/Testing_Guide
Your Existing Enterprise Services or Libraries

ESAPI Homepage: http://www.owasp.org/index.php/ESAPI
SecurityConfiguration

IntrusionDetector

Logger

Exception Handling

Randomizer

EncryptedProperties

Encryptor

HTTPUtilities

Encoder

Validator

AccessReferenceMap

AccessController

User

Authenticator

OWASP (ESAPI)
Custom Enterprise Web Application
OWASP Enterprise Security API
Remerciements
 Les contribueurs principaux
 Aspect Security pour le sponsoring du projet
 Jeff Williams (auteur du premier Top10 en2003 )
 Dave Wichers (auteur et responsible actuel du projet )

 Les organisations ayant contribué aux statistiques sur les
vulnérabilitées
 Aspect Security
 MITRE
 Softtek
 White Hat

 Les contributeurs et relecteurs :
 Mike Boberski, Juan Carlos Calderon, Michael Coates, Jeremiah
Grossman, Paul Petefish, Eric Sheridan, Andrew van der Stock

More Related Content

What's hot

Sécurité des Applications WEB -LEVEL1
 Sécurité des Applications WEB-LEVEL1 Sécurité des Applications WEB-LEVEL1
Sécurité des Applications WEB -LEVEL1Tarek MOHAMED
 
Sécurité des applications web: attaque et défense
Sécurité des applications web: attaque et défenseSécurité des applications web: attaque et défense
Sécurité des applications web: attaque et défenseAntonio Fontes
 
Les principales failles de sécurité des applications web actuelles
Les principales failles de sécurité des applications web actuellesLes principales failles de sécurité des applications web actuelles
Les principales failles de sécurité des applications web actuellesBee_Ware
 
Les firewalls applicatifs HTTP / WAF
Les firewalls applicatifs HTTP / WAFLes firewalls applicatifs HTTP / WAF
Les firewalls applicatifs HTTP / WAFSylvain Maret
 
La sécurité sur le web
La sécurité sur le webLa sécurité sur le web
La sécurité sur le webSofteam agency
 
Securite des Applications dans le Cloud
Securite des Applications dans le CloudSecurite des Applications dans le Cloud
Securite des Applications dans le CloudSebastien Gioria
 
Introduction vulnérabilité web
Introduction vulnérabilité webIntroduction vulnérabilité web
Introduction vulnérabilité webdavystoffel
 
Sécurité des applications Web
Sécurité des applications WebSécurité des applications Web
Sécurité des applications WebKlee Group
 
Waf, le bon outil, la bonne administration
Waf, le bon outil, la bonne administration Waf, le bon outil, la bonne administration
Waf, le bon outil, la bonne administration Bee_Ware
 
Presentation des failles_de_securite
Presentation des failles_de_securitePresentation des failles_de_securite
Presentation des failles_de_securiteBorni Dhifi
 
White paper - La sécurisation des web services
White paper - La sécurisation des web servicesWhite paper - La sécurisation des web services
White paper - La sécurisation des web servicesBee_Ware
 
Securite applicative et SDLC - OWASP Quebec - 15 avril 2014
Securite applicative et SDLC - OWASP Quebec - 15 avril 2014 Securite applicative et SDLC - OWASP Quebec - 15 avril 2014
Securite applicative et SDLC - OWASP Quebec - 15 avril 2014 Patrick Leclerc
 
Sécurité des applications Web
Sécurité des applications WebSécurité des applications Web
Sécurité des applications WebSylvain Maret
 
Securing your API and mobile application - API Connection FR
Securing your API and mobile application - API Connection FRSecuring your API and mobile application - API Connection FR
Securing your API and mobile application - API Connection FRSebastien Gioria
 
La Quete du code source fiable et sécurisé - GSDAYS 2015
La Quete du code source fiable et sécurisé - GSDAYS 2015La Quete du code source fiable et sécurisé - GSDAYS 2015
La Quete du code source fiable et sécurisé - GSDAYS 2015Sebastien Gioria
 
Sécurité des web services soap
Sécurité des web services soapSécurité des web services soap
Sécurité des web services soapZakaria SMAHI
 

What's hot (20)

Sécurité des Applications WEB -LEVEL1
 Sécurité des Applications WEB-LEVEL1 Sécurité des Applications WEB-LEVEL1
Sécurité des Applications WEB -LEVEL1
 
Sécurité des applications web: attaque et défense
Sécurité des applications web: attaque et défenseSécurité des applications web: attaque et défense
Sécurité des applications web: attaque et défense
 
Les principales failles de sécurité des applications web actuelles
Les principales failles de sécurité des applications web actuellesLes principales failles de sécurité des applications web actuelles
Les principales failles de sécurité des applications web actuelles
 
Failles de sécurité
Failles de sécuritéFailles de sécurité
Failles de sécurité
 
Sécurité des applications web
Sécurité des applications webSécurité des applications web
Sécurité des applications web
 
Les firewalls applicatifs HTTP / WAF
Les firewalls applicatifs HTTP / WAFLes firewalls applicatifs HTTP / WAF
Les firewalls applicatifs HTTP / WAF
 
La sécurité sur le web
La sécurité sur le webLa sécurité sur le web
La sécurité sur le web
 
Securite des Applications dans le Cloud
Securite des Applications dans le CloudSecurite des Applications dans le Cloud
Securite des Applications dans le Cloud
 
Introduction vulnérabilité web
Introduction vulnérabilité webIntroduction vulnérabilité web
Introduction vulnérabilité web
 
Sécurité des applications Web
Sécurité des applications WebSécurité des applications Web
Sécurité des applications Web
 
Waf, le bon outil, la bonne administration
Waf, le bon outil, la bonne administration Waf, le bon outil, la bonne administration
Waf, le bon outil, la bonne administration
 
20100114 Waf V0.7
20100114 Waf V0.720100114 Waf V0.7
20100114 Waf V0.7
 
Presentation des failles_de_securite
Presentation des failles_de_securitePresentation des failles_de_securite
Presentation des failles_de_securite
 
White paper - La sécurisation des web services
White paper - La sécurisation des web servicesWhite paper - La sécurisation des web services
White paper - La sécurisation des web services
 
Securite applicative et SDLC - OWASP Quebec - 15 avril 2014
Securite applicative et SDLC - OWASP Quebec - 15 avril 2014 Securite applicative et SDLC - OWASP Quebec - 15 avril 2014
Securite applicative et SDLC - OWASP Quebec - 15 avril 2014
 
Sécurité des applications Web
Sécurité des applications WebSécurité des applications Web
Sécurité des applications Web
 
Securing your API and mobile application - API Connection FR
Securing your API and mobile application - API Connection FRSecuring your API and mobile application - API Connection FR
Securing your API and mobile application - API Connection FR
 
La Quete du code source fiable et sécurisé - GSDAYS 2015
La Quete du code source fiable et sécurisé - GSDAYS 2015La Quete du code source fiable et sécurisé - GSDAYS 2015
La Quete du code source fiable et sécurisé - GSDAYS 2015
 
Sécurité des web services soap
Sécurité des web services soapSécurité des web services soap
Sécurité des web services soap
 
Sécurité des réseaux
Sécurité des réseauxSécurité des réseaux
Sécurité des réseaux
 

Viewers also liked

[Lithuania] Cross-site request forgery: ways to exploit, ways to prevent
[Lithuania] Cross-site request forgery: ways to exploit, ways to prevent[Lithuania] Cross-site request forgery: ways to exploit, ways to prevent
[Lithuania] Cross-site request forgery: ways to exploit, ways to preventOWASP EEE
 
Frameworks php - Solutions Linux 2008
Frameworks php - Solutions Linux 2008Frameworks php - Solutions Linux 2008
Frameworks php - Solutions Linux 2008Eric D.
 
Facebook et twitter pour les professionnels
Facebook et twitter pour les professionnelsFacebook et twitter pour les professionnels
Facebook et twitter pour les professionnelsPoleNumeriqueNormand
 
La veille de né kid du 25.11.10 : l'économie de la conservation
La veille de né kid du 25.11.10 : l'économie de la conservationLa veille de né kid du 25.11.10 : l'économie de la conservation
La veille de né kid du 25.11.10 : l'économie de la conservationNé Kid
 
Platicas de frutas
Platicas de frutasPlaticas de frutas
Platicas de frutasrauliki
 
La veille de né kid du 15.09.2010 : le folklore du web
La veille de né kid du 15.09.2010 : le folklore du webLa veille de né kid du 15.09.2010 : le folklore du web
La veille de né kid du 15.09.2010 : le folklore du webNé Kid
 
La veille de né kid du 18.11.2010 : la zététique
La veille de né kid du 18.11.2010 : la zététiqueLa veille de né kid du 18.11.2010 : la zététique
La veille de né kid du 18.11.2010 : la zététiqueNé Kid
 
La veille de Né Kid du 26.05.11 : le kitsch
La veille de Né Kid du 26.05.11 : le kitschLa veille de Né Kid du 26.05.11 : le kitsch
La veille de Né Kid du 26.05.11 : le kitschNé Kid
 
Evolutions 2012 / 2013
Evolutions 2012 / 2013Evolutions 2012 / 2013
Evolutions 2012 / 2013XWiki
 
1images de verbes_de_sens_contraire-2
1images de verbes_de_sens_contraire-21images de verbes_de_sens_contraire-2
1images de verbes_de_sens_contraire-2Maria Firou
 
Como lograr que cada persona que lo contacte a usted le compre o le compre ut...
Como lograr que cada persona que lo contacte a usted le compre o le compre ut...Como lograr que cada persona que lo contacte a usted le compre o le compre ut...
Como lograr que cada persona que lo contacte a usted le compre o le compre ut...Xazuke
 

Viewers also liked (20)

[Lithuania] Cross-site request forgery: ways to exploit, ways to prevent
[Lithuania] Cross-site request forgery: ways to exploit, ways to prevent[Lithuania] Cross-site request forgery: ways to exploit, ways to prevent
[Lithuania] Cross-site request forgery: ways to exploit, ways to prevent
 
Frameworks php - Solutions Linux 2008
Frameworks php - Solutions Linux 2008Frameworks php - Solutions Linux 2008
Frameworks php - Solutions Linux 2008
 
Richar
RicharRichar
Richar
 
Directrices1290
Directrices1290Directrices1290
Directrices1290
 
Jaccepte
JaccepteJaccepte
Jaccepte
 
Jeu Questionnaire
Jeu QuestionnaireJeu Questionnaire
Jeu Questionnaire
 
Facebook et twitter pour les professionnels
Facebook et twitter pour les professionnelsFacebook et twitter pour les professionnels
Facebook et twitter pour les professionnels
 
La veille de né kid du 25.11.10 : l'économie de la conservation
La veille de né kid du 25.11.10 : l'économie de la conservationLa veille de né kid du 25.11.10 : l'économie de la conservation
La veille de né kid du 25.11.10 : l'économie de la conservation
 
Platicas de frutas
Platicas de frutasPlaticas de frutas
Platicas de frutas
 
Tarea final
Tarea finalTarea final
Tarea final
 
La veille de né kid du 15.09.2010 : le folklore du web
La veille de né kid du 15.09.2010 : le folklore du webLa veille de né kid du 15.09.2010 : le folklore du web
La veille de né kid du 15.09.2010 : le folklore du web
 
Infokiosque
InfokiosqueInfokiosque
Infokiosque
 
La veille de né kid du 18.11.2010 : la zététique
La veille de né kid du 18.11.2010 : la zététiqueLa veille de né kid du 18.11.2010 : la zététique
La veille de né kid du 18.11.2010 : la zététique
 
La veille de Né Kid du 26.05.11 : le kitsch
La veille de Né Kid du 26.05.11 : le kitschLa veille de Né Kid du 26.05.11 : le kitsch
La veille de Né Kid du 26.05.11 : le kitsch
 
Evolutions 2012 / 2013
Evolutions 2012 / 2013Evolutions 2012 / 2013
Evolutions 2012 / 2013
 
Taller ccita 2010
Taller ccita 2010Taller ccita 2010
Taller ccita 2010
 
valores
 valores valores
valores
 
1images de verbes_de_sens_contraire-2
1images de verbes_de_sens_contraire-21images de verbes_de_sens_contraire-2
1images de verbes_de_sens_contraire-2
 
Antonio gonzalez
Antonio gonzalezAntonio gonzalez
Antonio gonzalez
 
Como lograr que cada persona que lo contacte a usted le compre o le compre ut...
Como lograr que cada persona que lo contacte a usted le compre o le compre ut...Como lograr que cada persona que lo contacte a usted le compre o le compre ut...
Como lograr que cada persona que lo contacte a usted le compre o le compre ut...
 

Similar to Owasp top 10 2010 Resist toulouse

Securitedesapplications 091011120426-phpapp02
Securitedesapplications 091011120426-phpapp02Securitedesapplications 091011120426-phpapp02
Securitedesapplications 091011120426-phpapp02Asma Messaoudi
 
Epitech securite-2012.key
Epitech securite-2012.keyEpitech securite-2012.key
Epitech securite-2012.keyDamien Seguy
 
20090929 04 - Securité applicative, hacking et risque applicatif
20090929 04 - Securité applicative, hacking et risque applicatif20090929 04 - Securité applicative, hacking et risque applicatif
20090929 04 - Securité applicative, hacking et risque applicatifLeClubQualiteLogicielle
 
Webinaire : sécurité informatique sur le web - Jérôme Thémée
Webinaire : sécurité informatique sur le web - Jérôme ThéméeWebinaire : sécurité informatique sur le web - Jérôme Thémée
Webinaire : sécurité informatique sur le web - Jérôme ThéméeMarie Tapia
 
Securité des applications web
Securité des applications webSecurité des applications web
Securité des applications webMarcel TCHOULEGHEU
 
Introduction à la sécurité des applications web avec php [fr]
Introduction à la sécurité des applications web avec php [fr]Introduction à la sécurité des applications web avec php [fr]
Introduction à la sécurité des applications web avec php [fr]Wixiweb
 
Conférence #nwxtech2 : Sécurité web/PHP par Maxime Mauchaussée
Conférence #nwxtech2 : Sécurité web/PHP par Maxime MauchausséeConférence #nwxtech2 : Sécurité web/PHP par Maxime Mauchaussée
Conférence #nwxtech2 : Sécurité web/PHP par Maxime MauchausséeNormandie Web Xperts
 
Vulnérabilité des sites web
Vulnérabilité des sites webVulnérabilité des sites web
Vulnérabilité des sites webSaid Sadik
 
2010 02 09 Ms Tech Days Owasp Asvs Sgi V01
2010 02 09 Ms Tech Days Owasp Asvs Sgi V012010 02 09 Ms Tech Days Owasp Asvs Sgi V01
2010 02 09 Ms Tech Days Owasp Asvs Sgi V01Sébastien GIORIA
 
Sécurisation d'un site internet
Sécurisation d'un site internetSécurisation d'un site internet
Sécurisation d'un site internetwaggaland
 
Tuto atelier securisation_site_web
Tuto atelier securisation_site_webTuto atelier securisation_site_web
Tuto atelier securisation_site_websahar dridi
 
2011 02-08-ms tech-days-sdl-sgi-v02
2011 02-08-ms tech-days-sdl-sgi-v022011 02-08-ms tech-days-sdl-sgi-v02
2011 02-08-ms tech-days-sdl-sgi-v02Sébastien GIORIA
 
Azure IaaS : concevoir en architecture sécurisée en tirant bénéfice des nouve...
Azure IaaS : concevoir en architecture sécurisée en tirant bénéfice des nouve...Azure IaaS : concevoir en architecture sécurisée en tirant bénéfice des nouve...
Azure IaaS : concevoir en architecture sécurisée en tirant bénéfice des nouve...Microsoft Décideurs IT
 
Azure IaaS : concevoir en architecture sécurisée en tirant bénéfice des nouve...
Azure IaaS : concevoir en architecture sécurisée en tirant bénéfice des nouve...Azure IaaS : concevoir en architecture sécurisée en tirant bénéfice des nouve...
Azure IaaS : concevoir en architecture sécurisée en tirant bénéfice des nouve...Microsoft Technet France
 

Similar to Owasp top 10 2010 Resist toulouse (20)

Securite web is_ima
Securite web is_imaSecurite web is_ima
Securite web is_ima
 
La Sécurité Sur Le Web
La Sécurité Sur Le WebLa Sécurité Sur Le Web
La Sécurité Sur Le Web
 
Securitedesapplications 091011120426-phpapp02
Securitedesapplications 091011120426-phpapp02Securitedesapplications 091011120426-phpapp02
Securitedesapplications 091011120426-phpapp02
 
Epitech securite-2012.key
Epitech securite-2012.keyEpitech securite-2012.key
Epitech securite-2012.key
 
20090929 04 - Securité applicative, hacking et risque applicatif
20090929 04 - Securité applicative, hacking et risque applicatif20090929 04 - Securité applicative, hacking et risque applicatif
20090929 04 - Securité applicative, hacking et risque applicatif
 
Webinaire : sécurité informatique sur le web - Jérôme Thémée
Webinaire : sécurité informatique sur le web - Jérôme ThéméeWebinaire : sécurité informatique sur le web - Jérôme Thémée
Webinaire : sécurité informatique sur le web - Jérôme Thémée
 
Securité des applications web
Securité des applications webSecurité des applications web
Securité des applications web
 
Introduction à la sécurité des applications web avec php [fr]
Introduction à la sécurité des applications web avec php [fr]Introduction à la sécurité des applications web avec php [fr]
Introduction à la sécurité des applications web avec php [fr]
 
Conférence #nwxtech2 : Sécurité web/PHP par Maxime Mauchaussée
Conférence #nwxtech2 : Sécurité web/PHP par Maxime MauchausséeConférence #nwxtech2 : Sécurité web/PHP par Maxime Mauchaussée
Conférence #nwxtech2 : Sécurité web/PHP par Maxime Mauchaussée
 
Vulnérabilité des sites web
Vulnérabilité des sites webVulnérabilité des sites web
Vulnérabilité des sites web
 
OpenSSO Aquarium Paris
OpenSSO Aquarium ParisOpenSSO Aquarium Paris
OpenSSO Aquarium Paris
 
2010 02 09 Ms Tech Days Owasp Asvs Sgi V01
2010 02 09 Ms Tech Days Owasp Asvs Sgi V012010 02 09 Ms Tech Days Owasp Asvs Sgi V01
2010 02 09 Ms Tech Days Owasp Asvs Sgi V01
 
Sécurisation d'un site internet
Sécurisation d'un site internetSécurisation d'un site internet
Sécurisation d'un site internet
 
Sécurité des Applications Web avec Json Web Token (JWT)
Sécurité des Applications Web avec Json Web Token (JWT)Sécurité des Applications Web avec Json Web Token (JWT)
Sécurité des Applications Web avec Json Web Token (JWT)
 
Tuto atelier securisation_site_web
Tuto atelier securisation_site_webTuto atelier securisation_site_web
Tuto atelier securisation_site_web
 
PFE PPT2
PFE PPT2PFE PPT2
PFE PPT2
 
2011 02-08-ms tech-days-sdl-sgi-v02
2011 02-08-ms tech-days-sdl-sgi-v022011 02-08-ms tech-days-sdl-sgi-v02
2011 02-08-ms tech-days-sdl-sgi-v02
 
Azure IaaS : concevoir en architecture sécurisée en tirant bénéfice des nouve...
Azure IaaS : concevoir en architecture sécurisée en tirant bénéfice des nouve...Azure IaaS : concevoir en architecture sécurisée en tirant bénéfice des nouve...
Azure IaaS : concevoir en architecture sécurisée en tirant bénéfice des nouve...
 
Azure IaaS : concevoir en architecture sécurisée en tirant bénéfice des nouve...
Azure IaaS : concevoir en architecture sécurisée en tirant bénéfice des nouve...Azure IaaS : concevoir en architecture sécurisée en tirant bénéfice des nouve...
Azure IaaS : concevoir en architecture sécurisée en tirant bénéfice des nouve...
 
On a volé les clefs de mon SI !
On a volé les clefs de mon SI !On a volé les clefs de mon SI !
On a volé les clefs de mon SI !
 

More from Sébastien GIORIA

OWASP Top10 IoT - CLUSIR Infornord Décembre 2014
OWASP Top10 IoT - CLUSIR Infornord Décembre 2014OWASP Top10 IoT - CLUSIR Infornord Décembre 2014
OWASP Top10 IoT - CLUSIR Infornord Décembre 2014Sébastien GIORIA
 
Analyser la sécurité de son code source avec SonarSource
Analyser la sécurité de son code source avec SonarSourceAnalyser la sécurité de son code source avec SonarSource
Analyser la sécurité de son code source avec SonarSourceSébastien GIORIA
 
2014 09-25-club-27001 iso 27034-presentation-v2.2
2014 09-25-club-27001 iso 27034-presentation-v2.22014 09-25-club-27001 iso 27034-presentation-v2.2
2014 09-25-club-27001 iso 27034-presentation-v2.2Sébastien GIORIA
 
2013 06-27-securecoding-en - jug pch
2013 06-27-securecoding-en - jug pch2013 06-27-securecoding-en - jug pch
2013 06-27-securecoding-en - jug pchSébastien GIORIA
 
OWASP Top10 2013 - Présentation aux RSSIA 2013
OWASP Top10 2013 - Présentation aux RSSIA 2013OWASP Top10 2013 - Présentation aux RSSIA 2013
OWASP Top10 2013 - Présentation aux RSSIA 2013Sébastien GIORIA
 
OWASP, the life and the universe
OWASP, the life and the universeOWASP, the life and the universe
OWASP, the life and the universeSébastien GIORIA
 
2013 04-04-html5-security-v2
2013 04-04-html5-security-v22013 04-04-html5-security-v2
2013 04-04-html5-security-v2Sébastien GIORIA
 
2013 02-12-owasp top10 mobile - attaques et solutions sur windows phone (sec309)
2013 02-12-owasp top10 mobile - attaques et solutions sur windows phone (sec309)2013 02-12-owasp top10 mobile - attaques et solutions sur windows phone (sec309)
2013 02-12-owasp top10 mobile - attaques et solutions sur windows phone (sec309)Sébastien GIORIA
 
2013 03-01 automatiser les tests sécurité
2013 03-01 automatiser les tests sécurité2013 03-01 automatiser les tests sécurité
2013 03-01 automatiser les tests sécuritéSébastien GIORIA
 
2013 02-27-owasp top10 javascript
 2013 02-27-owasp top10 javascript 2013 02-27-owasp top10 javascript
2013 02-27-owasp top10 javascriptSébastien GIORIA
 
2012 11-07-owasp mobile top10 v01
2012 11-07-owasp mobile top10 v012012 11-07-owasp mobile top10 v01
2012 11-07-owasp mobile top10 v01Sébastien GIORIA
 
OWASP Mobile Top10 - Les 10 risques sur les mobiles
OWASP Mobile Top10 -  Les 10 risques sur les mobilesOWASP Mobile Top10 -  Les 10 risques sur les mobiles
OWASP Mobile Top10 - Les 10 risques sur les mobilesSébastien GIORIA
 
2011 02-07-html5-security-v1
2011 02-07-html5-security-v12011 02-07-html5-security-v1
2011 02-07-html5-security-v1Sébastien GIORIA
 

More from Sébastien GIORIA (20)

OWASP Top10 IoT - CLUSIR Infornord Décembre 2014
OWASP Top10 IoT - CLUSIR Infornord Décembre 2014OWASP Top10 IoT - CLUSIR Infornord Décembre 2014
OWASP Top10 IoT - CLUSIR Infornord Décembre 2014
 
Analyser la sécurité de son code source avec SonarSource
Analyser la sécurité de son code source avec SonarSourceAnalyser la sécurité de son code source avec SonarSource
Analyser la sécurité de son code source avec SonarSource
 
2014 09-25-club-27001 iso 27034-presentation-v2.2
2014 09-25-club-27001 iso 27034-presentation-v2.22014 09-25-club-27001 iso 27034-presentation-v2.2
2014 09-25-club-27001 iso 27034-presentation-v2.2
 
SonarQube et la Sécurité
SonarQube et la SécuritéSonarQube et la Sécurité
SonarQube et la Sécurité
 
2014 09-04-pj
2014 09-04-pj2014 09-04-pj
2014 09-04-pj
 
Présentation au CRI-Ouest
Présentation au CRI-OuestPrésentation au CRI-Ouest
Présentation au CRI-Ouest
 
2013 06-27-securecoding-en - jug pch
2013 06-27-securecoding-en - jug pch2013 06-27-securecoding-en - jug pch
2013 06-27-securecoding-en - jug pch
 
OWASP Top10 2013 - Présentation aux RSSIA 2013
OWASP Top10 2013 - Présentation aux RSSIA 2013OWASP Top10 2013 - Présentation aux RSSIA 2013
OWASP Top10 2013 - Présentation aux RSSIA 2013
 
OWASP, the life and the universe
OWASP, the life and the universeOWASP, the life and the universe
OWASP, the life and the universe
 
2013 04-04-html5-security-v2
2013 04-04-html5-security-v22013 04-04-html5-security-v2
2013 04-04-html5-security-v2
 
2013 02-12-owasp top10 mobile - attaques et solutions sur windows phone (sec309)
2013 02-12-owasp top10 mobile - attaques et solutions sur windows phone (sec309)2013 02-12-owasp top10 mobile - attaques et solutions sur windows phone (sec309)
2013 02-12-owasp top10 mobile - attaques et solutions sur windows phone (sec309)
 
2013 03-01 automatiser les tests sécurité
2013 03-01 automatiser les tests sécurité2013 03-01 automatiser les tests sécurité
2013 03-01 automatiser les tests sécurité
 
2013 02-27-owasp top10 javascript
 2013 02-27-owasp top10 javascript 2013 02-27-owasp top10 javascript
2013 02-27-owasp top10 javascript
 
Secure Coding for Java
Secure Coding for JavaSecure Coding for Java
Secure Coding for Java
 
2012 11-07-owasp mobile top10 v01
2012 11-07-owasp mobile top10 v012012 11-07-owasp mobile top10 v01
2012 11-07-owasp mobile top10 v01
 
2012 07-05-spn-sgi-v1-lite
2012 07-05-spn-sgi-v1-lite2012 07-05-spn-sgi-v1-lite
2012 07-05-spn-sgi-v1-lite
 
2012 03-02-sdl-sgi-v03
2012 03-02-sdl-sgi-v032012 03-02-sdl-sgi-v03
2012 03-02-sdl-sgi-v03
 
2012 03-01-ror security v01
2012 03-01-ror security v012012 03-01-ror security v01
2012 03-01-ror security v01
 
OWASP Mobile Top10 - Les 10 risques sur les mobiles
OWASP Mobile Top10 -  Les 10 risques sur les mobilesOWASP Mobile Top10 -  Les 10 risques sur les mobiles
OWASP Mobile Top10 - Les 10 risques sur les mobiles
 
2011 02-07-html5-security-v1
2011 02-07-html5-security-v12011 02-07-html5-security-v1
2011 02-07-html5-security-v1
 

Owasp top 10 2010 Resist toulouse

  • 1. OWASP Top 10 - 2010 rc1 Les 10 risques les plus critiques des applications Web. Sébastien Gioria (French Chapter Leader & OWASP Global Education Comittee Member) sebastien.gioria@owasp.org (english slides from Dave Wichers (COO, Aspect Security & OWASP Boardmember) dave.wichers@owasp.org ) Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation http://www.owasp.org/
  • 2. Qui suis-je ? Consultant Sécurité au sein du cabinet de commissaires aux compte Groupe Y (s.gioria@groupey.fr)  Président du CLUSIR Poitou-Charentes  OWASP France Leader & Evangéliste (sebastien.gioria@owasp.org)  Membre du Comité OWASP d’Education  +12 ansd’expérience en Sécurité des Systèmesd’Information Différentspostes de manager SSI dans la banque, l’assurance et les télécoms  Expertise Technique  PenTesting, Digital Forensics  S-SDLC  Gestion du risque, Architectures fonctionnelles, Audits  Consulting et Formation en Réseaux et Sécurité   Domaines de prédilection :  Web 4.2 : WebServices, Insécurité du Web. 
  • 3. Quelssont les changements ? On parle de risques, et non plus uniquement de vulnérabilités. • Le titre devient donc : “ Les 10 risques les plus critiques des applications Web”. La méthodologie de calcul du risque de l’OWASP Top 10 • Basée sur la méthodologie OWASP Risk Rating Methodology 2 risques ajoutés, 2 retirés • Ajout: A6 – Mauvaise configuration • Ex-A10 du Top10 2004 : Configuration non sécurisée • Ajout: A8 – Redirections • Très courant et très dangereux, et mal considéré • Retiré: A3 – Execution de fichier malveillant • Principalement une faille PHP… • Retiré: A6 –Mauvaise gestion des erreurs et fuite d’informations • Une faille très courante, ne générant que rarement un risque
  • 4. Mapping Top10 2007 - Top 10 20 OWASP Top 10 – 2007 (Previous) OWASP Top 10 – 2010 (New) A2 – Injection Flaws A1 – Injection A1 – Cross Site Scripting (XSS) A2 – Cross Site Scripting (XSS) A7 – Broken Authentication and Session Management A3 – Broken Authentication and Session Management A4 – Insecure Direct Object Reference = A4 – Insecure Direct Object References A5 – Cross Site Request Forgery (CSRF) = A5 – Cross Site Request Forgery (CSRF) <was T10 2004 A10 – Insecure Configuration Management> + A6 – Security Misconfiguration (NEW) A10 – Failure to Restrict URL Access <not in T10 2007> A7 – Failure to Restrict URL Access + A8 – Unvalidated Redirects and Forwards (NEW) A8 – Insecure Cryptographic Storage A9 – Insecure Cryptographic Storage A9 – Insecure Communications A10 – Insufficient Transport Layer Protection A3 – Malicious File Execution A6 – Information Leakage and Improper Error Handling - <dropped from T10 2010> <dropped from T10 2010>
  • 5. Méthoded’évaluation du risque de l’OWASP Top 10 Exemplebasésur XSS Threat Agent ? Attack Vector 1 2 3 Weakness Prevalence Weakness Detectability Technical Impact Easy Widespread Easy Severe Average Common Average Moderate Difficult Uncommon Difficult Minor 2 1 1 2 1.3 * Business Impact 2 ? 2.6Evaluation pondérée du risque
  • 6. L’OWASP Top10 (2010 rc1) http://www.owasp.org/index.php/Top_10
  • 7. A1 – Injection L’injection • Envoyer à une application des données générant un comportement non attendu. Les Interpréteurs • Utilisent les chaines et les interpretent comme des commandes • SQL, OS Shell, LDAP, XPath, Hibernate, etc… L’injection SQL est toujours commune • Enormément d’applications y sont sensibles • Même s’il est très simple de s’en affranchir…. Impact • Souvent très sévère. Le plupart du temps l’ensemble des données de la base sont lisibles ou modifiables. • Cela peut même aller jusqu’au schéma de la base, les comptes ou un accès OS….
  • 8. ATTACK   App Server Billing Directories  Acct:5424-9383-2039-4029 Acct:4128-0004-1234-0293 3.L’application transfère les données à la requête SQL Web Server Firewall Hardened OS Firewall DB Table  "SELECT * FROM Account Summary Account: accounts WHERE SKU: acct=‘’ OR 1=1-Acct:5424-6066-2134-4334 Acct:4128-7574-3921-0192 ’" 1. L’application fourni un formulaire 2. L’attaquant envoi son attaque dans les données du formulaire Custom Code Network Layer Human Resrcs  Web Services HTTP SQL response query  HTTP request APPLICATION Legacy Systems Databases Communication Knowledge Mgmt E-Commerce Bus. Functions Administration Transactions Accounts Finance Application Layer Exemple sur l’injection SQL 4. Le SGBD lance la requête contenant l’attaqueet renvoie le résultats à l’application. 5. L’application renvoie ce résultat à l’utilisateur
  • 9. A1 – Comment se protéger  Recommandations 1. Se passer des interpréteurs, 2. Utiliser une interface permettant de préparer les requêtes (ex, prepared statements, or les procédures stockées), 3. Encoder toutes les données fournies par l’utilisateur avant de les passer à l’interpréteur  Toujours effectuer une validation de type “white liste” sur les données utilisateurs.  Minimiser les privilèges dans les bases pour limiter l’impact de la faille.  References  Plus de détails sur http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
  • 10. A2 – Cross-Site Scripting (XSS) Se retrouve à chaque audit/pentest • Des données venant d’un attaquant sont envoyé à l’innocent navigateur d’un utilisateur Ces données peuvent être • Stockées en base, • Réfléchies depuis une entrée d’une page Web (champ de formulaire, champ caché, URL, …) • Envoyé directement à un client Riche (Javascript, Flash, …) Virtuellement toute application Web est vulnérable • Essayez cela dans votre navigateur – javascript:alert(document.cookie) Impact • Vole des sessions utilisateur, de données sensibles, réécriter de la page Web, reidrection vers un site d’hameconnage ou autre code malveillant • De manière plus grave : installation d’un proxy XSS permettant à un attaquant d’observer le poste client voir de forcer l’utilisateur vers un site particulier
  • 11. Cross-Site Scripting Illustré 1 L’attaquant découvre le script vulnérable La victime se rend sur la page Custom Code Le Script s’execute sur le navigateur de la victime sans qu’il ne le sache 3 L’attaquant recoit le cookie ou autre élément directement Communication Knowledge Mgmt E-Commerce Bus. Functions 2 Accounts Finance L’attaquant entre un script malicieux sur la page web(stocké) ou bien utilise un lien(réfléchi) permettant d’envoyer vers la page Administration Transactions Application disposant de faille XSS
  • 12. A2 – Contremesures  Recommandations  Supprimer la faille   Ne pas inclure de contenu fourni par l’utilisateur dans la page de sortie !!!  Défenses possibles 1. Encoder toutes les entrées et sorties utilisateurs (utilisez l’OWASP ESAPI pour l’encodage de sortie) http://www.owasp.org/index.php/ESAPI 2. Effectuer de la validation de type « white liste » pour les données utilisateurs entrantes qui sont inclues dans une page. 3. Pour des grosses portions de code HTML fournie par un utilisateur, utiliser le filtre OWASP Anti-Sammy de manière à nettoyer l’HTML Voir: http://www.owasp.org/index.php/AntiSamy  Référence  Pour effectuer un encodage propre, ce référer à http://www.owasp.org/index.php/XSS_(Cross Site Scripting) Prevention Cheat Sheet (AntiSamy
  • 13. A3 – Mauvaise gestion des sessions et de l’authentification HTTP est un protocole sans état • Les identifiants doivent donc être passés a chaque requete. • Il faut utiliser SSL pour toute authentification Failles dans la gestion de l’authentification • Des ID de sesisons sont utilisés pour maintenir la session dans HTTP car il ne le peut lui. • Cela suffit à un attaquant, c’est aussi interessant qu’un identifiant • Les ID de sessions sont souvent exposés dans les sessions réseau, dans les browsers (cookies), dans les logs, …. Attention aux portes dérobées… • Changement de mot de passe, se souvenir de mon passe, oubli de mot de passe, questions secretes, logout, email, … Impact • Vol de session ou compromission de comptes utilisateur
  • 14. www.boi.com?JSESSIONID=9FA1DB9EA... Le site récrit l’URL (i.e., mise dans l’URL de l’ID de session) 3 5 L’attaquant peut utiliser le JSESSIONID sur le site boi.com pour son méfait Custom Code 2 L’utilisateur clique sur un lien vers http://www.hacker.com dans un forum L’attaquant regarde les logs “Referer” sur www.hacker.com Et découvre le JSESSIONID Communication Knowledge Mgmt E-Commerce Bus. Functions Utilisateur envoie ses identifiants Accounts Finance 1 Administration Transactions Illustration d’une mauvaise authentification 4
  • 15. A3 – ContreMesure  Vérifier l’architecture !  L’authentification doit être simple, centralisée et standardisée  Utiliser le mécanisme standard de gestion des cookies du framework (ils sont globalement fiable)  Utiliser constamment SSL pour protéger les identifiants de connexion et de sessions  Vérifier l’implémentation  Oublier l’analyse automatique  Vérifier le certificat SSL (SSLv2, renégociation, chiffrement faible, …)  Examiner toutes les fonctions relatives a l’authentification  Vérifier que la déconnexion supprime bien la session !  Utiliser l’OWASP WebScarab pour tester l’implémentation (sessionIDanalysis)
  • 16. A4 – Référencedirecte non sécuriséeà un objet Comment accéder aux données privées • C’est une manière de renforcerles habilitations en lien avec A7 – Mauvaise restriction d’accès à une URL Des erreurs classiques • • • • Attendre uniquement de l’utilisateur des accès à des objets autorisés ou Cacher des références à des objets dans des champs cachés … et ne pas renforcer les restrictions coté serveur. Ceci n’est qu’une tentative de contrôle d’accès sur la présentation et ne fonctionne pas ! • Un attaquant n’a qu’a modifier les valeurs des paramètres… Impact • Un utilisateur a accès à des données ou des fichiers normalemtn interdits
  • 17. Référence directe non sécurisée à un objet illustrée https://www.onlinebank.com/user?acct=6065  L’attaquant note le paramètre acct = 6065 ?acct=6065  Il modifie celui-ci de la manière suivante ?acct=6066  L’attaquant visualise un autre compte.
  • 18. A4 – Contre Mesure  Eliminer la référence directe.  La remplacer par une valeur temporaire aléatoire (e.g. 1, 2, 3)  L’ESAPI fournit des fonctions pour cela  IntegerAccessReferenceMap &RandomAccessReferenceMap http://app?file=Report123.xls http://app?file=1 http://app?id=9182374 http://app?id=7d3J93 Access Reference Map Report123.xls Acct:9182374  Valider la référence directe à l’objet  Vérifier que le contenu est correctement formaté.  Vérifier que l’utilisateur a le droit d’effctuer l’accès à l’objet.  Vérifier que le mode d’accès à l’objet est autorisé (e.g., read, write, delete)
  • 19. A5 – Cross Site Request Forgery (CSRF) Cross Site Request Forgery • C’est une attaque ou le navigateur de la victime génère une requête vers une application Web vulnérable • Cette vulnérabilité est causée par la capacité qu’on les navigateurs a envoyer automatiquement des données d’authentification (session ID, IP address, comptes de domaine windows, ..) dans chaque requête. Imaginez • Que se passerait-il si un hacker pouvait utiliser votre souris pour effectuer des clicks sur votre site de banque en ligne a votre place. • Que pourrait-il faire ? Impact • Initiation de transactions (transfert de fonds, logoff, modification de données, …) • Accès à des données sensibles • Changement des mots de passes/identifiants
  • 20. CSRF démystifié  Le problème  Les navigateurs Web incluent automatiquement la plupart des identifiants dans chaque requête.  Que cela soit des requêtes venant d’un formulaire, d’une image ou d’un autre site.  Tous les sites basés uniquement sur les identifiants automatiques sont vulnérables  Approximativement 100% des sites le sont…  C’est quoi un identifiant automatique?  Cookie de session  Header d’authentification HTTP  Une adresse IP  Les certificats SSL client  L’authentification de domaine Windows.
  • 21. CSRF illustré L’attaquant pose son piège sur un site internet (ou via un e-mail) 1 Communication Knowledge Mgmt E-Commerce Bus. Functions Tout en étant logguer sur le site vulnérable, la victime parcourt le site de l’attaquant. Administration Transactions 2 Accounts Finance Un tag chaché <img> contient une attaque vers un site vulnérable Application vulnérable au CSRF Custom Code 3 Le tag <img> tag chargé par le navigateur envoie une requête GET (contenant des identifiants sur le site vulnérable) Le site vulnérable ne voie que des requêtes légitimes et effectue l’action demandée
  • 22. A5 – ContreMesure  Ajouter un jeton, non envoyé automatiquement, a toutes les requêtes sensibles.  Cela rend impossible pour l’attaquant de soumettre une requête valide.  (sauf si en plus il y a une faille XSS)  Ces jetons doivent être surs cryptographiquement.  Options  Stocker un seul jeton dans la session et l’ajouter a tous les formulaire et liens  Champ caché: <input name="token" value="687965fdfaew87agrde" type="hidden"/>  Utiliser un URL : /accounts/687965fdfaew87agrde  Utiliser un jeton de formulaire: /accounts?auth=687965fdfaew87agrde…  Attention a ne pas exposer le jeton dans l’entete “referer”  Utiliser de préférence un champ caché.  Utiliser un jeton unique par fonction.  Il est recommandé d’ajouter un second niveau d’authentification pour une transaction sensible  Ne pas laisser un attaquant stocker des attaques sur le site  Encoder proprement les données d’entrées  Cela permet de limiter la majorité des interpréteurs de liens Voir www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet pour plus de détails
  • 23. A6 – Mauvaise configuration Les applications Web doivent faire confiance à une fondation sécurisée • On pense aux réseau, aux système et aux plateformes • Il ne faut pas oublier les environnements de développement Est-ce que votre code source est secret? • Pensez a tous les endroits ou l’on trouve votre code source. • La Sécurité ne doit pas se baser sur l’obscurité du code source. Il faut étendre la gestion de la configuration a toutes les parties de l’application • Tous les identifiants doivent être changés sur les environnements de production Impact • Installation d’une porte dérobée via un oubli de patch (serveur, réseau,…) • Failles XSS exploitées due à l’oublie de patch dans les framework • Accès non authorisé à des comptes , des données, ou des fonctionnalités applicatives par défaut non utilisées mais accessibles a cause d’une mauvaise configuration utilisateur
  • 24. Communication Knowledge Mgmt E-Commerce Bus. Functions Administration Transactions Accounts Finance Mauvaise configuration illustrée Database Custom Code App Configuration Framework Development App Server QA Servers Web Server Insider Hardened OS Test Servers Source Control
  • 25. A6 – Contre Mesure  Vérifier la gestion de la configuration sécurité de vos systèmes.  Ayez des guidelines de renforcement de la sécurité.  L’automatisation est réellement utile dans ce cas  Couvrir toute la plateforme et l’application  Garder a l’esprit d’avoir des patchs pour TOUS les composants  Cela inclue les librairies, et pas seulement l’OS, les serveurs et applications.  Analyser l’impact sécurité des changements  Pouvez vous effectuer des “masters” de votre configuration applicative ?  Mettre en place un reporting des builds dans le processus sécurité  Si vous ne pouvez vérifier le configuration applicative, l’applicatif n’est pas sécurisé  Vérifier l’implémentation  Les scans découvrent généralement les configurations par défaut et les problèmes du à des patchs de retard
  • 26. A7 – Mauvaise restriction d’URL Comment protéger vous l’accès à une URL ? • Cela concerne aussi le renforcement des l’habilitations tout comme le paragraphe A4 Une erreur commune… • N’afficher que les liens et menus authorisés dans les listes de choix. • Une fois de plus, c’est du controle d’accès visuel, et cela ne fonctionne pas. • Il suffit de modifier les requêtes en allant diretement sur les pages “non autorisées” Impact • Invocation de fonctions et de services non authorisées • Accès a des données ou des comptes n’appartenant pas à l’utilisateur • Elevation de privilèges et d’actions
  • 27. Mauvaise restriction d’URLillustrée https://www.onlinebank.com/user/getAccounts  L’attaquant note dansl’URLque le rôleestaffiché /user/getAccounts  Il modifiedirectementl’URL (le rôle) /admin/getAccounts, ou /manager/getAccounts  L’attaquant dispose de privilègessupplémentaires
  • 28. A7 – Contre Mesure  Pour tout URL il faut 3 éléments :  Restreindre l’accès aux seuls utilisateurs authentifiés (sauf si l’URL est publique).  Renforcer les permissions basées sur les rôles ou l’utilisateue (si l’URL est privée)  Bloquer toute requête à des pages non autorisées ( (e.g., fichiers de config, de log, code source, etc.)  Vérifier l’architecture  Utiliser un modèle positif simple a tous les niveaux  S’assurer d’avoir un modèle d’accès à tous les niveaux.  Vérifier l’implémentation  Oublier l’approche automatisée  Vérifier que chaque URL de l’application est protégée par :  Un filtre externe, comme en J2EE (web.xml)  Ou par un morceau de VOTRE code – Voir la méthode ESAPI’ isAuthorizedForURL()  Vérifier que la configuration du serveur n’autorise pas les requêtes vers les types de fichiers ou extensions non autorisés.  Utiliser un proxy type WebScarab pour forger des requêtes non autorisées.
  • 29. A8 – Redirections et transferts non contrôlés Les redirections sont communes dans une application WEB. • Et fréquemment elles incluent des paramètres fournis par l’utilisateur dans l’URL de destination. • Si ces paramètres ne sont pas validés, un attaquant peut envoyer la victime vers le site de son choix. Les transferts(aka Transfer en .NET) sont eux aussi communs • Ils renvoient la requête vers une nouvelle page en interne de l’application. • Parfois les paramètres déterminent la page cible. • Si cela n’est pas validé, cela permet de parfois passer outre les mécanismes d’autorisation et d’authentification. Impact • Rediriger la victime vers un site malveillant de type hameconnage. • Il devient possible de passer outre les contrôles de sécurité et accéder à des fonctions ou données non autorisées.
  • 30. Redirection illustrée L’attaquant envoi à la victime via un email ou une page Web de son choix le lien. Bus. Functions E-Commerce Knowledge Mgmt Communication Transactions La vicitime clique sur le lien contenant une donnée non validée. L’application redirige la victime vers le site de l’attaquant Administration 2 3 Finance From: Internal Revenue Service Subject: YourUnclaimedTaxRefund Our records show you have an unclaimedfederaltaxrefund. Please click here to initiateyour claim. Accounts 1 Custom Code Request sent to vulnerable site, including attacker’s destination site as parameter. Redirect sends victim to attacker site http://www.irs.gov/taxrefund/claim.jsp?year=2006 &… &dest=www.evilsite.com Evil Site 4 Le site malveillant installe des éléments sur le navigateur ou récupére des données
  • 31. Unvalidated Forward Illustrated 1 L’attaquant envoie sa charge sur une page vulnérable ou il a accès Request sent to vulnerable page which user does have access to. Redirect sends user directly to private page, bypassing access control. 2 L’application autorise la requête et continue vers la page vulnérable public void sensitiveMethod( HttpServletRequest request, HttpServletResponse response) { try { // Do sensitive stuff here. ... } catch ( ... Filtre public void doPost( HttpServletRequest request, HttpServletResponse response) { try { String target = request.getParameter( "dest" ) ); ... request.getRequestDispatcher( target ).forward(request, response); } catch ( ... 3 La page de transfert ne contrôle pas le paramètre et renvoie l’attaquant vers la page non autorisée, passant outre le contrôle d’accès.
  • 32. A8 – Contre Mesure  Il y a des tonnes de solutions 1. Eviter au maximum les redirections et les transferts 2. Si il faut absolument les utiliser, ne pas utiliser les paramètres parvenant d’un utilisateur pour définir l’URL/fonction cible. 3. Si vous “devez” utiliser les paramètres utilisateurs, a) Validez chaque paramètre pour vérifier qu’il est autorisé et valide par rapport à l’utilisateur, ou alors b) Utilisez une table de correspondance serveur entre les paramètres utilisateurs et les pages à appeler.  Pour les redirection, valider l’URL cible après la construction pour vérifier qu’elle redirige bien vers un site autorisé !  L’ESAPI peut vous aider :  Voir : SecurityWrapperResponse.sendRedirect( URL )  http://owasp-esapi-java.googlecode.com/svn/trunk_doc/org/owasp/esapi/filters/ SecurityWrapperResponse.html#sendRedirect(java.lang.String)  Quelques réflexions sur les Transferts  Idéallement, il faudrait appeler le contrôle d’accès pour être sur que l’utilisateur est bien autorisé aà effecgtuer le transfert(très simple avec l’ESAPI…)  Si vous utilisez des filtres externes (comme SiteMinder), cela ne sera pas simple  La meilleure solution est de s’assurer que les utilisateurs qui ont accès à la page initiale ont TOUS le droit d’accéder à la page cible….
  • 33. A9 – Stockage Cryptographique non sécurisé Le stockage de données non sécurisées • Oubli d’identification des données sensibles • Oubli d’identification de tous les entrepôts de stockage des données sensibles. • Bases de données, fichiers, répertoires, fichiers de logs, backup, … • Oubli de mettre en place une protection correcte des données dans tous les entrepots de stockages des données sensibles. Impact • Modification ou accès a des données confidentielles ou privées (carte de crédits, données santés, données financières, …) • Extrait de données secretes via d’autres failles (injection SQL, LDAP, …) • Problème d’image de marque, d’image client et perte de confiance • Long et couteux processus de vérification, investigation et retour a la normale (forensics, lettres et dédommagements client, assurance, …)
  • 34. 1 La victime stocke son numéro de carte de crédit dans le système via un formulaire Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions Stockage non sécurisé illustré Custom Code 4 Fichier de log Une personne malveillante interne vole 4 millions de carte de crédit Les logs sont rendus disponibles pour tous les membres internes dans le but du debug 3 Le gestionnaire des erreurs loggue le numéro de carte car la passerelle de commerce est indisponible. 2
  • 35. A9 – ContreMesure  Vérifier l’architecture  Identifier toutes les données sensibles  Identifier tous les entrepots de stockage des données  S’assurer des attaques possibles sur comptes  Utiliser un mécanisme de chiffrement approprié  Chiffrement de fichier, de base, d’élément de la base.  Utiliser correctement le mécanisme…  Utiliser des algorithmes connus standard et surs.  Générer, distribuer et protéger les clefs  S’assurer de la capacité de changement régulier des clefs  Vérifier l’implémentation  Un algorithme sur est utilisé et c’est le bon algorithme pour la situation !  Toutes les clefs, certificats, et mots de passe sont stockés et protégés correctement.  Il existe une distribution propre des clefs et il est possible d’en changer facilement
  • 36. A10 – Protection insuffisante lors du transport des données La transmission de données non sécurisée… • Oubli de l’identification de TOUTES les données sensibles • Oubli de l’identification de TOUTES les URLs/Pages ou les données sensibles transitent. • Sur le Web, vers les SGBD, vers les partenaires métiers, vers les réseaux internes… • Oubli de protéger les données à chacun de ces endroits… Impact • Modification ou accès a des données confidentielles ou privées (carte de crédits, données santés, données financières, …) • Extrait de données secretes via d’autres failles (injection SQL, LDAP, …) • Problème d’image de marque, d’image client et perte de confiance • Long et couteux processus de vérification, investigation et retour a la normale (forensics, lettres et dédommagements client, assurance)
  • 37. Protection insuffisante lors du transport des données illustré Partenaire métier Victimeexterne Custom Code Backend Systems Employées 1 Vols de données via le réseauexterne Attaquantexterne 2 Vol de données via le réseau interne Attaquant interne
  • 38. A10 – ContreMesure  Utiliser les mécanismes de protection appropriés  Utiliser TLS pour tout transport de données sensible.  Chiffrer les messages avant transmission.  E.g., XML-Encryption  Signer les messages avant transmission  E.g., XML-Signature  Utiliser les mécanismescorrectement !  Utiliser des algorithmessurs ! (désactiver les vieilles versions de SSL et les chiffrementsfaibles…)  Gérercorrectement les clefs/certificats.  Vérifier les certificats SSL avantl’utilisation.  Voirhttp://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet pour plus de details
  • 39. En résumé : comment adresser ces risques  Développer du code sécurisé !  Suivre les bonnes pratiques du Guide OWASP sur la construction sécurisée d’une application Web.  http://www.owasp.org/index.php/Guide  Utiliser l’OWASP Application Security Verification Standard comme un guide permettant de définir les mécanismes de sécurité  http://www.owasp.org/index.php/ASVS  Utiliser les composants de sécurité standard et s’adaptant le mieux a votre entreprise  Par exemple utiliser l’OWASP ESAPI comme une fondation a VOS composants standards  http://www.owasp.org/index.php/ESAPI  Auditer les applications  Faire appel a une équipe expérimentée pour analyser et auditer l’application.  Auditer les applications vous-meme graçe aux guide de l’OWASP  OWASP Code Review Guide: http://www.owasp.org/index.php/Code_Review_Guide  OWASP Testing Guide: http://www.owasp.org/index.php/Testing_Guide
  • 40. Your Existing Enterprise Services or Libraries ESAPI Homepage: http://www.owasp.org/index.php/ESAPI SecurityConfiguration IntrusionDetector Logger Exception Handling Randomizer EncryptedProperties Encryptor HTTPUtilities Encoder Validator AccessReferenceMap AccessController User Authenticator OWASP (ESAPI) Custom Enterprise Web Application OWASP Enterprise Security API
  • 41. Remerciements  Les contribueurs principaux  Aspect Security pour le sponsoring du projet  Jeff Williams (auteur du premier Top10 en2003 )  Dave Wichers (auteur et responsible actuel du projet )  Les organisations ayant contribué aux statistiques sur les vulnérabilitées  Aspect Security  MITRE  Softtek  White Hat  Les contributeurs et relecteurs :  Mike Boberski, Juan Carlos Calderon, Michael Coates, Jeremiah Grossman, Paul Petefish, Eric Sheridan, Andrew van der Stock

Editor's Notes

  1. Then you can present your developers with a clean intuitive interface to all the security controls they need to build a secure application.That’s what ESAPI is all about. Simplifying Application Security