Sébastien OSSIR Paris le 08 Juillet 2008

Présentation au sujet: "Sébastien OSSIR Paris le 08 Juillet 2008"— Transcription de la présentation:

1 Sébastien GIORIA @ OSSIR Paris le 08 Juillet 2008
Le projet OWASP Sébastien OSSIR Paris le 08 Juillet 2008

2 Agenda L’OWASP Les publications de l’OWASP Les outils Le Top 10

3 Sébastien Gioria Consultant indépendant en sécurité des systèmes d’informations. +10 ans dans le domaine de la sécurité informatique (banque, assurance, télécoms, …) Représentant Français de l’association américaine.

4 Le constat actuel Le système d’information s’ouvre :
Architectures orientées services Intégration de partenaires « multi-play/multi-canal » : Internet, Téléphone, Mail, Vidéo, … La sécurité aujourd’hui Niveau 1 : Le cable Niveau 2 : VLAN Niveau 3 : Liste de contrôle d’accès Niveau 4 à 7 : Firewall, Proxy, IDS, IPS Niveau 8 : L’utilisateur

5 Making Application Security Visible
At the core, OWASP is a just a community of people passionate about application security. We all share a vision of a world where you can confidently trust the software you use. Unfortunately, the current software market doesn’t encourage security – that’s something we’re trying to change. One of our primary missions is to make application security visible so that people can make informed decisions about risk. You’ll find lots of free and open source tools, documents, basic information, guidelines, presentations, video, and blogs at OWASP to help you get started. You’ll also find a rich community of people on our mailing lists, participating in our local chapters, and attending our conferences to help you.

6 L’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 a tous En France : une association; pour supporter les problèmes juridiques francais. Le point d’entrée est le wiki

7 Google Trends Data for:
We’re only just starting to scratch the surface of application security. There’s a huge amount of work to do. Despite all the efforts of all the great people involved in OWASP, the world’s software is most likely getting less and less secure. As we increase our interconnections and use more and more powerful computing technologies, the likelihood of introducing vulnerabilities increases exponentially. After 30 years, we’re finally starting to see the decline of the buffer overflow. We didn’t get smarter about software development, we’re just switching to platforms that don’t encourage buffer overflows. After a decade, we’re still seeing widespread XSS problems. And we’re introducing new technologies faster much faster than we can secure them. Things like Web Services, Ajax, Flex, Air, Silverlight, and JFX come right to mind. Whatever the internet becomes, OWASP can play a key role in making sure that it is a place we can trust. Thank you all for your participation in OWASP – I’m looking forward to working with all of you. Google Trends Data for:  Buffer overflow  XSS Thank You

8 Organisation de l’OWASP
OWASP Conferences OWASP Wiki OWASP Tools OWASP Lists OWASP Books OWASP Community OWASP Governance OWASP Chapter Leaders OWASP Project Leaders OWASP Foundation (501c3) Board of Directors (Williams, Wichers, Brennan, Cruz, and Deleersnyder) Board of Advisors Operations Director (McNamee) Technical Director (Casey)

9 Finances and Grants 100% OWASP Grants OWASP Foundation 55% 2007
OWASP Autumn of Code 2006 $20,000 budget OWASP Spring of Code 2007 $117,500 budget OWASP Summer of Code 2008 $126,000 budget 100% 55% 2007 Roughly $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) 45% OWASP Foundation

10 OWASP Is Alive! 2009 … 2007 2005 OWASP plays a special role in the application security ecosystem. We’re a vehicle for sharing knowledge and best practices across organizations. We have been very careful to limit commercial influence on what we do. Many people employed by vendors participate, but only as individuals. We are entirely volunteer and have very low expenses, so we award 100% of our membership funds as grants back to promising application security projects. Application security is moving very quickly and we’re working hard to tackle the newest, most difficult problems. Do you have a bookshelf of security books? When’s the last time you opened them? They don’t have answers to today’s problems because they’re dead. When they say, “print is dead” they don’t mean it’s out of style – it’s static not living! Think of OWASP as a process for translating security principles to the latest technologies and getting them to developers fast It’s an evolving growing living thing 2003 2001

11 L’OWASP 420 000 pages vues par mois 15 000 téléchargements par mois
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é

