Durcissement de code - Sécurité Applicative Web
-
Upload
cyrille-grandval -
Category
Presentations & Public Speaking
-
view
421 -
download
1
description
Transcript of Durcissement de code - Sécurité Applicative Web
Pourquoi durcir son code?Quand le faire?
Comment s’y prendre?
12.06.20141er WebDay ESGI
Paris
Cyrille GrandvalConsultant Sécurité Applicative
Maxence Perrin Développeur PHP Sécurisé
Durcissement de code
Qui sommes nous?
Cyrille GrandvalDirecteur général
Consultant sécurité Applicative
[email protected]@CyrilleGrandval linkedin.com/in/cyrillegrandval
Maxence PerrinDéveloppeur PHP
sécurisé
[email protected] @Maxence_Perrin
Darkmira
Développement PHP sécurisé
Confiance – Elitisme – Qualité
Développement d’applications pérennes, fiables et sécurisées
Industrialisation du développement• Bonnes pratiques• Méthodes de type Agiles• Frameworks Symfony et Zend
www.darkmira.fr
Introduction
Quelques faitsPourquoi durcir son code?
2011 : Piratage du Playstation Network, 77 millions de comptes volés
Juin 2014 : Piratage du système “Pay by Phone” à Nice pour le paiement des places de Parking
Avril 2014 : Vol d’une partie des RIB des abonnés de MediaPart
Février 2014 : Piratage des données personnelles des clients d’Orange, 800 000 comptes volés
Janvier 2014 : vol de 4,6 millions de pseudos et numéros de téléphone de Snapchat
Mars 2013 : 50 millions de mots de passes volés chez Evernote
Avril 2014 : HeartBleed Faille de sécurité découverte dans OpenSSL qui affectent ⅔ des sites internet
Avril 2014 : Piratage des données personnelles des clients d’Orange, 1,3 millions de comptes volés
Risques et impacts d’une attaque
Piratage
Vol de données Altération de données Indisponibilité de l’application
Vol de propriété intellectuelle
Perte d’image
Perte de confiance / crédibilité
Perte financière Responsabilité pénale / civile
DEPOT DE BILAN
RISQ
UES
IMPA
CTS
Un très grand % de business sont basés sur une application Web
Constat
design dev test prod
Coût
PROACTIF REACTIF
Application web
Réseau système
% attaques
SourceGartner
%budget
75%
25%
10%
90%
Evolution des attaques• Basé sur les CVE http://cve.mitre.org/cve/
• Baisse de moitié du nombre de vulnérabilités jusqu’à 2011
• Augmentation jusqu’au niveau de 2009 à partir de 2012
• 90% des failles ont une sévérité de moyenne à élevée
• Baisse significative des failles de sévérité élevée jusqu’à 2011 et stagnation
Evolution des attaques mobiles
2012 2013
99 96
Applications testées vulnérables
%
2012 2013
13 14
Vulnérabilités moyennes par application
Source : Cenzic - Application Vulnerability Trends Report : 2014
Contexte juridique
Un accroissement des responsabilités des dirigeants face à la sécurité des informations numériques• + de protection des données• + de traçabilité• Nul n’est censé ignorer la loi• Sensibilisation du personnel interne / externe• Mettre l’entreprise en conformité avec la législation
Engagement de la responsabilité civile et / ou pénale• Directive européenne : jusqu’à 5 ans d’emprisonnement et 300 000 euros d’amendes
L’intégration de la sécurité
Présentation de l’OWASP
OWASP : Open Web Application Security Project - Organisation mondiale à but non lucratif http://www.owasp.org
Son rôle : sensibiliser à la sécurité applicative pour aider à prendre les bonnes décisions en matière de sécurité des applications
Evènements et présence :
• Des conférences à travers le monde• Des listes de diffusion spécifiques• Des chapitres locaux
Liste des projets de l’OWASP : https://www.owasp.org/index.php/Category:OWASP_Project
Des matériels :
• 50% de documentations (Top10, Cheats Sheets, Normes, Guides, …)• 40% d’outils (Samy, ZAP)• 10% de code (Librairies)
Cycle de vie de l’application
Intégrer les préoccupations de sécurité dès le début du cycle et non à la fin
Définition des besoins
Détermination des besoins sécurité
Revue de code sécurité
Tests de sécurité
Sécurité du déploiement
Audit de sécurité
Cycle de vie de développement
Cycle de vie de sécurité
Architecture et conception
Développement Test Déploiement Maintenance
Revue sécurité de conception
Processus de contrôle de la sécurité d’une application web en 4 niveaux :
• Niveau 0 (Superficiel) : critères minimums de vérification définie par chaque société• Niveau 1 (Opportuniste) : protège contre les failles faciles à découvrir • Niveau 2 (Standard) : défend contre les failles courantes avec un risque de modéré à sérieux • Niveau 3 (Avancé) : défend contre les failles avancées et démontre de bonnes pratiques de conception sécurisé
Source : OWASP ASVS 2013 bêta - https://docs.google.com/document/d/1B5Ho1iapIEIgxdyua_A7TxwyrY-ts7qUz9NEdxj8tZ4/edit
OWASP : Standard de Vérification de la Sécurité des Applications (2013)
Qualifier l’application avec l’ASVS
Qualifier l’application avec l’ASVS
L’ASVS définit 13 groupes d’exigences de vérification et des points de vérification par groupes pour un ou plusieurs niveaux.
Vulnérabilités des applications Web
Top 10 des attaques les plus répandues
A1 - Injections
A10 – Redirections et
renvois non validés
A4 - Références directes non
sécurisées à un objet
A7 – Manque de contrôle d’accès
au niveau fonctionnel
A2 - Violation de Gestion
d'Authentification et de Session
A5 – Mauvaise configuration
Sécurité
A3 - Cross-Site Scripting (XSS)
A6 – Exposition de données
sensibles
A8 - Falsification de requête
intersite (CSRF)
A9 - Utilisation de composants avec des vulnérabilités
connues
Owasp Top 10 – 2013
• Liste des attaques les plus répandues par catégorie• Explication, exemples d’exploitations et contremesures• Document mis à jour tous les 3 ans
Objectifs :1/ Sensibiliser les acteurs du SI2/ Fournir des techniques de bases pour se protéger
Injection SQL
Définition
• Injection de code SQL• Altération de la requête d’origine
Requête d’origine
SELECT * FROM user WHERE login = ‘“ . $_POST[‘login’] . “‘ AND password = ‘“ . $_POST[‘password’] . “‘
Injection : ‘OR ‘1’ = ‘1
SELECT * FROM user WHERE login = ‘‘ OR ‘1’ = ‘1’ AND password = ‘‘ OR ‘1’ = ‘1‘
Injection SQL
• Faille toujours d’actualité
• S’en prémunirNe pas afficher vos messages d’erreursRequête préparée, Procédure stockée
• Démonstration fin de séance
DéfinitionInsertion de code malveillant (Javascript, VBScript, …) dans application WebScript interprété côté client
Action possible :Vol de cookie de session mais pas que…
Trois types d’attaque• Reflected• Permanent• DOM-based
XSS
XSS - Reflected
Le code malveillant de l’attaquant est intégré sans contrôle, dans la page web par le serveur
XSS - Permanent
Le code malveillant de l’attaquant est stocké dans un backend puis retourné par le serveur dans la page web
XSS - Permanent
XSS – DOM based
Le code malveillant de l’attaquant est intégr dans les données é:générées directement par le navigateur (côté client)
Contre-mesures
• Valider les données d’entrée• Encoder les données de sortie
Quelques outils
• OWASP ESAPI Project (https://www.owasp.org/index.php/ESAPI)• OWASP AntiSamy Project (https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project)• Librairies et bibliothèques par technologies
XSS
Chiffrez vos données
Crypter : une arme de guerre
• Jusqu’en 1996 (128 bits)• 2004 : Loi pour la confiance dans l’économie numérique
Crypter n’est pas hasher
Hashage salt statique / salt dynamique
N’oubliez pas les utilisateurs• Impliquez l’utilisateur dans la sécurité• Conception sécurisée
CSRF
Définition
Faire réaliser des actions à l’insu des utilisateurs
Mise en œuvre
• Utilisateur A est administrateur d’un site voyage et est connecté dessus• Grâce à un phishing, il se connecte sur le site de l’attaquant• Ce site comprend une image dont l’url est la page de modification d’un des voyages• Le navigateur de l’Utilisateur A charge l’url de l’image et donc la page de modification du voyage à son insu• L’utilisateur A ayant une session active sur son site, le prix du voyage est modifié
CSRF Exploitation
Balise IMG invisible (GET) <img src=http://myvoyage.com/voyage.php?id=78&action=modify&amount=10 width=”1” height=“1” />
Formulaire (POST)
<form name=“form” method=“post” action=“http://myvoyage.com/voyage.php“> <input type=“hidden” name=“id” value=“78”> <input type=“hidden” name=“action” value=“modify”> <input type=“hidden” name=“amount” value=“10”></form><script>document.form.submit()</script>
CSRF
Contrer cette attaque
• Jeton unique passé sur chaque action (formulaire, url)• Jeton limité dans le temps• Session limité dans le temps• Forcer une nouvelle authentification avant toute action critique• CAPTCHA• Vérifier le referer
Quelques outils
• OWASP CSRF Guard Project (https://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project)• OWASP CSRF Tester Project (https://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project)
Une attaque en cache une autre
Démonstration
Démonstration
Exemples d'une attaque SQL Injection
• Code en PHP
• Base de données MySQL
• Site de voyage minimaliste-Liste des voyages-Information sur un voyage-Mon compte
• Déroulement de l’attaque-Prise d’empreinte-Exploitation basique-Utilisation de l’outil sqlmap (http://sqlmap.org)
Conclusion
Conclusion
Pourquoi ne pas durcir le code (Les mythes) ?
1/ Ma société n’a pas d’informations sensibles2/ Mon application est interne à mon entreprise3/ Mon application est derrière un firewall et / ou utilise HTTPS4/ Mes développeurs réalisent des applications sécurisées5/ Les attaques Web ne sont exploitées que part une élite de hackers
Si vous avez compris l’ironie de cette conclusion,vous êtes sur la bonne voie
Continuez ;-)
Conclusion
Questions, Commentaires, Sujets de discussions ?
Twitter : @Darkmira1Facebook : darkmiraLinkedin : darkmira