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)
Firew
all
TLS
OS renforcé
Serveur Web renforcé
Conterner Java
Firew
all
Base
de
donn
ées
Infr
ast
ruct
ure
IT
Web
Serv
ices
Rép
ert
oir
es
/ fi
chie
rs
SIR
H /
CR
M /
ER
P
Com
pta
bili
té
WebApp métier dévelppée sur mesure
ATTAQUE APPLICATION
Couch
e r
ése
au
Couch
e A
pplic
ati
ve 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 2003
75% 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’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
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 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
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 Javahttp://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 !