Téléchargé 262 fois
![Cross-Site Request Forgery
Utilisation normale (2/2)
Client légitime Server Web
www.exemple.co
m
<a href="index.php?action=acheter&id=1">Acheter</a>
Liste des objets:
ION Drum [Acheter]
AudioTek [Acheter]
Trump Sonesta [Acheter]
Page suivante | Page Precedente](https://image.slidesharecdn.com/presentationyasserowasp-110606204917-phpapp01/85/Les-5-risques-les-plus-critiques-des-applications-Web-selon-l-OWASP-43-320.jpg)
![Protection contre le Cross-Site Request Forgery
Utilisation normale (2/2)
Client légitime Server Web
www.exemple.com
<a href="index.php
Liste des objets:
?action=acheter&id=1&secureToken=431fwap8rawddf...">Acheter</a>
ION Drum [Acheter]
AudioTek [Acheter]
Trump Sonesta [Acheter]
Page suivante | Page Precedente](https://image.slidesharecdn.com/presentationyasserowasp-110606204917-phpapp01/85/Les-5-risques-les-plus-critiques-des-applications-Web-selon-l-OWASP-47-320.jpg)
Contenu connexe
Les 5 risques les plus critiques des applications Web selon l'OWASP
- 1. The OWASP Foundation http://www.owasp.org Les 5 risques les plus critiques des applications Web Journée de la Sécurité Informatique – FST Tanger 2ème édition, 28 mai 2011 Yasser ABOUKIR OWASP WebGoat Project Contributor yaboukir@gmail.com
- 2. The OWASP Foundation http://www.owasp.org Plan 1) OWASP, késako? 2) Les 5 risques les plus critiques des applications Web 3) WebGoat Project 4) Nouveaux vecteurs d’attaque | 2
- 3. The OWASP Foundation http://www.owasp.org 1) OWASP, késako? 2) Les 5 risques les plus critiques des applications Web 3) WebGoat Project 4) Nouveaux vecteurs d’attaque | 3
- 4. OWASP World OWASP isa worldwide free and Everyone is free to participate in open community focused on OWASP and all of our materials improving the security of are available under a free and application software. open software license. Our mission is to make The OWASP Foundation is a application security visible so 501c3 not-for-profit charitable that people and organizations organization that ensures the can make informed decisions ongoing availability and support about application security risks. for our work.
- 5. OWASP • OWASP :Open Web Application Security Project • Indépendant des fournisseurs et des gouvernements. • Objectif principal : produire des outils, documents et standards dédiés à la sécurité des applications Web. • Toutes les documentations, standards, outils sont fournis sous le modèle de l‟open-source. • Organisation : • Réunion d‟experts indépendants en sécurité informatique • Communauté mondiale (plus de 100 chapitres) réunie en une fondation américaine pour supporter son action. L‟adhésion est gratuite et ouverte à tous. • Le point d‟entrée est le wiki http://www.owasp.org
- 6. Organisation de l‟OWASP OWASP OWASP Conferences OWASP Governance OWASP Wiki OWASP Tools OWASP Chapter OWASP Foundation (501c3) Leaders OWASP Lists Board of Directors Board of Operations Technical OWASP Books (Williams, Wichers, Advisors Director (McNamee) Director (Casey) OWASP Project Brennan, Cruz, and Leaders Deleersnyder) OWASP Community
- 7. Finances and Grants OWASP Grants 100% 55% OWASP Foundation 45% 7
- 8. L‟OWASP 420 000 pages vues par mois 15 000 téléchargements par mois 11 335 membres sur les listes 3 687 utilisateurs du Wiki 1 500 MAJ du Wiki par mois 110 chapitres mondiaux 100 membres individuels 48 outils/projets/documents 38 membres entreprise 25 projets fondés et soutenus dans la communauté 1 employé
- 9. OWASP KnowledgeBase • 3,913 total articles • 427 presentations • 200 updates per day • 179 mailing lists • 180 blogs monitored • 31 doc projects • 19 deface attempts • 12 grants
- 10. OWASP Tools andTechnology • Vulnerability • Penetration • ESAPI Scanners Testing Tools • Static Analysis • Code Review Tools Tools • Fuzzing Automated Manual Security Security Security Architecture Verification Verification • AppSec Libraries • Reporting Tools • Flawed Apps • ESAPI Reference • Learning Implementation Environments • Guards and • Live CD Filters • SiteGenerator Secure AppSec AppSec Coding Management Education 10
- 11. Les publications Toutes lespublications sont disponibles sur le site de l‟OWASP: http://www.owasp.org L‟ensemble des documents est régi par la licence GFDL (GNU Free Documentation License) Les documents sont issus de différentes collaborations : • Projets universitaires • Recherche & développements des membres
- 12. Les publications majeures •Le TOP 10 des vulnérabilités applicatives • Le guide de conception d‟applications Web sécurisées • Le FAQ de la sécurité des applications • Le guide « les 10 commandements sur l‟écriture d‟une application non sécurisée »
- 13. Les Guides 100% Libres! Issusde l‟expérience de milliers d’experts à travers le monde OWASP guide: • Un ouvrage pour la création d‟applications Web sécurisées à l‟intention des : Développeurs Architectes … • Inclus les meilleurs pratiques dans différents langages (PHP, Java, .Net, …) • Plusieurs centaines de pages OWASP Testing guide: • Ouvrage dédié à l‟audit sécurité des applications Web à l‟intention des pen-testeurs principalement.
- 14. OWASP Enterprise SecurityAPI (ESAPI) • Un framework de sécurité pour les développeurs • Permettre de créer une application Web Sécurisée Classes Java Disponible sur le site de l‟OWASP En cours de portage pour le SoC 2008 sur .NET et PHP
- 15. WebGoat - WebScarab WebGoat : • Application Java serveur (JSP, JEEE) non sécurisé. • Sert à démontrer les failles, leur principe et à éduquer. WebScarab : • Application Java permettant d‟effectuer des tests de sécurité: • Sur les applications Web • Sur les WebServices
- 16. Quelques outils Outilde génération de données aléatoires (Fuzzer) permettant d‟injecter des données pour les tests • JBroFuzz : Fuzzer destiné à tester les applications Web • WS Fuzz : Fuzzer destiné à tester les WebServices. Sprajax Outil destiné a tester la sécurité des applications AJAX Et bien d‟autres : http://www.owasp.org/index.php/Category:OWASP_Project
- 17. Le Top 10 Liste les 10 vulnérabilités des applications Web les plus rencontrées Mis à jour tous les ans D‟importantes organisations l‟ont adoptées dans leurs référentiels Federal Trade Commission (US Gov) US Defense Information Systems Agency VISA (Cardholder Information Security Program) – PCI/DSS Le NIST Des opérateurs Télécoms
- 18. Quels sont leschangements ? 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 éléments 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
- 19. Mapping Top10 2007- Top 10 2010 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 + A6 – Security Misconfiguration (NEW) Management> A10 – Failure to Restrict URL Access A7 – Failure to Restrict URL Access <not in T10 2007> + 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 - <dropped from T10 2010> A6 – Information Leakage and Improper Error Handling - <dropped from T10 2010>
- 20. Méthode d‟évaluation durisque de l‟OWASP Top 10 Exemple basé sur XSS Threat Attack Weakness Weakness Business Technical Impact Agent Vector Prevalence Detectability Impact 1 Easy Widespread Easy Severe ? 2 Average Common Average Moderate ? Difficult Uncommon Difficult Minor 3 2 1 1 2 1.3 * 2 2.6 Evaluation pondérée du risque
- 21. L‟OWASP Top10 (2010rc1) http://www.owasp.org/index.php/Top_10
- 22. 1) OWASP, késako? 2)Les 5 risques les plus critiques des applications Web 3) WebGoat Project 4) Nouveaux vecteurs d’attaque |22
- 23. Environnement typique del‟entreprise 23
- 24. 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 interprètent 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….
- 25. Exemple sur l‟injectionSQL Account Summary Account: "SELECT * FROM Knowledge Mgmt Communication Legacy Systems Bus. Functions Administration Human Resrcs E-Commerce Application Layer Transactions Web Services SKU: Directories Databases HTTP Accounts Acct:5424-6066-2134-4334 accounts WHERE Finance DB Table Billing HTTP response SQL Acct:4128-7574-3921-0192 request query acct=‘’ OR 1=1 --’" Acct:5424-9383-2039-4029 APPLICATION ATTACK Acct:4128-0004-1234-0293 Custom Code 1. L’application fourni un formulaire 2. L’attaquant envoi son attaque dans les données du formulaire App Server 3.L’application transfère les Web Server données à la requête SQL Hardened OS Network Layer 4. Le SGBD lance la requête contenant l’attaque et renvoie les résultats à l’application. Firewall Firewall 5. L’application renvoie ce résultat à l’utilisateur
- 26. A1 – Commentse 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
- 27. A2 – Cross-SiteScripting (XSS) Se retrouve à chaque audit/pentest • Des données venant d‟un attaquant sont envoyées à 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ées directement à un client Riche (Javascript, Flash, …) Virtuellement toute application Web est vulnérable • Essayez cela dans votre navigateur – javascript:alert(document.cookie) Impact • Vol des sessions utilisateur, de données sensibles, réécriture de la page Web, redirection vers un site d‟hameçonnage 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
- 28. Cross-Site Scripting Illustré L’attaquant découvre le script vulnérable 1 Application disposant de faille L’attaquant entre un script XSS malicieux sur la page web(stocké) ou bien utilise un lien(réfléchi) Knowledge Mgmt Communication permettant d’envoyer vers Bus. Functions Administration E-Commerce Transactions Accounts Finance la page La victime se rend sur la page 2 Custom Code Le Script s’execute sur le navigateur de la victime sans qu’il ne le sache 3 L’attaquant reçoit le cookie ou autre élément directement
- 29. Vérification des donnéesusager (Input validation) Cross site scripting (XSS) non persistent Client légitime Search results for Gagner de l’argent Gagner de l’argent: Comment gagner de l'argent facile et des Search cadeaux sur internet… L' objectif du blog est de présenter toutes les idées qui permettent d' économiser … Server Web <html> <head></head> <body> <h1>Search results for Gagner de l’argent :</h1> <itemize> <item>Comment gagner deacile et des cadeaux sur internet…</item> <item>L' objectif du blog est de présenter toutes les idées qui permettent d' économiser …</item> extract($_POST); </itemize> </body> $req = "select * from POSTS </html> where title = '$stitle'
- 30. Vérification des donnéesusage (Input validation) Cross site scripting (XSS) non persistent Search results for <u>Super</u> Super: Client malicieux Search No results found Server Web <html> <head></head> <body> <h1>Search results for <u>Super</u> :</h1> No results found </itemize> </body> extract($_POST); </html> $req = "select * from POSTS where title = '$stitle'
- 31. Vérification des donnéesusager (Input validation) Cross site scripting (XSS) persistent Server BD Client malicieux Post id message 1 Hello 2 Bien fait ... 3 <script type="text/javascript ">document.location. href=“http://evil.com "</script> <script type="text/javascript">document.location.href=“http://evil.com"</script> Your message has been posted
- 32. Vérification des donnéesusager (Input validation) Cross site scripting (XSS) Server BD Client légitime id message Guestbook messages: 1 Hello Hello Bien fait ... 2 Bien fait ... 3 <script <h1>Guestbook messages:</h1> type="text/javascript">d Hello<br> Bien fait<br> ocument.location.href=“ <script http://evil.com"</script> type="text/javascript">document.location.hr ef=“http://evil.com"</script><br> ... 32
- 33. 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 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
- 34. A3 – Mauvaisegestion des sessions et de l‟authentification HTTP est un protocole sans état • Les identifiants doivent donc être passés à chaque requête. • Il faut utiliser SSL pour toute authentification Failles dans la gestion de l‟authentification • 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 intéressant 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 secrètes, logout, email, … Impact • Vol de session ou compromission de comptes utilisateur
- 35. Illustration d‟une mauvaiseauthentification 1 Utilisateur envoie ses Communication Bus. Functions Administration Transactions E-Commerce Knowledge identifiants Accounts Finance Mgmt www.test.com?JSESSIONID=9FA1DB9EA... Le site récrit l’URL Custom Code (i.e., mise dans l’URL de 2 l’ID de session) 3 L’utilisateur clique sur un lien vers http://www.cracker.com dans un forum L’attaquant regarde les logs “Referer” sur www.cracker.com 4 Et découvre le JSESSIONID 5 L’attaquant peut utiliser le JSESSIONID sur le site boi.com pour son méfait
- 36. 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 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 à l‟authentification • Vérifier que la déconnexion supprime bien la session ! • Utiliser l‟OWASP WebScarab pour tester l‟implémentation (sessionID analysis)
- 37. A4 – Référencedirecte non sécurisée à un objet Comment accéder aux données privées • C‟est une manière de renforcer les 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‟à modifier les valeurs des paramètres… Impact • Un utilisateur a accès à des données ou des fichiers normalement interdits
- 38. Référence directe nonsécurisée à un objet illustrée https://www.banque.com L‟attaquant note le /user?acct=6065 paramètre acct = 6065 ?acct=6065 de la manière suivante ?acct=6066 L‟attaquant visualise un autre compte.
- 39. A4 – ContreMesure 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 & RandomAccessReferenceMa http://app?file=Report123.xls Report123.xls Access http://app?file=1 Reference http://app?id=9182374 Map Acct:9182374 http://app?id=7d3J93 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)
- 40. A5 – CrossSite 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é que les navigateurs ont d‟ envoyer automatiquement des données d‟authentification (session ID, IP adresse, comptes de domaine Windows, ..) dans chaque requête. Imaginez • Que se passerait-il si un attaquant pouvait utiliser votre souris pour effectuer des clicks sur votre site de banque en ligne à 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
- 41. 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.
- 42. Cross-Site Request Forgery Utilisation normale (1/2) Client légitime GET index.php Server Web www.exemple.co m POST login.php
- 43. Cross-Site Request Forgery Utilisation normale (2/2) Client légitime Server Web www.exemple.co m <a href="index.php?action=acheter&id=1">Acheter</a> Liste des objets: ION Drum [Acheter] AudioTek [Acheter] Trump Sonesta [Acheter] Page suivante | Page Precedente
- 44. Cross-Site Request Forgery Attaque Client légitime Server Web <html> <head></head> <body> <img src="http://www.exemple.com/index.php? www.attaque.com action=acheter&id=1"> </body> </html> Server Web www.exemple.com
- 45. 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 à 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‟entête “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
- 46. Protection contre leCross-Site Request Forgery Utilisation normale (1/2) Client légitime GET index.php Server Web www.exemple.com POST login.php
- 47. Protection contre leCross-Site Request Forgery Utilisation normale (2/2) Client légitime Server Web www.exemple.com <a href="index.php Liste des objets: ?action=acheter&id=1&secureToken=431fwap8rawddf...">Acheter</a> ION Drum [Acheter] AudioTek [Acheter] Trump Sonesta [Acheter] Page suivante | Page Precedente
- 48. Protection contre leCross-Site Request Forgery Attaque Client légitime Server Web <html> <head></head> <body> <img src="http://www.exemple.com/index.php? www.attaque.com action=acheter&id=1"> </body> </html> Vérification de la variable secureToken échouée. Session fermée. Server Web www.exemple.com
- 49. 1) OWASP, késako? 2)Les 5 risques les plus critiques des applications Web 3) WebGoat Project 4) Nouveaux vecteurs d’attaque |49
- 50. WebGoat • Plateforme deformation permettant à un utilisateur d'apprendre à exploiter les vulnérabilités les plus courantes sur une application Web. • Téléchargé plus de ~120,000 fois • Application Web Java EE délibérément vulnérable. 50
- 51. Organismes utilisant WebGoat Utilisé par source code analysis and web application security scanning vendors pour les demos Utilisé par les universités dans le curruculum de sécurité: • Carnegie-Mellon: WebGoat comme open source project option • University of Denver • ENSIAS – Morocco : Travaux Pratiques, Module « Sécurité applicative et des données » – Option Sécurité des Systèmes d‟Information OWASP Autumn 2006 and Spring of Code 2007 Projects Utilisé par plusieurs entreprises comme outil de formation 51
- 52. Origine du motWebGoat “ Why the name "WebGoat"? Developers should not feel bad about not knowing security. Even the best programmers make security errors. What they need is a scapegoat, right? Just blame it on the “ Goat “ ! “ WebGoat , un bouc émissaire pour les développeurs WEB 52
- 53. Histoire du WebGoat • Don à OWASP par Aspect Security ~2002 • Project Lead : Bruce Mayhew • Premières contributions externes dès 2005 • V.5 produite comme AoC 2006 project 53
- 54. Objectifs • Comprendre l'interactionde haut niveau des processus au sein d'une application WEB. • Déterminer quelles informations au sein des données visibles du client, pourraient être utiles dans une attaque. • Identifier et comprendre les données et les interactions de l'utilisateur qui pourraient exposer l‟application à une attaque. • Effectuer les tests contre ces interactions afin d‟exposer les failles dans leur fonctionnement. • Exécuter des attaques contre l'application pour démontrer et exploiter ses vulnérabilités 54
- 55. Let‟s have ademo! 55
- 56. 1) OWASP, késako? 2)Les 5 risques les plus critiques des applications Web 3) WebGoat Project 4) Nouveaux vecteurs d’attaque |56
- 57. HTTP Parameter Pollution (HPP) • Présentées pour la première fois en 2009 par l'OWASP. • Constat: les navigateurs interprétaient différemment le fait qu'une variable soit envoyée plusieurs fois dans la même requête. • Certains vont ne considérer que la 1ère , d'autre la dernière et les plus intéressants vont concaténer les deux. 57
- 58. HPP Réaction des serveurs Web à la requête Source: HPP: First OWASP Paper by Luca Carettoni and Stefano di Paola GET /target/foo?par1=val1&par1=val2 58
- 59. HPP Source: Automated Discoveryof Parameter Pollution Vulnerabilities in Web Applications Statistiques sur les réponses des serveurs WEB à une requête HTTP avec un même paramètre multiplié (pollué) 59
- 60. HPP pour contournerla sécurité des Web Applications Firewalls (WAF) • ModSecurity SQL Injection filter bypass Concept introduit par Lavakumar Kuppan La requête suivante est proprement détectée: /index.aspx?page=select 1,2,3 from table where id=1 En utilisant le HPP, il est possible de contourner la protection du filtre: (Split & Join*) /index.aspx?page=select 1&page=2,3 from table where id=1 60
- 61. Simple PoC ofHPP La redirection se fera vers http://www.owasp.org ou plutôt vers http://www.yaboukir.com ? http://www.facebook.com/l.php?u=http://www.owasp .org&h=3e88d&u=http://www.yaboukir.com De même si on essaie 3 valeurs pour « u »: http://www.facebook.com/l.php?u=http://www.owasp .org&h=3e88d&u=http://www.yaboukir.com&u=htt ps://www.owasp.org/index.php/Morocco 61
- 62. Clickjacking détournement declic, est une technique malveillante visant à pousser un internaute à fournir des informations confidentielles ou à prendre le contrôle de son ordinateur en le poussant à cliquer sur des pages apparemment sûres. 62
- 63. Clickjacking • Les propriétésHTML permettent de manipuler lʼaffichage dʼune page web. Il est possible de positionner des calques (élément HTML DIV) à des endroits prédéfinis dʼune page, et de jouer sur la profondeur lors de la superposition de plusieurs calques. • Placer un calque transparent en première position, afin que lʼutilisateur ne visualise que le calque en arrière-plan. 63
- 64. Clickjacking 64
- 65. Clickjacking Proof of Concept Vousferiez à ma page sans s‟en rendre compte :p 65
- 66. Bypassing CSRF protectionswith HPP & Clickjacking Cette technique transforme une attaque par Clickjacking en une attaque CSRF efficace par l'envoi de formulaires à travers des domaines avec un contenu malveillant contrôlé à l'aide des paramètres HTTP polullés (utilisant leHPP). En JSP et Java Servlets lorsqu'un formulaire est soumis avec à la fois la QueryString et un corps de requête contenant un paramètre du même nom, la valeur de la QueryString est privilégiée. Ce problème peut être exploité en incluant la valeur du paramètre contrôlé par attaquant dans la QueryString de l'URL appelé à partir d'une iframe invisible.
- 67. Clickjacking + HPP+ Social Engineering Bypassing CSRF token protections
- 68. HPP part ofthe attack URL: Normal: http://www.example.com/updateEmail.jsp Attack: http://www.example.com/updateEmail.jsp?email=evil@attacker.mail Form: <form method="POST"> <input type="text" name="email" value=””></input> <input type="hidden" name=”csrf-token” value="a0a0a0a0a0a"/> </form> HTTP Request: POST /updateEmail.jsp?email=evil@attacker.mail HTTP/1.1 Host: www.example.com email=&csrf-token=a0a0a0a0a0 Server Interpretation: request.parameter("email") ===> evil@attacker.mail
- 69. Clickjacking part ofthe attack How attacker’s site looks to the victims (Harmless) The form submitted by Clickjacking (Critical) How the IFRAME and the Critical form actually overlap (One-click CSRF) Hidden IFRAME URL: http://www.victim.site/udateEmail.jsp?email=evil@attacker.mail
- 70. Bypassing CSRF tokenprotections Proof of Concept Votre email de login sera modifié sans que vous le sachiez :p
- 71. Les 5 risquesles plus critiques des applications Web Merci pour votre aimable attention!
- 72. Special thanks to Lavakumar Kuppan for sharing the CSRF bypass senario with me! 72
- 73. References • OWASP Top10 - 2010 rc1: Les 10 risques les plus critiques des applications Web. Par Sébastien GIORIA. • Le projet OWASP, par Sébastien GIORIA @ OSSIR, Paris 08/07/2008 • OWASP WebGoat v5, par OWASP 16 April 2010 • HTTP Parameter Pollution Vulnerabilities in Web Applications, par Marco „embyte‟ Balduzzi, @ BlackHat Europe 2011 • HTTP Parameter Pollution, par Luca Carettoni & Stefano di Paola, @ OWASP AppSec Europe 2009 - Poland • Bypassing CSRF protections with HPP & Clickjacking, By, par Lavakumar Kuppan • Bypassing Web Application Firewalls with HTTP Parameter Pollution, par Lavakumar Kuppan
Notes de l'éditeur
- #5 REMEMBER… OWASP IS JUST PEOPLEYou are all probably familiar with OWASP, so I’d like to take this opportunity to share a few metrics and give you an idea of where OWASP is headed.I’ve been the volunteer chair of OWASP since 2004, and I’ve spent quite a lot of time, effort, and my own money developing the organization. Why do I do all this? Why do I care?AppSec is about not about tools or technology… it’s about people. OWASP is about community.______________
- #8 2007Roughly $329K income ($72K membership, $257K conf/training/sponsor)Expenses $294K ($155K conferences, $76K SOC, $62K foundation)Current:Roughly $400K in the bank (before SOC 2008)
- #11 In terms of OWASP Tools and Technology, our coverage is a bit spotty, but we’re actively working to remedy that.We have a lot of tools for automated verification, but we lag behind the commercial tools a bit here. We have 3 SoC projects to build better static and dynamic tools, so look for some advances here.Our manual verification tools are quite good, with WebScarab listed as one of the most popular security tools anywhere.In the security architecture area, we do not have a lot of tools or technology, although the Enterprise Security API is an important part of this key area.We have a number of tools to encourage security coding, including several appsec libraries and many guards and filters.Our appsec management tools are fairly weak, although the OWASP Report Generator shows some promiseAnd in the AppSec Education area, the WebGoat tool has been very successful, although this region is yellow because we can and should do more in the education areas.