Upload
sebastien-gioria
View
1.618
Download
0
Embed Size (px)
Citation preview
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/
Les 10 plus importants risques dans vos applications
Sébastien Gioria
OWASP Global Education committee OWASP French Chapter Leader
Votre application va être piratée Laisssez moi vous mettre
dans la bonne direction
2
Votre application
va être piratée
Votre application
a été piratée
OUI
NON
NON
OUI
Ne soyez pas le prochain !
Fire
wal
l
Hardened OS
Web Server
App Server
Fire
wal
l
Dat
abas
es
Lega
cy S
yste
ms
Web
Ser
vice
s D
irect
orie
s H
uman
Res
rcs
Bill
ing
Custom Code
APPLICATION ATTACK
Net
wor
k La
yer
App
licat
ion
Laye
r
Acc
ount
s Fi
nanc
e A
dmin
istra
tion
Tran
sact
ions
C
omm
unic
atio
n K
now
ledg
e M
gmt
E-C
omm
erce
B
us. F
unct
ions
HTTP request
SQL query
DB Table
HTTP response
"SELECT * FROM accounts WHERE
acct=‘’ OR 1=1--’"
1. L’application fourni un formulaire 2. L’attaquant envoi son attaque dans les données du formulaire 3.L’application transfère les données à la requête SQL
Account Summary
Acct:5424-6066-2134-4334 Acct:4128-7574-3921-0192 Acct:5424-9383-2039-4029 Acct:4128-0004-1234-0293
4. Le SGBD lance la requête contenant l’attaque et renvoie les résultats à l’application.
5. L’application renvoie ce résultat à l’utilisateur
Account:
SKU:
Account:
SKU:
A1 – Injection
• Envoyer à une application des données générant un comportement non attendu.
L’injection
• Utilisent les chaines et les interpretent comme des commandes • SQL, OS Shell, LDAP, XPath, Hibernate, etc…
Les Interpréteurs
• Enormément d’applications y sont sensibles • Même s’il est très simple de s’en affranchir….
L’injection SQL est toujours commune
• 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….
Impact
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)
• Des données venant d’un attaquant sont envoyées à l’innocent navigateur d’un utilisateur
Se retrouve à chaque audit/pentest
• Stockées en base, • Réfléchies depuis une entrée d’une page Web (champ de formulaire, champ caché, URL, …)
• Envoyées directement à un client Riche (Javascript, Flash, …)
Ces données peuvent être
• Essayez cela dans votre navigateur – javascript:alert(document.cookie)
Virtuellement toute application Web est vulnérable
• Vol des sessions utilisateur, de données sensibles, réécriture de la page Web, redirection 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 voire de forcer l’utilisateur vers un site particulier
Impact
(AntiSamy)
A2 – Contre mesures
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 fourni 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, se référer à http://www.owasp.org/index.php/XSS_(Cross Site Scripting) Prevention Cheat Sheet
Que se passe-t-il ?
10
Hacker
Customer
GET /login.jsp?SESSIONID=123456789
OK SESSIONID=12345679 Authenticated
A3 – Mauvaise gestion des sessions et de l’authentification
• Les identifiants doivent donc être passés à chaque requête. • Il faut utiliser SSL pour toute authentification
HTTP est un protocole sans état
• Des ID de sessions 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, ….
Failles dans la gestion de l’authentification
• Changement de mot de passe, se souvenir de mon passe, oubli de mot de passe, questions secretes, logout, email, …
Attention aux portes dérobées…
• Vol de session ou compromission de comptes utilisateur
Impact
A3 – Contre Mesure
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 fiables) 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
(sessionID analysis)
A4 – Référence directe non sécurisée à un objet
• C’est une manière de renforcer les habilitations en lien avec A7 – Mauvaise restriction d’accès à une URL
Comment accéder aux données privées
• 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…
Des erreurs classiques
• Un utilisateur a accès à des données ou des fichiers normalement interdits
Impact
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
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)
http://app?file=1 Report123.xls
http://app?id=7d3J93 Acct:9182374 http://app?id=9182374
http://app?file=Report123.xls Access
Reference Map
A5 – Cross Site Request Forgery (CSRF)
• 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é que les navigateurs ont d’ envoyer automatiquement des données d’authentification (session ID, IP adresse, comptes de domaine windows, ..) dans chaque requête.
Cross Site Request Forgery
• Que se passerait-il si un attaquant pouvait utiliser votre souris pour effectuer des clicks sur votre site de banque en ligne a votre place.
• Que pourrait-il faire ?
Imaginez
• Initiation de transactions (transfert de fonds, logoff, modification de données, …)
• Accès à des données sensibles • Changement des mots de passes/identifiants
Impact
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 Une entête d’authentification HTTP Une adresse IP Les certificats SSL client L’authentification de domaine Windows.
A5 – Contre Mesure
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
• On pense aux réseaux, aux systèmes et aux plateformes • Il ne faut pas oublier les environnements de développement
Les applications Web doivent faire confiance à une fondation sécurisée
• 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.
Est-ce que votre code source est secret?
• Tous les identifiants doivent être changés sur les environnements de production
Il faut étendre la gestion de la configuration a toutes les parties de l’application
• Installation d’une porte dérobée via un oubli de patch (serveur, réseau,…) • Failles XSS exploitées du à l’oubli de patch dans les frameworks • Accès non autorisé à 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
Impact
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 inclut 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 dus à des patchs de retard
A7 – Mauvaise restriction d’URL
• Cela concerne aussi le renforcement des habilitations tout comme le paragraphe A4
Comment protégez vous l’accès à une URL ?
• N’afficher que les liens et menus autorisé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”
Une erreur commune…
• Invocation de fonctions et de services non autorisées • Accès a des données ou des comptes n’appartenant pas à l’utilisateur • Élévation de privilèges et d’actions
Impact
A7 – Contre Mesure
Pour toute 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
• 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 redirections sont communes dans une application WEB.
• 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.
Les transferts(aka Transfer en .NET) sont eux aussi communs
• 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.
Impact
A8 – Contre Mesure Il y a des tonnes de solutions
1. Eviter au maximum les redirections et les transferts 2. S’il faut absolument les intégrer, 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é
• 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.
Le stockage de données non sécurisées
• 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, …)
Impact
A9 – Contre Mesure
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
• 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…
La transmission de données non sécurisées…
• 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)
Impact
A10 – Contre Mesure
Utiliser les mécanismes de protection appropriés Utiliser TLS pour tout transport de données sensibles. Chiffrer les messages avant transmission.
E.g., XML-Encryption Signer les messages avant transmission
E.g., XML-Signature
Utiliser les mécanismes correctement ! Utiliser des algorithmes surs ! (désactiver les vieilles versions de
SSL et les chiffrements faibles…) Gérer correctement les clefs/certificats. Vérifier les certificats SSL avant l’utilisation. Voir http://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
Remerciements - Copyright
Les contributeurs principaux Jeff Williams (auteur du premier Top10 en2003 ) Dave Wichers (auteur et responsible actuel du projet )
Antonio Fontes (OWASP Geneva Chapter) pour certains points
Vous êtes libres de : Partager (copier, distribuer , transmettre) Mixer les slides
Mais uniquement si : Vous le faites a des finalités non-commerciales Et vous continuez à partager vos résultats de la même façon
38