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

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

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

4. Introduction

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

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

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

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

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

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

11. L’intégration de la
sécurité

12. 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)

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

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

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

16. Vulnérabilités des
applications Web

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

18. 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‘

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

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

21. XSS - Reflected
Le code malveillant de l’attaquant est intégré sans contrôle, dans la
page web par le serveur

22. XSS - Permanent
Le code malveillant de l’attaquant est stocké dans un backend puis
retourné par le serveur dans la page web

23. XSS - Permanent

24. 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)

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

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

27. 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é

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

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

30. Démonstration

31. 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)

32. Conclusion

33. 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 ;-)

34. Conclusion
Questions, Commentaires, Sujets de discussions ?
Twitter : @Darkmira1
Facebook : darkmira
Linkedin : darkmira