1. UN PEU DE SÉCURITÉ DANS CE
MONDE DE KIWI
Laurie-Anne Bourdain
Kiwi Party 2014
1

2. LA SÉCURITÉ RÉPONDS AUX RISQUES
Confidentialité
Intégrité
Disponi-
bilité
2

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. LES BASES DE LA
GESTION DE RISQUES
4

5. UN CYCLE SANS FIN
Gestion
de
Risque
Analyse
RéponseÉvaluation
5

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. 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. LA RÉPONSE… N’EST PAS 42
Mitiger Eliminer
Transférer Accepter
Risque
8

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. É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. ÉVALUER LES RISQUES
Impact
Faible Moyen Grave Catastrophique
Probabilité
Élevé
Moyenne
Faible
Très
faible
11

12. ON THE WEB AGAIN
12

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