La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP."— Transcription de la présentation:

1 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 OWASP Top rc1 Les 10 risques les plus critiques des applications Web. Sébastien Gioria (French Chapter Leader & OWASP Global Education Comitee Member) (english slides from Dave Wichers (COO, Aspect Security & OWASP Boardmember) )

2 Quels sont les changements ? Le titre devient donc : Les 10 risques les plus critiques des applications Web. On parle de risques, et non plus uniquement de vulnérabilités. Basée sur la méthodologie OWASP Risk Rating Methodology La méthodologie de calcul du risque de lOWASP Top 10 Ajout: A6 – Mauvaise configuration Ex-A10 du Top : 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 dinformations Une faille très courante, ne générant que rarement un risque 2 éléments ajoutés, 2 retirés

3 Mapping Top Top = =

4 Méthode dévaluation du risque de lOWASP Top 10 Threat Agent Attack Vector Weakness Prevalence Weakness Detectability Technical Impact Business Impact ? EasyWidespreadEasySevere ? AverageCommonAverageModerate DifficultUncommonDifficultMinor *2 2.6 Evaluation pondérée du risque Exemple basé sur XSS

5 LOWASP Top10 (2010 rc1)

6 A1 – Injection Envoyer à une application des données générant un comportement non attendu. Linjection Utilisent les chaines et les interpretent comme des commandes SQL, OS Shell, LDAP, XPath, Hibernate, etc… Les Interpréteurs Enormément dapplications y sont sensibles Même sil est très simple de sen affranchir…. Linjection SQL est toujours commune Souvent très sévère. Le plupart du temps lensemble des données de la base sont lisibles ou modifiables. Cela peut même aller jusquau schéma de la base, les comptes ou un accès OS…. Impact

7 Exemple sur linjection SQL Firewall Hardened OS Web Server App Server Firewall Databases Legacy Systems Web Services Directories Human Resrcs Billing Custom Code APPLICATION ATTACK Network Layer Application Layer Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions HTTP request SQL query DB Table HTTP response "SELECT * FROM accounts WHERE acct= OR 1=1-- " 1. Lapplication fourni un formulaire 2. Lattaquant envoi son attaque dans les données du formulaire 3.Lapplication transfère les données à la requête SQL Account Summary Acct: Acct: Acct: Acct: Le SGBD lance la requête contenant lattaqueet renvoie le résultats à lapplication. 5. Lapplication renvoie ce résultat à lutilisateur Account: SKU: Account: SKU:

8 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 lutilisateur avant de les passer à linterpréteur Toujours effectuer une validation de type white liste sur les données utilisateurs. Minimiser les privilèges dans les bases pour limiter limpact de la faille. References Plus de détails sur

9 A2 – Cross-Site Scripting (XSS) Des données venant dun attaquant sont envoyé à linnocent navigateur dun utilisateur Se retrouve à chaque audit/pentest Stockées en base, Réfléchies depuis une entrée dune page Web (champ de formulaire, champ caché, URL, …) Envoyé 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 Vole des sessions utilisateur, de données sensibles, réécriter de la page Web, reidrection vers un site dhameconnage ou autre code malveillant De manière plus grave : installation dun proxy XSS permettant à un attaquant dobserver le poste client voir de forcer lutilisateur vers un site particulier Impact

10 Cross-Site Scripting Illustré Application disposant de faille XSS 3 2 Lattaquant découvre le script vulnérable Lattaquant entre un script malicieux sur la page web(stocké) ou bien utilise un lien(réfléchi) permettant denvoyer vers la page 1 La victime se rend sur la page Lattaquant recoit le cookie ou autre élément directement Le Script sexecute sur le navigateur de la victime sans quil ne le sache Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions

11 (AntiSamy) A2 – Contre mesures Recommandations Supprimer la faille Ne pas inclure de contenu fourni par lutilisateur dans la page de sortie !!! Défenses possibles 1.Encoder toutes les entrées et sorties utilisateurs (utilisez lOWASP ESAPI pour lencodage de sortie) 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 lHTML Voir: Référence Pour effectuer un encodage propre, ce référer à Site Scripting) Prevention Cheat Sheet Site Scripting) Prevention Cheat Sheet

