1

UN PEU DE SÉCURITÉ DANS CE MONDE DE KIWILaurie-Anne Bourdain

Kiwi Party 2014

2

LA SÉCURITÉ RÉPONDS AUX RISQUES

Confidentialité

Intégrité

Disponi-

bilité

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

4

LES BASES DE LAGESTION DE RISQUES

5

UN CYCLE SANS FIN

Gestion de Risque

Analyse

RéponseÉvaluation

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

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.

8

LA RÉPONSE… N’EST PAS 42

Mitiger

Eliminer

Transférer Accepte

r

Risque

9

NE PAS TROP EN FAIRE

0 10 20 30 40 50 60 70 80 90 1000

10

20

30

40

50

60

Coûtdes risques

Coût des mesures de mitigation de risques

Équilibre

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

11

ÉVALUER LES RISQUESImpact

Faible Moyen Grave Catastrophique

Probabilité

Élevé

Moyenne

Faible

Très faible

12

ON THE WEB AGAIN

13

OWASP TOP 10OWASP 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

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.

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

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.

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 !

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

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)

20

QUESTIONS ?