Securité web

62
Securité Web Les failles les plus courantes

description

Support de conférence du 7 février 2013 à Supinfo Nantes

Transcript of Securité web

Page 1: Securité web

Securité Web

Les failles les plus courantes

Page 2: Securité web

Quelques questions

• Quelles menaces pour la sécurité de mon site et des données de mes utilisateurs ?

• Comment les pirates arrivent-ils à exploiter ces failles ?

• Que faire pour y remédier ?• Quelques bonne pratiques à adopter ?

Page 3: Securité web

Sommaire

1. Faille XSS2. Injection SQL3. Attaque des mots de passe par brute force4. Faille include5. Quelques bonnes pratiques

Page 4: Securité web

Faille XSS

Page 5: Securité web

1.Faille XSS

• Le Cross Site Scripting (XSS) permet l’injection de code malveillant côté client

• Souvent des codes Javascript, Java ou Flash

a. Qu’est ce que c’est ?

Page 6: Securité web

b. Comment ça marche ?

• Souvent, le code va s’exécuter sur les pages des visiteurs du site

• Le script de l’attaquant va avoir accès au DOM• Il peut faire n’importe quel action à l’insu de

l’utilisateur

1.Faille XSS

Page 7: Securité web

• Exemple :

1.Faille XSS

b. Comment ça marche ?

Page 8: Securité web

Exemple :

1.Faille XSS

b. Comment ça marche ?

Page 9: Securité web

Maintenant, tentons de comprendre ce qui c’est passé !Le pirate à entrer le code suivant dans le commentaire :

1.Faille XSS

b. Comment ça marche ?

Ce même code a été ensuite affiché sur la page html or on se rend bien compte que c’est du code qui a été affiché dans le navigateur. Le navigateur a donc exécuté ce qui était dans entre les balise script normalement et affiché le message voulu par le pirate.

Page 10: Securité web

c. Quel est le danger ?

• Vols d’informations• Utilisation d’un site piraté pour faire circuler un virus

(virus Samy sur MySpace en 2005)• Phishing• Défacement• Redirection vers un autre site (pouvant servir à voler

des informations par la même occasion)

1.Faille XSS

Page 11: Securité web

d. Comment l’éviter ?

Pour l’éviter deux possibilités :• Faire des filtres• Remplacer certains caractères html par leur entité

html correspondante

1.Faille XSS

Page 12: Securité web

On pourrait faire une fonction qui filtre la balise <script>.La fonction ci-dessous va enlever tout les « script ».

1.Faille XSS

d. Comment l’éviter ?

Page 13: Securité web

Problèmes : • Ce filtre est facilement contournable. En effet, au lieu

de mettre <script></script> mettons <scscript></scrscriptipt> et lorsque le filtre enlevera les « script » il restera <script></script>

• Si on veut mettre le mot script dans un message il sera effacer du message.

1.Faille XSS

d. Comment l’éviter ?

Page 14: Securité web

d. Comment l’éviter ?

La fonction htmlspecialchars()

1.Faille XSS

La fonction htmlspecialchars permet de remplacer certains caractère html par leur entité correspondante :• '&' devient &amp;• '"' devient &quot;• "'" devient &#039;• '<‘ devient &lt;• '>‘ devient &gt;

Page 15: Securité web

d. Comment l’éviter ?

La fonction htmlentities()

1.Faille XSS

La fonction htmlentities a exactement la même utilité que la fonction htmlspecialchars sauf qu’elle remplace tout les caractères html existant par leur entité correspondante. Elle est donc plus complète.

Page 16: Securité web

d. Comment l’éviter ?

La fonction strip_tags()

1.Faille XSS

La fonction strip_tags() va supprimer tout les balises html, php

Page 17: Securité web

Démonstration

Page 18: Securité web

Questions

Page 19: Securité web

Injection sql

Page 20: Securité web

2. Injection sql

L’injection sql permet, comme son nom l’indique d’injecter une requête sql à l’insu du développeur

a. Qu’est ce que c’est ?

Page 21: Securité web

2. Injection sql

b. Comment ça marche ?

• Souvent, le code malveillant va être inséré dans des données transmis par formulaire et par des données dans les urls

• Le code de l’attaquant va pouvoir faire des requêtes à la base ou en fausser leur sortie

• Au préalable il pourra avoir soigneusement exploité le manque de sécurisation pour connaître le nom d’une ou de plusieurs table de la base.

Page 22: Securité web

2. Injection sql

b. Comment ça marche ?

Exemple :

Page 23: Securité web

2. Injection sql

b. Comment ça marche ?

Exemple :

Page 24: Securité web

2. Injection sql

b. Comment ça marche ?

Dans l’exemple précédent nous avons pris le cas d’une connexion classique. Pour bien comprendre ce qui c’est passé il est bon de voir quel type de requête est utilisé pour la connexion.