12 A3 – Mauvaise gestion des sessions et de lauthentification Les identifiants doivent donc être passés a chaque requete. Il faut utiliser SSL pour toute authentification HTTP est un protocole sans état Des ID de sesisons sont utilisés pour maintenir la session dans HTTP car il ne le peut lui. Cela suffit à un attaquant, cest aussi interessant quun 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 lauthentification Changement de mot de passe, se souvenir de mon passe, oubli de mot de passe, questions secretes, logout, , … Attention aux portes dérobées… Vol de session ou compromission de comptes utilisateur Impact

13 Illustration dune mauvaise authentification Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions 1 Utilisateur envoie ses identifiants 2 Le site récrit lURL (i.e., mise dans lURL de lID de session) 3 Lutilisateur clique sur un lien vers dans un forum 4 Lattaquant regarde les logs Referer sur Et découvre le JSESSIONID 5 Lattaquant peut utiliser le JSESSIONID sur le site boi.com pour son méfait

14 A3 – Contre Mesure Vérifier larchitecture ! Lauthentification 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 limplémentation Oublier lanalyse automatique Vérifier le certificat SSL (SSLv2, renégociation, chiffrement faible, …) Examiner toutes les fonctions relatives a lauthentification Vérifier que la déconnexion supprime bien la session ! Utiliser lOWASP WebScarab pour tester limplémentation (sessionID analysis)

15 A4 – Référence directe non sécurisée à un objet Cest une manière de renforcerles habilitations en lien avec A7 – Mauvaise restriction daccès à une URL Comment accéder aux données privées Attendre uniquement de lutilisateur 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 nest quune tentative de contrôle daccès sur la présentation et ne fonctionne pas ! Un attaquant na qua modifier les valeurs des paramètres… Des erreurs classiques Un utilisateur a accès à des données ou des fichiers normalemtn interdits Impact

16 Référence directe non sécurisée à un objet illustrée Lattaquant note le paramètre acct = 6065 ?acct=6065 Il modifie celui-ci de la manière suivante ?acct=6066 Lattaquant visualise un autre compte. https://www.onlinebank.com/user?acct=6065

17 A4 – Contre Mesure Eliminer la référence directe. La remplacer par une valeur temporaire aléatoire (e.g. 1, 2, 3) LESAPI fournit des fonctions pour cela IntegerAccessReferenceMap & RandomAccessReferenceMap Valider la référence directe à lobjet Vérifier que le contenu est correctement formaté. Vérifier que lutilisateur a le droit deffctuer laccès à lobjet. Vérifier que le mode daccès à lobjet est autorisé (e.g., read, write, delete) Report123.xls Acct: Access Reference Map

18 A5 – Cross Site Request Forgery (CSRF) Cest 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é quon les navigateurs a envoyer automatiquement des données dauthentification (session ID, IP address, comptes de domaine windows,..) dans chaque requête. Cross Site Request Forgery 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 ? 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

19 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 dun formulaire, dune image ou dun autre site. Tous les sites basés uniquement sur les identifiants automatiques sont vulnérables Approximativement 100% des sites le sont… Cest quoi un identifiant automatique? Cookie de session Header dauthentification HTTP Une adresse IP Les certificats SSL client Lauthentification de domaine Windows.

20 CSRF illustré 3 2 Lattaquant pose son piège sur un site internet (ou via un ) 1 Tout en étant logguer sur le site vulnérable, la victime parcourt le site de lattaquant. Le site vulnérable ne voie que des requêtes légitimes et effectue laction demandée Le tag tag chargé par le navigateur envoie une requête GET (contenant des identifiants sur le site vulnérable) Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions Un tag chaché contient une attaque vers un site vulnérable Application vulnérable au CSRF

