• 10 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 22/07/2022

Empêchez l'exploitation des contrôles d'accès

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Passons maintenant à la gestion des contrôles d'accès et à leur sécurisation.

Comprenez le principe du contrôle d'accès

Imaginez une application web avec quatre niveaux d’accès pour quatre groupes de personnes.

Le premier groupe aura un accès limité, le deuxième groupe aura un accès un peu plus privilégié, le troisième groupe aura encore plus d’accès. Enfin, le quatrième groupe aura les accès administrateur ou root.

Ces niveaux d’accès sont appelés rôles.

Imaginons les quatre rôles suivant.

Rôle

Niveau d'accès

guppy

1

poisson

2

dauphin

3

baleine

4

Dans cet exemple, vous devrez créer un accès pour chaque rôle. Assurez-vous que les rôles guppy, poisson et dauphin ont des accès limités. Le rôle baleine, lui, peut accéder à tout ce que les autres peuvent faire : c’est l’administrateur.  

Le contrôle d'accès consiste à configurer votre application web pour s'assurer que les utilisateurs ne peuvent accéder qu'aux données permises par leur rôle.

L'authentification valide une identité, comme un nom d'utilisateur et un mot de passe. Une fois authentifié, vous pourrez accéder à certaines pages. Si les contrôles d’accès ne sont pas verrouillés, vous pourrez accéder à des pages et à des fonctionnalités auxquelles vous n'êtes normalement pas autorisé à accéder, parfois sans le savoir.

Découvrez les attaques contre le contrôle d'accès

Appréhendez la restriction URL

Les attaques courantes contre le contrôle d'accès se produisent lorsqu'une URL permet de contourner l'authentification. Les pirates informatiques utilisent la connaissance des formats et des modèles pour deviner l'URL des pages privilégiées qui n'ont pas été configurées de manière sécurisée. Pour se protéger contre ce type d'attaque, il est possible de mettre en place une restriction URL.

Prenons le cas d’une attaque utilisant les rôles que nous avons définis précédemment

Un utilisateur du groupe guppy se connecte, et le lien de la page principale ressemble à ceci :

https://webdevfightshacker.bla/guppy_login.html

Vous remarquerez qu’il y a une structure définie. La page de login  guppy_login.html  est définie comme page principale.

Un attaquant pourra par exemple être en mesure de deviner la page d’authentification d’un autre rôle en devinant les pages des autres groupes (poisson_login.html, par exemple).

https://webdevfightshacker.bla/whale_login.html

Comprenez les références directes d'objets non sécurisées (IDOR)

Un utilisateur malveillant dispose de techniques pour accéder à une grande partie du code d'une application web. Une partie de ce code peut révéler comment une base de données est organisée. Le fait de fournir quelques informations sur la structure de l’application web peut permettre à un utilisateur non autorisé d’effectuer des actions malveillantes et de contourner les accès prédéfinis. 

Par exemple, si vous accédez à votre compte sur un site et que vous êtes sur la page principale, vous remarquez que l'adresse URL ressemble à ceci :

https://webdevfightshacker.bla/index.php/view?account=3453

Ici le numéro 3453 correspond a un nombre dans la base de données. Une personne malveillante pourrait ici modifier ce nombre pour accéder à un compte en particulier.

https://webdevfightshacker.bla/index.php/view?account=1

Dans l'exemple ci-dessus, chaque compte est considéré comme un objet. Lorsque vous faites une référence directe à cet objet dans l'URL en ajoutant account=1, vous donnez à l’attaquant un indice sur la façon dont votre application web et votre base de données sont configurées.

Il pourra ainsi exploiter ces faiblesses pour accéder à certaines parties non autorisées de l'application.

Découvrez l'attaque null byte (octet nul)

Une attaque d'octet nul tire parti des références de l'objet. Les noms de page par défaut peuvent être basés sur la configuration du modèle, de la vue et du contrôleur (MVC) que beaucoup d'applications web utilisent.

Cela permet à un attaquant d'utiliser ces connaissances pour extraire une partie du code source de votre page !

Regardons un site web avec un lien de menu intitulé  About_us.htm. Ceci montre que toutes les pages se terminent par  .htm  ou similaire.

webdevfightshacker.bla/fight/default.aspx?content=about_us.htm

L’attaquant sait aussi que le fichier default.aspx.csest la page principale, et veut y jeter un coup d’œil pour plus d'informations.

Un octet nul (./) fait croire au navigateur que l'URL est complète. La chaîne de caractères qui suit l'octet nul peut donner à l’attaquant l'occasion de montrer le contenu de n'importe quel fichier.

webdevfightshacker.bla/fight/default.aspx?content=%20./default.aspx.cs%00.htm

Cet exemple montre la page default.asps.cs.Il sera ici possible d'accéder à n'importe quelle page et donc de contourner les contrôles d'accès mis en place.

Sécurisez les contrôles d’accès

  1. Au lieu de nommer vos pages cibles avec un sens, utilisez un tableau de valeurs clés qui font référence à vos objets.

  2. Modifiez les noms par défaut de vos pages web.

  3. Assurez-vous que toutes les pages ont un contrôle d'authentification.

  4. Personnalisez vos exceptions et vos codes d'erreur.

En résumé

  • Les applications web avec authentification ne garantissent pas que toutes les pages sont verrouillées par contrôle d’accès.

  • Les références directes aux objets peuvent amener un attaquant à comprendre les modèles et la configuration des applications web.

  • N'utilisez pas de noms prévisibles ou de références directes à la base de données dans l'URL.

  • Prévenez les attaques d'octets nuls en protégeant votre code source.

  • Utilisez des références d'objet indirectes avec des paramètres et des combinaisons clé-valeur.

  • Personnalisez vos codes d'erreur pour qu'ils ne révèlent pas les attributs de la base de données.

Dans le prochain chapitre, nous aborderons les failles XSS et comment s’en prémunir.

Exemple de certificat de réussite
Exemple de certificat de réussite