Durcissement de code - Sécurité Applicative Web
Upcoming SlideShare
Loading in...5
×
 

Durcissement de code - Sécurité Applicative Web

on

  • 340 views

Durcissement de code - Pourquoi durcir son code ? Quand le faire ? Comment s’y prendre ? ...

Durcissement de code - Pourquoi durcir son code ? Quand le faire ? Comment s’y prendre ?

Cyrille Grandval & Maxence Perrin répondent à ces problématiques que se posent de nombreux acteurs du Web lors de la conférence d'ouverture de la 1ère édition du WebDay ESGI.

Statistics

Views

Total Views
340
Slideshare-icon Views on SlideShare
308
Embed Views
32

Actions

Likes
1
Downloads
7
Comments
0

3 Embeds 32

http://www.scoop.it 28
http://www.slideee.com 3
https://www.linkedin.com 1

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Durcissement de code - Sécurité Applicative Web Durcissement de code - Sécurité Applicative Web Presentation Transcript

    • Pourquoi durcir son code? Quand le faire? Comment s’y prendre? 12.06.2014 1er WebDay ESGI Paris Cyrille Grandval Consultant Sécurité Applicative Maxence Perrin Développeur PHP Sécurisé Durcissement de code
    • Qui sommes nous? Cyrille Grandval Directeur général Consultant sécurité Applicative cgrandval@darkmira.fr @CyrilleGrandval linkedin.com/in/cyrillegrandval Maxence Perrin Développeur PHP sécurisé mperrin@darkmira.fr @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 faits Pourquoi 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 RISQUESIMPACTS
    • 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 Source Gartner % 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 SI 2/ 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émunir Ne pas afficher vos messages d’erreurs Requête préparée, Procédure stockée • Démonstration fin de séance
    • Définition Insertion de code malveillant (Javascript, VBScript, …) dans application Web Script 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 sensibles 2/ Mon application est interne à mon entreprise 3/ Mon application est derrière un firewall et / ou utilise HTTPS 4/ Mes développeurs réalisent des applications sécurisées 5/ 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 : @Darkmira1 Facebook : darkmira Linkedin : darkmira