12 OWASP SoC 2008 – AppSec Innovation
AppSensor Teachable Static Analysis Workbench XML/WS Testing Tool AntiSamy .NET Positive Security Project JSP TagLib Tester Online Code Signing Service Access Control Rules Tester Most Innovative AppSensor Most applications let you attack them forever without noticing. We’re studying what events and patterns WITHIN THE APPLICATION indicate attacks in progress. In my mind, this is the single most effective thing we can do to lessen the likelihood of successful attacks. Teachable Static Analysis Workbench We’re examining the process of teaching the tool about the application it’s analyzing – in order to get less false positives and more useful data. This will be an Eclipse plugin that dynamically recomputes. XML/WS Testing Tool There’s a glaring lack of tools to do effective security testing of web services and XML, so we’re building one. AntiSamy .NET If you’re accepting “rich content” from users, you need AntiSamy. It’s a library that performs whitelist validation of HTML against a set of customizable rules. We see more and more rich data being passed around in the future. The current project is in Java, this will extend support to .NET. Positive Security Project If you’re tired of everything in application security being organized by negative concepts like threats, attacks, and vulnerabilities, the Positive Security Project is reframing application security from an assurance perspective. Not that the negative stuff isn’t important, but it’s important to start with the positive. JSP TagLib Tester This is an innovative tool to test JSP (and other UI components) for their susceptibility to XSS. Instead of testing from the outside, the tool instantiates the controls and attempts to inject scripts from within the code. The result is a detailed guide of where script injection is possible. Online Code Signing Service Using MD5 hashes is finished. Currently the only way to get code signed is through verisign. This project will establish an OpenSign server, a process, and a set of supporting tools. Access Control Rules Tester Access control is a huge source of serious vulnerabilities, and is only trivally covered by current tools. This tool will build, compare, and test role-based sitemaps, identifying possible access control problems at the URL, business logic, and data level. Other Projects: Three different code analysis tools Two new vulnerability scanners Testing Guide v3, Code Review Guide v1.1, LiveCD update .NET Project reboot Backend Security Internationalization Classic ASP Security SQLiBench SiteGenerator Refresh App Security Verification Standard

13 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 With almost 4000 articles, OWASP is the largest knowledgebase of application security information anywhere. Now bigger is not always better, so let me explain a little bit about our process. We put the wiki in place about 2 years ago – the same software wikipedia uses. OWASP gets about 200 updates to the wiki every day. Most of these are relatively minor, but some are entire new articles. A team of reviewers worldwide follows all of these updates via an RSS feed. In the two years, we’ve only had 19 attempts to deface the site, and we caught them all the same day. Please do not take this as a challenge – defacing a wiki is no accomplishment. We also have 31 different documentation projects that are actively monitoring and digesting all the application security information we can find. We monitor presentations, mailing lists, white papers, and tons of feeds for useful information. We clean, sort, organize, tag, and structure the information and add it to our knowledgebase. There is also one extremely important filter that is applied to all the information we can find. We try to eliminate all of the commercial bias. If we discuss commercial solutions, we steer clear of specific products and companies and try to focus on the different approaches to the problem. I’ll talk more about the finances in a minute, but although there are many product vendors who are members of OWASP, they do not control the agenda in any way. We are also actively deleting information. Several projects are “refactoring” our knowledgebase to minimize duplication. To ensure the high quality of the materials, we are publishing parts of the knowledgebase as books. You can download the PDF’s of these books for free, or buy a printed copy from Lulu for the cost of publishing – OWASP adds nothing to the cost. I’d like to point out one very cool work that is being published later this year – the Application Security Desk Reference. Like the Physicians’ Desk Reference, this will be an extensive reference work, documenting all the fundamental concepts in application security: principles, threat agents, attacks, vulnerabilities, controls, technical impacts, and business impacts. All of the knowledgebase, including the books, are available under the Creative Commons license.

14 OWASP Tools and Technology
Automated Security Verification Vulnerability Scanners Static Analysis Tools Fuzzing Manual Security Verification Penetration Testing Tools Code Review Tools Security Architecture ESAPI Secure Coding AppSec Libraries ESAPI Reference Implementation Guards and Filters AppSec Management Reporting Tools AppSec Education Flawed Apps Learning Environments Live CD SiteGenerator 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 promise And 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.

15 Un Conseil d’Administration (association loi 1901) :
OWASP en France Un Conseil d’Administration (association loi 1901) : Président/évangéliste/relations publiques : Sébastien Gioria Vice-Président et responsable du projet de traduction : Ludovic Petit Secrétaire et Responsable Juridique : Estelle Aimé Un Bureau : Le CA Romain Gaucher : chercheur au NIST Mathieu Estrade : développeur apache

16 OWASP en France Projets : Interventions :
Top 10 : finalisé, marketing viral en cours Guide : En gestation SoC 2008 : divers review de projets Questionnaire a destination des RSSI sur le sujet : en cours Interventions : Infosecurity 2007 Microsoft TechDays 2008 Infosecurity 2008 Sensibilisation / Formations : Mutuelle d’assurance (Java/PHP) Société d’EDI (JAVA / .NET) Opérateur Téléphonie mobile (PHP) Ministère de l’intérieur – SGDN Conférences dans des écoles a venir

17 Les documents sont issus de différentes collaborations :
Les publications Toutes les publications sont disponibles sur le site de l’OWASP: 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

18 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 »

19 Les Guides 100% Libres. Issus de 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.

