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

Sécurisation des applications web JUG Montpellier, Avril

Présentations similaires


Présentation au sujet: "Sécurisation des applications web JUG Montpellier, Avril"— Transcription de la présentation:

1 Sécurisation des applications web JUG Montpellier, Avril

2 Agenda Introduction –Le speaker, le contexte, ce dont nous nallons pas parler et le reste Sécurité des applications Web LOWASP –Le top10 –Les autres ressources Quelques principes de secure coding Conclusion / Ressources

3 INTRODUCTION Pour commencer..

4 Introduction: Le speaker –Hubert GREGOIRE Formation Systèmes & Réseaux, EPITA94 + de 20 ans dexpérience –Directeur Technique chez Editeur leader de lachat public –Formateur Learning Tree Internationnal Titres: Sécurité Web et mobiles, Dév. Java, JavaScript, et WebServices mais aussi Wifi. –Membre de lOWASP depuis 2009

5 Introduction: Le contexte Etude de WASC de 2010, sites avec vulnérabilités

6 Introduction: Le contexte (suite) –« Les vulnérabilités au sein des applications Web sont désormais le vecteur le plus Important (55%) des attaques dirigées contre les entreprises. » selon Gartner Group Les applications Web contrôlent toutes nos activités (e-commerce, voyages, plan, bureautique, messagerie, gestion, santé, RH, solutions verticales…) Les décideurs, les développeurs sont peu responsabilisés et sensibilisés aux parades et solutions

7 Introduction: Le contexte (suite) Firewall TLS OS renforcé Serveur Web renforcé Conterner Java Firewall Base de donnéesInfrastructure ITWeb Services Répertoires / fichiers SIRH / CRM /ERPCompta bilité WebApp métier dévelppée sur mesure ATTAQUE APPLICATION Couche réseau Couche Applicative Le code de votre application est le maillon faible

8 Introduction: La sécurité des applications Web, ce nest pas: L'ingénierie sociale (ou social engineering) –Pour cela, demandez à Kevin La Sécurité système –ouf XP est mort, tout va bien, La Sécurité réseau –le firewall et OpenSSL sen occupent … Ni, comment se créer des bitcoins ou casser la clé Wifi de votre voisin(e)

9 SECURITÉ DES WEBAPP Une branche de la sécurité informatique

10 Une nouvelle aire Age des antivirus Age de la sécurité réseau Age de la sécurité applicative 2000 …

11 Types dattaques Source : Rapport Cenzic – 1 er semestre 2009

12 Faiblesses des applications Web 75 % 90 % 25 % 10 % % Attaques% Dépenses Etude du GARTNER % des attaques ciblent le niveau Applicatif 66% des applications web sont vulnérables Application Web Eléments Réseaux Etude du SANS (septembre 2011)

13 De nouvelles menaces Activisme, Réseaux sociaux, Cloud, HTML5… Source Etude Verizon, 2013

14 Conséquences dune vulnérabilité Vol de données Usurpation didentité Indisponibilité de services Perte financière Perte des clients Image dégradée Perte de temps… 96% des attaques sont simples (Vérizon)

15 Types de vulnérabilité Authentification –Brute Force, Authentification insuffisante, Restauration de mdp Autorisation –Prédiction de session, Autorisation insuffisante, Expiration de session Attaque coté client –Usurpation de contenu, XSS Exécution de commandes –Buffer Overflow, Injection, prise de contrôle Fuites dinformations –Indexation de répertoires, commentaires, requêtes prévisibles Attaque logiques –Déni de service, abus de fonctionnalités, validation insuffisante

16 Ce que disent les experts métiers « Seuls des pirates peuvent nous attaquer ! » Des outils simples et complets sont disponibles sur Internet Essayez de chercher «SQL Injection » sur YouTube ! Sinon, une attaque complexe peut sacheter entre 100 et 200 par jour.

17 Qui sont les pirates ? Majoritairement des bidouilleurs, curieux qui veulent casser un système (Hackers) mais avec une certaine éthique. Mais aussi des scripts keedies, des ex- employés malveillants, des concurrents, le crime organisé (chantage), des gouvernements (espionnage, veille concurrentielle)

18 Notion de risque La sécurité informatique, est un savant équilibre entre lutilisabilité et la limitation des vulnérabilités dune application Le risque 0 nexiste pas RISQUE = GRAVITE * VALEUR * MENACE Nous allons limiter la gravité « Un serveur sûr est forcément éteint»

19 Peut on sécuriser ? Oui, mais la sécurité peut coûter cher –Ne sécuriser que ce qui a besoin de lêtre (classifier les données) –Approche itérative ( couche par couche, application par application …) –Doit être globale tout au long du cycle de vie « Une application sécurisée est une application qui fonctionne comme prévu » Sécurité prise en compte dans les US et les nombreux cas de test

