UN PEU DE SÉCURITÉ DANS CE
MONDE DE KIWI
Laurie-Anne Bourdain
Kiwi Party 2014
1
LA SÉCURITÉ RÉPONDS AUX RISQUES
Confidentialité
Intégrité
Disponi-
bilité
2
QU’EST-CE QUE JE VOUS SERT?
Gestion de Risque
• Analyse
• Réponse
• Évaluation
On the Web again
• Les Menaces de l’Interne...
LES BASES DE LA
GESTION DE RISQUES
4
UN CYCLE SANS FIN
Gestion
de
Risque
Analyse
RéponseÉvaluation
5
S.T.R.I.D.E. (PROGRÈS)
• Se faire passer pour quelqu’un ou quelque chose que l’on n’est
pas.
• Peut être utilisé pour modi...
IDENTIFIER SES RISQUES
Tous les sites ne sont pas exposés aux mêmes
risques, mais il y a de grandes tendances (voir
OWASP ...
LA RÉPONSE… N’EST PAS 42
Mitiger Eliminer
Transférer Accepter
Risque
8
NE PAS TROP EN FAIRE
0
10
20
30
40
50
60
0 20 40 60 80 100
Coût
des risques
Coût des mesures
de mitigation de
risques
Équi...
ÉVALUER LES RISQUES
Pour évaluer les risques on utiliser généralement la
formule suivante:
PPA = PPI * FA
Ou:
PPA : Prévis...
ÉVALUER LES RISQUES
Impact
Faible Moyen Grave Catastrophique
Probabilité
Élevé
Moyenne
Faible
Très
faible
11
ON THE WEB AGAIN
12
OWASP TOP 10
OWASP Top 10 2013
A1 Injection
A2 Broken Authentication & Session Management
A3 Cross-Site Scripting (XSS)
A4...
LES UTILISATEURS
 Identification, authentification et autorisation:
Identifier: demander qui est l’utilisateur
Authentifi...
LES UTILISATEURS, BIS
 Injections SQL:
Vérifier le type de données si possible;
Échapper les caractères spéciaux
(mysqli_...
LE DÉVELOPPEUR
 Porte Dérobées (Backdoor) / Porte de Debug
Porte Dérobée = Pas Bien
Porte de Debug = Pas Bien en Producti...
LE DÉVELOPPEUR, BIS
 Version et Documentation
Versionner son code permet de repartir sur une base
saine lors de développe...
L’HÉBERGEMENT
 Backup
Vérifiez quelle est la politique de backup de votre
hébergeur.
Comparez la à vos besoins.
Si nécess...
LES AUTRES
 Il existe des attaques contre lesquelles, on ne peux
rien faire. Sauf éduquer les utilisateurs et signaler
le...
QUESTIONS ?
20
Prochain SlideShare
Chargement dans…5
×

Un peu de sécurité dans ce monde de Kiwi

1 460 vues

Publié le

Présentation donnée pendant la Kiwi Party 2014

Rapide introduction des menaces pour les sites web.

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 460
Sur SlideShare
0
Issues des intégrations
0
Intégrations
9
Actions
Partages
0
Téléchargements
8
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Un peu de sécurité dans ce monde de Kiwi

  1. 1. UN PEU DE SÉCURITÉ DANS CE MONDE DE KIWI Laurie-Anne Bourdain Kiwi Party 2014 1
  2. 2. LA SÉCURITÉ RÉPONDS AUX RISQUES Confidentialité Intégrité Disponi- bilité 2
  3. 3. QU’EST-CE QUE JE VOUS SERT? Gestion de Risque • Analyse • Réponse • Évaluation On the Web again • Les Menaces de l’Internet • Comment les Mitiger • Quelques bonnes pratiques Questions 3
  4. 4. LES BASES DE LA GESTION DE RISQUES 4
  5. 5. UN CYCLE SANS FIN Gestion de Risque Analyse RéponseÉvaluation 5
  6. 6. S.T.R.I.D.E. (PROGRÈS) • Se faire passer pour quelqu’un ou quelque chose que l’on n’est pas. • Peut être utilisé pour modifier des données, un DoS… Spoofing • Modifier quelque chose sans en avoir le droit. • Le « defacing » en est l’exemple le plus visible.Tampering • Rejet de Responsabilité. • Affirmer ne pas avoir fait quelque chose (vrai ou pas). • Sert généralement à camoufler un « spoofing » ou « tampering ». Repudiation • Accéder à et publier des informations (généralement sensibles ou confidentielles). • Le cas Snowden est un bon exemple. Information Disclosure • Attaque qui a pour but d’empêcher les utilisateurs légitimes d’utiliser un service. • En le crashant, le ralentissant ou en saturant sa mémoire. Denial of Service • (Se) donner plus d’accès à un système. • Peut permettre un « tampering » ou « information disclosure » Elevation of Privilege 6
  7. 7. IDENTIFIER SES RISQUES Tous les sites ne sont pas exposés aux mêmes risques, mais il y a de grandes tendances (voir OWASP Top 10). Les questions à se poser:  Qu’est-ce qui peut valoir le coup d’attaquer mon site?  Quelle est ma visibilité?  Est-ce que des concurrents (ou moi-même) ont subit des attaques?  Quelles sont mes périodes critiques (fin de mois/d’année, release d’un super produit, grande annonce…)? Ne pas négliger ce qui semble improbable. 7
  8. 8. LA RÉPONSE… N’EST PAS 42 Mitiger Eliminer Transférer Accepter Risque 8
  9. 9. NE PAS TROP EN FAIRE 0 10 20 30 40 50 60 0 20 40 60 80 100 Coût des risques Coût des mesures de mitigation de risques Équilibre 9
  10. 10. ÉVALUER LES RISQUES Pour évaluer les risques on utiliser généralement la formule suivante: PPA = PPI * FA Ou: PPA : Prévision de Perte Annuelle PPI : Prévision de Perte Isolée FA : Fréquence Annuelle 10
  11. 11. ÉVALUER LES RISQUES Impact Faible Moyen Grave Catastrophique Probabilité Élevé Moyenne Faible Très faible 11
  12. 12. ON THE WEB AGAIN 12
  13. 13. OWASP TOP 10 OWASP Top 10 2013 A1 Injection A2 Broken Authentication & Session Management A3 Cross-Site Scripting (XSS) A4 Insecure Direct Object References A5 Security Misconfiguration A6 Sensitive Data Exposure A7 Missing Function Level Access Control A8 Cross-Site Request Forgery (CSRF) A9 Using Unknown Vulnerable Components A10 Unvalidated Redirects and Forwards 13 Plus d’info: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
  14. 14. LES UTILISATEURS  Identification, authentification et autorisation: Identifier: demander qui est l’utilisateur Authentifier: vérifier qui est l’utilisateur Autoriser: donner des accès à l’utilisateur L’authentification et les autorisations de l’utilisateur doivent être vérifiée pour chacune de ses actions. Les autorisations doivent être données selon les principes du « least privilege » et du « Need-to-Know »  Non-repudiation: Être capable d’identifier l’auteur des problèmes. Toutes les actions utilisateurs doivent être loguées. Ces logs doivent être protégés en écriture. 14
  15. 15. LES UTILISATEURS, BIS  Injections SQL: Vérifier le type de données si possible; Échapper les caractères spéciaux (mysqli_real_escape_string()); Utiliser des requêtes pré-formatées:  $stmt = $dbh->prepare("SELECT * FROM users WHERE USERNAME = ? AND PASSWORD = ?"); $stmt- >execute(array($username, $password));  La requête pré-formatée n’accepte que les données attendues et est plus rapide (quand il y a plusieurs requêtes identiques à exécuter). 15
  16. 16. LE DÉVELOPPEUR  Porte Dérobées (Backdoor) / Porte de Debug Porte Dérobée = Pas Bien Porte de Debug = Pas Bien en Production Les portes dérobées sont des moyens d’entrée non documentés, sans mot de passe et/ou contournant les mesures de sécurité d’une application. Les portes de debug sont la même chose, mais leur but est d’offrir, lors du développement, des accès facile pour tester les fonctionnalités d’une application. Elles doivent toujours être supprimées avant de déployer en production. L’utilisateur « admin » (mdp = admin) est une backdoor. 16
  17. 17. LE DÉVELOPPEUR, BIS  Version et Documentation Versionner son code permet de repartir sur une base saine lors de développements futurs. Éviter les développement à La RACHE©®™  Patcher Toujours utiliser les dernières versions de Biblio, API… Patchez également vos softwares et serveurs.  Testez, Testez, Testez ! 17
  18. 18. L’HÉBERGEMENT  Backup Vérifiez quelle est la politique de backup de votre hébergeur. Comparez la à vos besoins. Si nécessaire, faites les backups vous-même  Politique de destruction du matériel Savez-vous ce qu’il advient des disques qui ont hébergé vos données lorsqu’ils sont en fin de vie?  DoS Dans la plupart des cas, les attaques DoS seront gérées par votre hébergeur et son ISP.  Continuité Si la continuité est critique pour votre activité, prévoyez un plan de secours (autre hébergeur). 18
  19. 19. LES AUTRES  Il existe des attaques contre lesquelles, on ne peux rien faire. Sauf éduquer les utilisateurs et signaler les attaques en cours. Phishing Dangling Pointer (Lien moisi) 19
  20. 20. QUESTIONS ? 20

×