20 OWASP Enterprise Security API (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

21 WebGoat - WebScarab WebGoat : WebScarab :
Application Java serveur (JSP, JEEE) non sécurisés. Sert a démontrer les failles, leur principe et a éduquer WebScarab : Application Java permettant d’effectuer des tests de sécurité : Sur les applications Web Sur les WebServices

22 Quelques outils Outil de 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 :

23 Liste les 10 vulnérabilités des applications Web les plus rencontrées
Le Top 10 Liste les 10 vulnérabilités des applications Web les plus rencontrées Mis a 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

24 Le Top 10 A1 - Cross Site Scripting (XSS) A2 – Faille d'injection
A3 – Exécution de fichier malicieux A4 – Référence directe non sécurisée à un objet A5 – Falsification de requête inter-site (Cross Site Request Forgery - CSRF) A6 – Fuite d'information et traitement d'erreur incorrect A7 – Violation de gestion d'authentification et de session A8 – Stockage cryptographique non sécurisé A9 – Communications non sécurisées A10 – Manque de restriction d'accès URL

25 A1 - Principe d’une attaque XSS
But : Envoyer l’utilisateur vers un site Web malicieux Récupérer des informations contenues dans le navigateur Principe : Mail ou lien malicieux Exécution de code dans le navigateur Récupération de données : cookies, objets(IE) Envoi des données vers l’attaquant. Dangerosité : Passe outre les contrôles de sécurité (Firewall, IDS, …) Coupler à certaines attaques, cela permet d’accéder au LAN

26 A1 - Les protections Effectuer une validation en profondeur :
Des headers, Des cookies, Des chaînes de requêtes, Des champs de formulaires, Et aussi des champs cachés, .NET: Utilisez la bibliothèque Microsoft Anti-XSS 1.5 disponible gratuitement sur MSDN : Utiliser le projet des filtres OWASP(Java/PHP) :

27 A2 - Injection de données (SQL, LDAP, commandes, …)
But : Corrompre des données d’une base, d’un annuaire. Récupérer des informations sensibles dans des bases ou annuaires Exécuter des commandes sur un système distant. Principe : Par la modification de la donnée attendue, la requête d’accès à une base SQL est modifiée. Dangerosité : Est-il utile de l’expliciter ?

28 A2 - Les protections Valider les données Renforcer les mécanismes du plus faible privilège. Java EE : utilisation de Spring et Hibernate .NET : utilisation de SqlCommand avec SqlParameter ou Hibernat PHP : utilisation de PDO

29 A3 - Exécution de fichier malicieux
But : Installation de code sur le poste distant. Installation de rootkits Principe : Par la modification d’une donnée, un fichier de commande est envoyé sur le serveur et exécuté Dangerosité : Est-il utile de l’expliciter ?

30 A5 - Cross Site Request Forgery - CSRF
But : Exécuter une action non désirée par un client sur un site. Récupérer des informations internes Principe : Exécution de requêtes sur un site malveillant de façon cachée (via une iframe par ex). Dangerosité : Passe outre les firewalls/IDS Permet d'accéder au LAN Interne Pas besoin de Javascript

31 A5 - Comment se protéger Vérifier que le code est immune aux vulnérabilités XSS… Ne pas utiliser GET pour les traitements sensibles Ajouter des jetons aléatoires et uniques qui ne peuvent être envoyés automatiquement par le navigateur Pour ASP.NET, utilisez ViewStateUserKey OWASP CSRF Guard, OWASP PHP CSRF Guard,

32 A6 - Fuite d’informations
But : Récupérer de l’information sur l’application ou le système. Principe : Envoie de données provoquant une exception Dangerosité : Faible, mais néanmoins très utile pour un attaquant

33 A6 - Comment s’en protéger
Désactiver ou limiter la gestion des erreurs/exceptions. Modifier le traitement d’erreur pour qu’il retourne une code HTTP 200 Ok.

34 A7 - Violation de session ou d’authentification
But : Obtenir un jeton de session permettant alors de se faire passer pour un autre Principe : Modification des données de type ASPSESSIONID Dangerosité : Est-il utile de l’expliciter ?

35 A7 - Protection Utiliser uniquement des mécanismes de sessions internes aux librairies ou Framework Ne pas accepter des identifiants de sessions par défaut Éviter d'utiliser ou limiter l'utilisation de cookies personnalisés pour l'authentification

36 Les attaques sur les architectures WebServices
XML Bomb : Trivial à effectuer : Référence récursive à une entité du même document : Peut provoquer un déni de service ! <?xml … …. <!entity owasp0 « Owasp »> <!entity owasp1 « &owasp0;&owasp0> <!entity owasp « &owasp424241;&owasp424241 »> <owasptest>&owasp424242;</owasptest>

37 Les Attaques sur les architectures WebServices
Injection XML Permet de modifier les données d’entrée d’un WebService. Injection Xpath/Xquery Permet d'exécuter des requêtes de façon similaire à SQL XSS && Injection SQL Même principe que dans une architecture classique. Mêmes dégâts possibles ! Bombes SOAP : Attaques en dénis de services via les tableaux SOAP Bombes XML + SOAP …..

38 Les protections ultimes ?
Former les développeurs au développement sécurisé ! Vérifier les données ! Tester son code ! Débrancher la prise Réseau…..

39 Q & R