1

S

Développement d’applications web

Initiation à la sécurité

2

Problématique / Enjeux

Système constamment soumis à des tentatives d’attaques

Protection du système

Protection des données personnelles des utilisateurs

Protection des données de notre application

3

Attaque sur le système

Attaques les plus graves

Mettent en jeu L’intégrité du système L’intégrité de toutes les données stockées sur le

système

4

Type d’attaques les plus courantes

Attaque sur le serveur web

Attaque sur d’autres services SSH FTP …

=> Exécution de code arbitraire en tant qu’un certain utilisateur

5

Éléments de protection

Exécuter les serveurs web et ftp sous des utilisateurs n’ayant accès qu’aux fichiers qu’ils doivent servir

Sécuriser les connexions SSH Privilégier la connexion par clé public/privé Utiliser des utilitaires bannissant les personnes

tentant de se connecter trop de fois sans succès (failtoban, iptoban, …)

Possibilité de n’accepter les connexions que de certaines IP/plages d’IP

6

Prévention et détection

Mettre à jour régulièrement les programmes installés Bugfixes Security issues

Se tenir au courant des failles potentielles existantes Les failles connues sont souvent listées sur les sites

dédiés

Consulter les logs ou utiliser un utilitaire le faisant pour détecter les tentatives d’exploitation de certaines failles

7

Attaques sur des applications web

Attaques cherchant à: Exécuter une requête arbitraire en base de donnée Insérer un code javascript dans une page Détourner des sécurités pour accéder à des parties

sécurisées d’une application …

8

Importance

Moins d’impact qu’une attaque sur le système

A peu de risque de nuire à l’intégrité du système entier

Peut cependant: Accéder à des données confidentielles Accéder à des parties d’administration Éviter un paiement Récupérer des données personnelles d’utilisateurs Effacer des données …

9

Comment s’en protéger ?

Cela dépend du type d’attaque

Se tenir informer des dernières attaques effectués sur les applications que nous utilisons

Surveiller les logs

10

SQL injection

Principe: Exécuter une requête arbitraire en base de données

Réalisation: Utilisation d’un défaut de sécurité lors de l’insertion d’un

élément en base de donné (un commentaire par exemple) pour exécuter la requête voulu

Risques: Récupération des données utilisateur Connexion en tant que n’importe que utilisateur …

11

Exemple

<?phpmysql_query(“SELECT id FROM users WHERE name= ’“.$login. “ ‘ AND password=‘ “ .$password. “ ‘;“);?>

SELECT id FROM users WHERE name= ’dupont‘ AND password=‘ dupontpasswd ‘;

SELECT id FROM users WHERE name= ’dupont ‘ -- ‘ AND password=‘ ‘;

12

Comment s’en protéger ?

Il faut échapper tous les caractères spéciaux avant de les insérer dans une requête Des fonctions existent pour le faire Se renseigner pour savoir si ce que l’on utilise nous protège

Utiliser des requêtes SQL paramétrées

Vérifier l’ensemble des informations fournies par l’utilisateur

…

13

XSS

XSS= cross site scripting

Principe: Exécution d’un script (javascript, flash, java, …) dans le navigateur des

clients

Réalisation: Détourne l’utilisation de l’ajout de commentaire, d’un module de recherche

ou autre pour insérer un script arbitraire dans une page

Risques: Vol de cookie/session des utilisateurs Récupération de données personnelles des utilisateurs Infection des machines des utilisateurs par un code malin

14

Exemple

Quelqu’un ajoute sur notre blog un commentaire contenant:<Script language=“javascript“>…</script>

Lors de l’affichage du commentaire, le script javascript sera exécuter par le navigateur ayant chargé la page.

N’importe quel autre type de script client aurait pu être inséré (java, flash, etc.)

15

Solution

Toujours encoder les caractères utilisés dans les balises html avant d’affiché un texte fourni par un utilisateur. Ceci se fait via l’utilisation de fonctions spécifique

dans la plupart des langages Vérifier que les bibliothèques, modules, framework

que vous utilisez mettent en place des sécurités contre ces attaques

16

Modification de cookie

Qu’est-ce qu’un cookie ? Un fichier stockant des données pour un site web Ce fichier est renvoyé à chaque requête Il peut contenir n’importe quel type d’information

17

Modification de cookie

Principe: Modifier les informations contenu dans un cookie pour

obtenir plus de droit ou éviter une sécurité ou un paiement

Réalisation: Le cookie est un fichier texte s’il n’a pas été encodé, il suffit

donc de l’éditer

Risques: Le pirate peut obtenir le rôle d’administrateur ou éviter

certaines sécurités (vérification de paiement, etc.)

18

Solution

Première solution: Crypter le cookie

Quelqu’un sera toujours capable de trouver comment décrypter et pourra modifier les informations

Deuxième solution: Fournir dans le cookie une clé d’identification

Les informations de session sont conservés sur le serveur La clé permet de dire au serveur quelles informations

regarder

19

url jumping

Principe: Rentrer l’url d’une page dans la barre d’adresse sans

suivre la progression imposée par le site

Réalisation: Taper l’adresse dans la barre d’adresse de son

navigateur

Risque: Éviter un paiement ou une procédure

d’authentification

20

Exemple

Une personne accède à l’url: Monsite.com/administration/adminpanel.php

Si cette page ne vérifie pas que la personne est bien authentifiée, elle pourra avoir accès à cette page sans même s’être connectée.

21

Autre exemple

Dans une procédure d’achat en ligne: La personne est à la page:

Monsite/achat/step3.php Elle rentre directement l’adresse

Monsite/achat/step5.php Si aucune vérification n’est faite, elle est peut-être

passée de l’étape de paiement à l’étape de validation et d’envoie sans avoir payé.

22

Solution

Chaque page faisant partie d’une zone sécurisée ou d’une chaîne d’action est responsable de vérifier: Que la personne accédant à la page est bien

authentifiée Que la personne accédant à la page a bien suivi

toute la chaîne d’action

Attention, le stockage d’information directement dans le cookie n’est pas sûr (comme vu précédemment), une combinaison d’attaques reste possible

23

Déni de service

Principe: Rendre inaccessible l’application

Réalisation: Requêtes multiples, boucle « infini », …

But: Rendre le site ou le service inaccessible

24

Exemple

Grand nombre de requêtes envoyées sur l’application

Remplissage de la mémoire:

…

String TotalObjects = request.getParameter(“numberofobjects”);int NumOfObjects = Integer.parseInt(TotalObjects);ComplexObject[] anArray = new ComplexObject[NumOfObjects];

25

Solution

Limiter le nombre de requête provenant d’une même source

Ne pas utiliser de données fournies par l’utilisateur pour des boucles ou des allocations sans mettre des limites

…

26

Bonnes pratiques

Ne jamais croire une information entrée par un utilisateur Formulaire, paramètre url, etc.

Toujours vérifier les informations passées d’une page à l’autre Si une information est passée chez l’utilisateur, il

faut supposer qu’elle a pu être altéré et la vérifier avant de l’utiliser

…

27

Plus d’informations ?

www.owasp.org Open Web Application Security Project