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 secure coding• Conclusion / Ressources

INTRODUCTIONPour commencer..

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 contexteEtude 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)

Firewall

TLS

OS renforcé

Serveur Web renforcé

Conterner Java

Firewall

Base

de

donn

ées

Infra

stru

ctur

e IT

Web

Ser

vice

sRé

perto

ires /

fich

iers

SIRH

/ CR

M /E

RPCo

mpt

a bi

lité

WebApp métier dévelppée sur mesure

ATTAQUE APPLICATION

Couc

he ré

seau

Couc

he A

pplic

ativ

e Le code de votre application est le

maillon faible

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)

SECURITÉ DES WEBAPPUne branche de la sécurité informatique

Une nouvelle aire

Age des antivirus• 8090

Age de la sécurité réseau• 902000

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 GARTNER 200375% des attaques ciblent le niveau Applicatif66% des applications web sont vulnérables

Application Web

Eléments Réseaux

Etude du SANS (septembre 2011)http://www.sans.org/top-cyber-security-risks/

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’OWASP KESAKO ?L’Open Web Application Security Project

L’OWASPOpen 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-InjectionUne 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

Sessiones 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.

• ExempleJournaux 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

fonctionnelPratiquement 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

SolutionsVotre 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

connuesLes 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.

• Exemplehttp://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…

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• 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();}

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 clonablepublic final void clone() throws java.lang.CloneNotSupportedException { throw new java.lang.CloneNotSupportedException();}

• Eviter que qqun surcharge la méthode clone() d’un objet sensible

public final void clone() throws java.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é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

CONCLUSIONVous êtes bientôt libre…

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 Magazinehttp://www.scmagazine.com

• Etudes Verizon 2013 et Qualys 2010

• Stay curious !

MERCI POUR VOTRE ATTENTION !