21 A5 – Contre Mesure Ajouter un jeton, non envoyé automatiquement, a toutes les requêtes sensibles. Cela rend impossible pour lattaquant 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 lajouter a tous les formulaire et liens Champ caché: Utiliser un URL : /accounts/687965fdfaew87agrde Utiliser un jeton de formulaire: /accounts?auth=687965fdfaew87agrde … Attention a ne pas exposer le jeton dans lentete referer Utiliser de préférence un champ caché. Utiliser un jeton unique par fonction. Il est recommandé dajouter un second niveau dauthentification pour une transaction sensible Ne pas laisser un attaquant stocker des attaques sur le site Encoder proprement les données dentrées Cela permet de limiter la majorité des interpréteurs de liens Voir pour plus de détailswww.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet

22 A6 – Mauvaise configuration On pense aux réseau, aux système 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 lon trouve votre code source. La Sécurité ne doit pas se baser sur lobscurité 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 lapplication Installation dune porte dérobée via un oubli de patch (serveur, réseau,…) Failles XSS exploitées due à loublie 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 dune mauvaise configuration utilisateur Impact

23 Hardened OS Web Server App Server Framework Mauvaise configuration illustrée App Configuration Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions Test Servers QA Servers Source Control Development Database Insider

24 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é. Lautomatisation est réellement utile dans ce cas Couvrir toute la plateforme et lapplication Garder a lesprit davoir des patchs pour TOUS les composants Cela inclue les librairies, et pas seulement lOS, les serveurs et applications. Analyser limpact 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, lapplicatif nest pas sécurisé Vérifier limplémentation Les scans découvrent généralement les configurations par défaut et les problèmes du à des patchs de retard

25 A7 – Mauvaise restriction dURL Cela concerne aussi le renforcement des lhabilitations tout comme le paragraphe A4 Comment protéger vous laccès à une URL ? Nafficher que les liens et menus authorisés dans les listes de choix. Une fois de plus, cest du controle daccè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 authorisées Accès a des données ou des comptes nappartenant pas à lutilisateur Elevation de privilèges et dactions Impact

26 Mauvaise restriction dURL illustrée Lattaquant note dans lURL que le rôle est affiché /user/getAccounts Il modifie directement lURL (le rôle) /admin/getAccounts, ou /manager/getAccounts Lattaquant dispose de privilèges supplémentaires

