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

cgrandval@darkmira.fr@CyrilleGrandval linkedin.com/in/cyrillegrandval

Maxence PerrinDé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 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