Maintenant remplaçons les variables par les données rentrée pas l’utilisateur, la requête devient alors :

Or le # signifie le début d’un commentaire en sql d’où la requête revient donc a :

La requête retourne toujours un resultat tant que le nom d’utilisateur ‘admin’ existe dans la base

Page 25: Securité web

2. Injection sql

c. Quel est le danger ?

• Vols d’informations• Changement des informations de la base• Délétion de données

Page 26: Securité web

2. Injection sql

d. Comment l’éviter ?

Pour l’éviter deux possibilités :• Échapper les caractères• Préparer les requêtes

Page 27: Securité web

2. Injection sql

d. Comment l’éviter ?

La fonction addslashes() :La fonction addslashes() permet de rajouter un antislash devant les ‘, ", /, byte NULL

Page 28: Securité web

2. Injection sql

d. Comment l’éviter ?

La fonction MySQLi:mysqli_real_escape_string() :La fonction mysqli_real_escape_string() permet de rajouter un antislash devant les ‘, ", /, byte NULL, \n, \r

Page 29: Securité web

Attention !

La fonction mysql_real_escape_string() sera devenu obsolète pour la version

5.5.0 de PHP et sera supprimée dans les futures version de PHP.

Page 30: Securité web

2. Injection sql

d. Comment l’éviter ?

La fonction PDO:quote() :La fonction PDO:quote() permet de rajouter un antislash devant tout les caractères spéciaux définis par le pilote ainsi qu’un « ’ » de chaque côté de la valeur de la variable,

Page 31: Securité web

2. Injection sql

d. Comment l’éviter ?

Préparer ses requêtes :La préparation des requêtes permet également de protéger nos requêtes. Néanmoins, il ne suffit pas juste de faire une requête préparé pour que note requête soit protégé. En effet, le code suivant ne permet absolument pas de protéger notre requête.

Page 32: Securité web

2. Injection sql

d. Comment l’éviter ?

Préparer ses requêtes :Voici deux façons de faire qui permettent de protéger les requêtes contre les injections.

En préparant juste :

Page 33: Securité web

2. Injection sql

d. Comment l’éviter ?

Préparer ses requêtes :

En passant les paramètres par la fonction PDOStatement:bindValue() (conseillé):

Page 34: Securité web

2. Injection sql

d. Comment l’éviter ?

Mais surtout bien vérifier les données :

Le plus important pour éviter de subir des injections est de vérifier les données rentrées. Cela comprend, de :• vérifier le type de la données (de le transtyper si besoin est)• Vérifier la longueur des données• Si le choix des données est restreint vérifier que les données sont la

fourchettes de solutions

Page 35: Securité web

Démonstration

Page 36: Securité web

Questions

Page 37: Securité web

Attaque par brute force

Page 38: Securité web

3. Brute force

a. Qu’est ce que c’est ?

Le principe d’une attaque par brute force des mots de passe est de tendre à une recherche exhaustive des mots de passe possible rentrer par l’utilisateur.Plusieurs variantes existent une recherche exhaustive en essayant tout les combinaisons de caractères possibles ou alors une autre variante consiste à se servir d’un dictionnaire pour rechercher les mots probables rentrés par l’utilisateur.

Page 39: Securité web

3. Brute force

b. Comment ça marche ?

Première variante, la recherche exhaustive des combinaisons de caractères possibles :

L’attaquant, qui a au préalable récupéré le pseudo d’un membre, teste tout les combinaisons de caractères possibles pouvant être rentrée en mot de passe. Au bout d’un moment le mot de passe rentrée est bon et l’attaquant à accès au compte.

Page 40: Securité web

3. Brute force

b. Comment ça marche ?

Deuxième variante, l’attaque par dictionnaire :

L’attaquant, qui a au préalable récupéré le pseudo d’un membre, teste tout les mots probables du dictionnaire d’une langue.

Page 41: Securité web

3. Brute force

b. Comment ça marche ?

Façon de faire :

Pour exécuter ces attaques il est évident que cela doit être un script qui doit exécuter les requêtes dans un but de rapidité. Ce script va donc envoyer des requêtes avec le même pseudo et différents mot de passe, puis, pour repérer l’échec d’authentification, va comparer le code source de la page lors de l’échec d’authentification et le code source de la page renvoyé pour chaque mot de passe. Lorsque le code source n’est pas le même alors, c’est qui n’y a pas d’erreur et donc que vous avez l’attaquant est connecté au compte.

Page 42: Securité web

3. Brute force

c. Quel est le danger ?