20 Comment se protéger ? Sensibilisation / Formation des acteurs Utilisation de Framework éprouvés, libres Outils/Scanners pour tests de sécurité –Automatique / Manuel / Mixte –Réseau ( boite noire ), Code (boite de verre), Profiler –One shot ou en intégration continue WAF ( Web Application Firewall ) à ne pas confondre avec Wife Acceptance Factor Revue de code / Pair programming Une seule méthode ne suffit pas automatique/manuel, attention aux faux positifs et faux négatifs !

21 LOWASP KESAKO ? LOpen Web Application Security Project

22 LOWASP Open Web Application Security Project (OWASP) est une communauté publique mondiale open source permettant aux organismes de développer, acheter et maintenir des applications fiables. LOWASP publie les élèments suivants: Le Top10, classement des principales vulnérabilités des WebApp Des normes et des outils pour sécuriser les applications Web Des Bonnes Pratiques (Cheat Sheets) Des guides complets sur les tests de sécurité, le développement et laudit de code Et bien plus… le tout sur Les outils, documents, listes de diffusion et forums de lOWASP sont gratuits et ouverts à tous. Référence de MITRE, PCI DSS, FTC

23 Le top10 Classement des 10 vulnérabilités les plus critiques et courantes sur les Webapp selon des évaluations dexperts Classification de A1 à A10, descriptions, solutions et exemples Java,.net et php Mise à jour en 2004, 2007, 2010 et 2013

24 Injection passe devant XSS en 2013 ! Modernisation des applications Correction au niveau des firewall, des framework et des pratiques

25 A1-Injection Une faille d'injection, de type SQL, HQL, OS et LDAP, se produit quand une donnée non fiable est envoyée à un interpréteur en tant qu'élément d'une commande ou d'une requête Exemple Solutions Utiliser les RegExp pour contrôler les data Utiliser les prepared Statement Limiter les droits de lutilisateur String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") +"'";

26 A2 - Violation de Gestion dAuthentification et de Session es fonctions applicatives relatives à l'authentification et la gestion de session ne sont souvent pas mises en oeuvre correctement, permettant aux attaquants de compromettre les mots de passe, clés, jetons de session Exemple Solutions : Utiliser un framework éprouvé qui gère correctement les sessions, et ne développer/tester qui si réellement nécessaire ?dest=Hawaii

27 A3-Cross-Site Scripting (XSS) Les failles XSS se produisent chaque fois qu'une application accepte des données non fiables et les envoie à un browser sans validation appropriée. Exemple Solutions –Contrôler les saisies utilisateurs –Encoder lors de la présentation ou de la persistance –Utiliser des librairies ou des Framework (String) page += " ";

28 A4-Références directes non sécurisées à un objet Une référence directe à un objet se produit quand un développeur expose une référence à un objet d'exécution interne, tel un fichier, un dossier, un enregistrement de base de données ou une clé de base de données. Exemple Solutions –Contrôler les saisies utilisateurs –Utiliser des références indirectes coté serveur

29 A5-Mauvaise configuration Sécurité Une bonne sécurité nécessite de disposer d'une configuration sécurisée définie et déployée pour l'application, contextes, serveur d'application, serveur web, serveur de base de données et la plate-forme. Exemple Journaux sur / ou c: Option autodeploy Sources jsp compilés au runtime Solutions –Gestion de conf, suppression des services inutiles –Scanner réseaux, limitation droits des service

30 A6-Exposition de données sensibles Beaucoup de webapp ne protègent pas les données sensibles telles que les cartes de crédit, identifiants et les informations d'authentification Exemple Les données stockées/archivées et circulent en clair? Solutions Ne conserver que les données sensibles nécessaires. Les données que lon ne possède pas ne peuvent être volées

31 A7-Manque de contrôle daccès au niveau fonctionnel Pratiquement toutes webapp vérifient les droits d'accès au niveau fonctionnel avant de rendre cette fonctionnalité visible dans l'interface utilisateur Exemple Solutions Votre application devrait utiliser un module de gestion des autorisations consistant, facilement analysable et appelé depuis les fonctionnalités métier

32 A8-Falsification de requête intersite (CSRF) Une attaque CSRF (Cross Site Request Forgery) force le navigateur d'une victime authentifiée à envoyer une requête HTTP forgée. Exemple Solutions –La meilleure option est dinclure un jeton unique dans un champ caché, ou dutiliser un outil qui le fait.

33 A9-Utilisation de composants avec des vulnérabilités connues Les composants vulnérables, tels que bibliothèques, contextes et autres modules logiciels fonctionnent presque toujours avec des privilèges maximum. Exemple CXF Authentification Bypass –ne fourni pas de jeton dauthentification Solutions –Monter de version –Plus de tests avant la mise en prod..

34 A10-Redirections et renvois non validés Les applications web réorientent et redirigent fréquemment les utilisateurs vers d'autres pages et sites internet. Exemple Solutions Eviter lutilisation des redirections et des renvois. En cas dutilisation, ne pas utiliser de valeur de destination dans les paramètres utilisateur mais un code ou un jeton unique

