Sécurisation des applications web JUG Montpellier, Avril 2014 @hgregoir hubert.gregoire@free.fr

Agenda Introduction Sécurité des applications Web L’OWASP Le speaker, le contexte, ce dont nous n’allons pas parler et le reste Sécurité des applications Web L’OWASP Le top10 Les autres ressources Quelques principes de secure coding Conclusion / Ressources

Pour commencer.. Introduction

Introduction: Le speaker Hubert GREGOIRE Formation Systèmes & Réseaux , EPITA’94 + de 20 ans d’expérience Directeur Technique chez Editeur leader de l’achat public Formateur Learning Tree Internationnal Titres: Sécurité Web et mobiles, Dév. Java, JavaScript, et WebServices mais aussi Wifi. Membre de l’OWASP depuis 2009

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

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

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

Introduction: La sécurité des applications Web, ce n’est 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 s’en occupent … Ni, comment se créer des bitcoins ou casser la clé Wifi de votre voisin(e)

Une branche de la sécurité informatique Securité des webapp

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

Types d’attaques Source : Rapport Cenzic – 1er semestre 2009

Faiblesses des applications Web 75 % 90 % 25 % 10 % % Attaques % Dépenses Etude du SANS (septembre 2011) http://www.sans.org/top-cyber-security-risks/ Application Web Eléments Réseaux Etude du GARTNER 2003 75% des attaques ciblent le niveau Applicatif 66% des applications web sont vulnérables

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

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

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 d’informations Indexation de répertoires, commentaires, requêtes prévisibles Attaque logiques Déni de service, abus de fonctionnalités, validation insuffisante

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 s’acheter entre 100€ et 200€ par jour.

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)

Notion de risque La sécurité informatique, est un savant équilibre entre l’utilisabilité et la limitation des vulnérabilités d’une application  Le risque 0 n’existe pas RISQUE = GRAVITE * VALEUR * MENACE  Nous allons limiter la gravité « Un serveur sûr est forcément éteint»

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

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 !

L’Open Web Application Security Project L’OWASP kesako ?

L’OWASP 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. L’OWASP 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 l’audit de code Et bien plus… le tout sur www.owasp.org/ Les outils, documents, listes de diffusion et forums de l’OWASP sont gratuits et ouverts à tous. Référence de MITRE, PCI DSS, FTC

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

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

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 l’utilisateur String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") +"'";

A2 - Violation de Gestion d’Authentification 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 http://example.com/sale/saleitems;masessionid= 45131215?dest=Hawaii

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 += "<inpuAt name='creditcard' type='TEXT‘ value='" + request.getParameter("CC") + "'>";

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 http://example.com/app/accountInfo?acct=notmyacct

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

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 l’on ne possède pas ne peuvent être volées

A7-Manque de contrôle d’accè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 http://exemple.com/app/getappInfo http://exemple.com/app/admin_getappInfo Solutions Votre application devrait utiliser un module de gestion des autorisations consistant, facilement analysable et appelé depuis les fonctionnalités métier

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 <img src="http://example.com/app/transferFunds? amount=1500&destinationAccount=attackersAcct#“ width="0" height="0" /> Solutions La meilleure option est d’inclure un jeton unique dans un champ caché, ou d’utiliser un outil qui le fait.

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 d’authentification Solutions Monter de version Plus de tests avant la mise en prod..

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 http://www.example.com/redirect.jsp?url=evil.com Solutions Eviter l’utilisation des redirections et des renvois. En cas d’utilisation, ne pas utiliser de valeur de destination dans les paramètres utilisateur mais un code ou un jeton unique

Les autres ressources Des guides du test, de l’audit 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 http://www.lulu.com/shop/owasp/owasp-developers-guide-v20-2005/paperback/product-3545912.html

Notions de secure CODING Un peu de rock’n’roll et du code… Notions de secure CODING

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

Pour éviter le déni de service final OutputStream rawOut = new FileOutputStream(file); try { final BufferedOutputStream out = new BufferedOutputStream(rawOut); use(out); out.flush(); } finally { rawOut.close(); } 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(); }

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 ..’);

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"); }

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() d’un objet sensible super.clone();

Secure coding c’est 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 d’une String (contiguë) Sauf besoin tout est final et private  CheckStype, PMD, Findbugs proposent des règles sécure coding

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 (n’activez 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

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 l’API Selon les moyens utilisez un Firewall n7 ou XML Firewall Protégez vos XSD, ils deviennent critiques Evitez l’importation de fichiers externes Précisez vos espaces de nommage

Guide pratique Secure Coding L’OWAP 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…

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-139067.html#3 Visibilité ClassLoader Protéger son Constructeur Utiliser le security manager Nombreux articles sur le Web

Vous êtes bientôt libre… Conclusion

MERCI POUR VOTRE ATTENTION ! Ressources Secure Coding Guidelines for Java http://www.oracle.com/technetwork/java/seccodeguide-139067.html OWASP Secure Coding Practices - Quick Reference Guide https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide Secure Computing Magazine http://www.scmagazine.com Etudes Verizon 2013 et Qualys 2010 Stay curious ! MERCI POUR VOTRE ATTENTION !