Le danger, c’est tout simplement le contrôle d’un compte (ou plusieurs si l’attaquant attaque plusieurs compte), le vol d’informations, modification des informations de l’utilisateurs, …., toute les actions que peut faire un utilisateurs. Il est également possible d’avoir plus d’accès dans le cas du contrôle d’un administrateur qui pourrait avoir accès au compte ftp.

Page 43: Securité web

3. Brute force

d. Comment l’éviter ?

Première méthode, la limitation d’essaies :

Une première méthode consiste à limiter le nombre d’essaies de mots de passe rentrée par l’utilisateur.

Page 44: Securité web

3. Brute force

d. Comment l’éviter ?

Deuxième méthode, le captcha :

Une deuxième méthode consiste à mettre un captcha pour s’identifier. Le script ne pourra donc pas déchiffrer le captcha et ne pourra jamais être authentifié.

Page 45: Securité web

3. Brute force

d. Comment l’éviter ?

Augmenter la sécurité des mots de passe :

Vous pouvez demander aux utilisateurs d’avoir un mot de passe comportant un certains nombre de caractères (au moins 6) avec des lettres, des chiffres, des caractères spéciaux et ne formant pas un mot. Ce n’est pas une mesure de sécurité absolu mais elle peut au moins endurcir la découverte des mots de passe par l’attaquant.

Page 46: Securité web

Questions

Page 47: Securité web

Faille include

Page 48: Securité web

4. Faille include

a. Qu’est ce que c’est ?

• L’exploitation d’une faille include permet d’accéder à n’importe quel page sur le serveur et plus selon les configurations de votre environnement PHP.

• Souvent le nom du fichier est demandé dans une url

Page 49: Securité web

4. Faille include

b. Comment ça marche ?

Nous allons travailler sur un cas classique de recherche où l’objet de la recherche est une page web inclue par un include. En voici le script que l’attaquant ne connait pas bien sûr.

Néanmoins, il est facile de le repérer à l’url :

Page 50: Securité web

4. Faille include

b. Comment ça marche ?

L’attaquant va donc remplacer « example1.php » par le fichier qu’il veut voir. Prenons par exemple le fichier .htaccess. L’url rentrée par l’attaquant va donc devenir :

Le script va donc inclure le fichier .htaccess et dans la suite logique des choses la page affiche le contenu de mon fichier .htaccess :

Page 51: Securité web

4. Faille include

c. Quel est le danger ?

Comme danger on pourrait citer celui d’avoir accès pour l’attaquant à des fichiers sensible tel que le .htaccess, .htpasswd et celui de pouvoir inclure et/ou exécuter des fichiers sensibles (un script pouvant afficher la liste des mails des utilisateurs par exemple).

Page 52: Securité web

4. Faille include

d. Comment l’éviter ?

Voilons, comme première solutions le fait d’obliger une extension particulière comme par exemple les .html. Cela évitera, en toute logique, d’inclure les fichiers .htaccess, .htpasswd et tout les scripts php.Le code du début deviendra donc le suivant :

Page 53: Securité web

4. Faille include

d. Comment l’éviter ?Si nous répétons l’attaque donnée en démonstration, voici donc ce qui va se passer :

Néanmoins cette technique n’est pas une protection absolu dans le cas où l’on peut aisément inclure un autre fichier de celui demandé.

Page 54: Securité web

4. Faille include

d. Comment l’éviter ?

Ou alors vous pouvez tout simplement vérifier le fichier à inclure. Pour ce faire vous pouvez dresser une liste des fichiers qui peuvent être inclues soit avec un tableau soit avec des entrée dans une table de la base de données.Exemple de script pouvant exercé ce contrôle :

Page 55: Securité web

Démonstration

Page 56: Securité web

Questions

Page 57: Securité web

Quelques bonnes pratiques

Page 58: Securité web

5. Quelques bonnes pratiques

a. Eviter de montrer nos erreurs

Fonction error_reporting() :

Cette fonction permet d’empécher que dans le cas d’une éventuel erreurs, celle-ci soit afficher au mieux à l’utilisateur et au pire au pirate pour révéler des informations précieuses tel que le nom de variables, le nom de table sql, nom de répertoire, de fichier, ….

Page 59: Securité web

5. Quelques bonnes pratiques

a. Eviter de montrer nos erreurs

Fonction set_error_handler() :

Cette fonction permet de gérer vos erreur. Vous pouvez donc, en cas d’erreur, enregistrer ces erreurs dans une base de données afin d’en prendre connaissance et faire une redirection vers une page d’erreur, évitant ainsi que l’erreur soit visible par le pirate.

Page 60: Securité web

5. Quelques bonnes pratiques

a. Eviter de montrer nos erreurs

Le « @ » anti-erreurs :

Le placement d’un @ devant les fonctions natives php vous permette d’empêcher le déclenchement d’une erreur.

Page 61: Securité web

Questions

Page 62: Securité web