27 A7 – Contre Mesure Pour tout URL il faut 3 éléments : Restreindre laccès aux seuls utilisateurs authentifiés (sauf si lURL est publique). Renforcer les permissions basées sur les rôles ou lutilisateue (si lURL est privée) Bloquer toute requête à des pages non autorisées ( (e.g., fichiers de config, de log, code source, etc.) Vérifier larchitecture Utiliser un modèle positif simple a tous les niveaux Sassurer davoir un modèle daccès à tous les niveaux. Vérifier limplémentation Oublier lapproche automatisée Vérifier que chaque URL de lapplication 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 nautorise 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.

28 A8 – Redirections et transferts non contrôlés Et fréquemment elles incluent des paramètres fournis par lutilisateur dans lURL 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 lapplication. Parfois les paramètres déterminent la page cible. Si cela nest pas validé, cela permet de parfois passer outre les mécanismes dautorisation et dauthentification. 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

29 Redirection illustrée 3 2 Lattaquant envoi à la victime via un ou une page Web de son choix le lien. From: Internal Revenue Service Subject: Your Unclaimed Tax Refund Our records show you have an unclaimed federal tax refund. Please click here to initiate your claim. 1 Lapplication redirige la victime vers le site de lattaquant Request sent to vulnerable site, including attackers destination site as parameter. Redirect sends victim to attacker site Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions 4 Le site malveillant installe des éléments sur le navigateur ou récupére des données La vicitime clique sur le lien contenant une donnée non validée. Evil Site &http://www.irs.gov/taxrefund/claim.jsp?year=2006 & … &dest=www.evilsite.com… &dest=www.evilsite.com

30 Unvalidated Forward Illustrated 2 Lattaquant envoie sa charge sur une page vulnérable ou il a accès 1 Lapplication autorise la requête et continue vers la page vulnérable Request sent to vulnerable page which user does have access to. Redirect sends user directly to private page, bypassing access control. 3 La page de transfert ne contrôle pas le paramètre et renvoie lattaquant vers la page non autorisée, passant outre le contrôle daccès. public void doPost( HttpServletRequest request, HttpServletResponse response) { try { String target = request.getParameter( "dest" ) );... request.getRequestDispatcher( target ).forward(request, response); } catch (... Filtre public void sensitiveMethod( HttpServletRequest request, HttpServletResponse response) { try { // Do sensitive stuff here.... } catch (...

31 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 dun utilisateur pour définir lURL/fonction cible. 3.Si vous devez utiliser les paramètres utilisateurs, a)Validez chaque paramètre pour vérifier quil est autorisé et valide par rapport à lutilisateur, ou alors b)Utilisez une table de correspondance serveur entre les paramètres utilisateurs et les pages à appeler. Pour les redirection, valider lURL cible après la construction pour vérifier quelle redirige bien vers un site autorisé ! LESAPI peut vous aider : Voir : SecurityWrapperResponse.sendRedirect( URL ) SecurityWrapperResponse.html#sendRedirect(java.lang.String) SecurityWrapperResponse.html#sendRedirect(java.lang.String) Quelques réflexions sur les Transferts Idéallement, il faudrait appeler le contrôle daccès pour être sur que lutilisateur est bien autorisé aà effecgtuer le transfert(très simple avec lESAPI…) Si vous utilisez des filtres externes (comme SiteMinder), cela ne sera pas simple La meilleure solution est de sassurer que les utilisateurs qui ont accès à la page initiale ont TOUS le droit daccéder à la page cible….

32 A9 – Stockage Cryptographique non sécurisé Oubli didentification des données sensibles Oubli didentification 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 dautres failles (injection SQL, LDAP, …) Problème dimage de marque, dimage 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

33 Stockage non sécurisé illustré Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions 1 La victime stocke son numéro de carte de crédit dans le système via un formulaire 2 Le gestionnaire des erreurs loggue le numéro de carte car la passerelle de commerce est indisponible. 4 Une personne malveillante interne vole 4 millions de carte de crédit Fichier de log 3 Les logs sont rendus disponibles pour tous les membres internes dans le but du debug

34 A9 – Contre Mesure Vérifier larchitecture Identifier toutes les données sensibles Identifier tous les entrepots de stockage des données Sassurer 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 Sassurer de la capacité de changement régulier des clefs Vérifier limplémentation Un algorithme sur est utilisé et cest 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 den changer facilement

35 A10 – Protection insuffisante lors du transport des données Oubli de lidentification de TOUTES les données sensibles Oubli de lidentification 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ée… 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 dautres failles (injection SQL, LDAP, …) Problème dimage de marque, dimage 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

36 Protection insuffisante lors du transport des données illustré Custom Code Employées Partenaire métier Victime externe Backend Systems Attaquant externe 1 Vols de données via le réseau externe 2 Vol de données via le réseau interne Attaquant interne

37 A10 – Contre Mesure 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é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 lutilisation. Voir pour plus de details

38 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 dune application Web. Utiliser lOWASP Application Security Verification Standard comme un guide permettant de définir les mécanismes de sécurité Utiliser les composants de sécurité standard et sadaptant le mieux a votre entreprise Par exemple utiliser lOWASP ESAPI comme une fondation a VOS composants standards Auditer les applications Faire appel a une équipe expérimentée pour analyser et auditer lapplication. Auditer les applications vous-meme graçe aux guide de lOWASP OWASP Code Review Guide: OWASP Testing Guide:

39 OWASP (ESAPI) Custom Enterprise Web Application OWASP Enterprise Security API Authenticator User AccessController AccessReferenceMap Validator Encoder HTTPUtilities Encryptor EncryptedProperties Randomizer Exception Handling Logger IntrusionDetector SecurityConfiguration Your Existing Enterprise Services or Libraries ESAPI Homepage:

40 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


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

Présentations similaires


Annonces Google