35 Les autres ressources Des guides du test, de laudit et du dev. Outils ( ZAP, WebSarab, CRS mod_security) Librairies ESAPI, CSRFGuard, AntiSammy Méthodologies OpenSAMM, ASVS Fiches pratiques (Cheat Sheets) conférences, des chapitres locaux… Nouveaux : Mobile Top10, Node.js Projects developers-guide-v /paperback/product html

36 NOTIONS DE SECURE CODING Un peu de rocknroll et du code…

37 Les principes de secure coding Enfin un peu de code et de rockn roll Un principe, méfiez vous de tout: –Des données (paramètres) –De la JVM (autres classes) –Du Système de fichiers

38 Pour éviter le déni de service Relâchez toute les ressources, moins critique depuis java 7 ! final OutputStream rawOut = new FileOutputStream(file); try { final BufferedOutputStream out = new BufferedOutputStream(rawOut); use(out); out.flush(); } finally { rawOut.close(); } final OutputStream rawOut = new FileOutputStream(file); try { final BufferedOutputStream out = new BufferedOutputStream(rawOut); use(out); out.flush(); } finally { rawOut.close(); }

39 Pour éviter les fuites de données Purger les informations sensibles dans les exceptions Ne pas tracer des données confidentielles dans les journaux sensitiveData.set(DUMMY); logger.error(Erreur pour. + sensitiveData ); try { final FileInputStream(file rawIn = new FileInputStream(file); sensitiveData data = new SensitiveDate( secret ); … stuff … } catch (IOException e) { if(sensitiveData!=null){ sensitiveData.set(DUMMY); } logger.error(Erreur a la lecture du fichier..); }

40 Attention à la sérialisation, qui contourne le constructeur Pour les données sensibles, inhibez la sérialisation/désérialisation: private final void readObject(ObjectInputStream in) throws java.io.IOException { throw new java.io.IOException("Class cannot be deserialized"); } private final void writeObject(ObjectOutputStream out) throws java.io.IOException { throw new java.io.IOException("Object cannot be serialized"); }

41 Attention à la méthode clone() qui contourne le constructeur Rendre une classe non clonable public final void clone() throws java.lang.CloneNotSupportedException { throw new java.lang.CloneNotSupportedException(); } Eviter que qqun surcharge la méthode clone() dun objet sensible public final void clone() throws java.lang.CloneNotSupportedException { super.clone(); }

42 Secure coding cest aussi Du code propre, commenté, lisible –Evitez dans la mesure du possible les syntaxes courtes du C++, pré Incrément et opérateur ternaire … –Utilisez des noms de variables explicites –Stockez jamais des données sensibles en clair, même en mémoire, au pire utiliser un char[] au lieu dune String (contiguë) –Sauf besoin tout est final et private CheckStype, PMD, Findbugs proposent des règles sécure coding

43 Spécifiquement pour le Web Méfiez vous de tout ce qui vient du navigateur et du réseau (userAgent, Cookies, data, headers…) Préférez POST a GET, désactivez PUT/DELETE si inutilisés (nactivez que pour REST par exemple) Contrôlez les upload de fichier Effectuez les traitements confidentiels, contrôles, encodages/décodages seulement coté serveur Utilisez les flags httpOnly et secure de cookie

44 Traitement XML et WebSevices Utilisez plutôt les API (sax, stax) ou des librairies éprouvées pour parser ou générer des fichier XML, et evitez la génération manuelle. Tout fichier XML parsé doit être validé par un schéma strict –Activez les options schemaValidation de lAPI –Selon les moyens utilisez un Firewall n7 ou XML Firewall Protégez vos XSD, ils deviennent critiques Evitez limportation de fichiers externes Précisez vos espaces de nommage

45 Guide pratique Secure Coding LOWAP publie des guides pratique ( Cheat Sheet ) sur de nombreux sujets, dont: HTML5, JAAS, XSS /SQL Injection Prevention, Access Control, REST, Web Services Les préconisations générales sont des sessions de 15 minutes, 5 essais max, mot de passe de 8 caractères dont 3 spéciaux, rotation tous les 90 jours…

46 Oracle, Java secure coding Oracle maintien une page des bonnes pratiques pour une programmation Java plus sûre. –http://www.oracle.com/technetwork/java/seccodeguide html#3http://www.oracle.com/technetwork/java/seccodeguide html#3 –Visibilité –ClassLoader –Protéger son Constructeur –Utiliser le security manager Nombreux articles sur le Web

47 CONCLUSION Vous êtes bientôt libre…

48 Ressources Secure Coding Guidelines for Java OWASP Secure Coding Practices - Quick Reference Guide https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_- _Quick_Reference_Guide Secure Computing Magazine Etudes Verizon 2013 et Qualys 2010 Stay curious ! MERCI POUR VOTRE ATTENTION !


Télécharger ppt "Sécurisation des applications web JUG Montpellier, Avril"

Présentations similaires


Annonces Google