Sécurisation des applications web

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

Agenda • Introduction • 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 securecoding • 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 TreeInternationnal • 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 lesentreprises. » 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 maillonfaible WebApp métier dévelppéesurmesure Couche Applicative Base de données Infrastructure IT Web Services Répertoires / fichiers SIRH / CRM /ERP Comptabilité ATTAQUE APPLICATION TLS Conterner Java Serveur Web renforcé OS renforcé Coucheré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

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

% Attaques % Dépenses 75 % 10 % 90 % 25 % Etude du SANS (septembre 2011) http://www.sans.org/top-cyber-security-risks/ Faiblesses des applications Web 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 WifeAcceptance 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 (CheatSheets) • 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 preparedStatement • 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 += "<inpuAtname='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 RequestForgery) force le navigateur d'une victime authentifiée à envoyer une requête HTTP forgée. • Exemple • <imgsrc="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 utilisateurmais 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 (CheatSheets) • 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

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

Les principes de securecoding • 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

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 OutputStreamrawOut = 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() throwsjava.lang.CloneNotSupportedException { throw new java.lang.CloneNotSupportedException(); } • Eviter que qqun surcharge la méthode clone() d’un objet sensible public final void clone() throwsjava.lang.CloneNotSupportedException { 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écurecoding

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 ( CheatSheet ) 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 securecoding • 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

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 Qualys2010 • Stay curious ! MERCI POUR VOTRE ATTENTION !

Sécurisation des applications web