Sécurisez vos applications web avec l'OWASP

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 suivants :

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.

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. Le lien de la page principale ressemble à ceci :

https://example.com/guppy_login.html

Vous remarquerez qu’il y a une structure définie. La page de loginguppy_login.htmlest 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://example.com/poisson_login.html

Vous pouvez mettre en œuvre les restrictions d’URL directement dans votre serveur HTTP (comme Apache httpd ou nginx) afin d’autoriser uniquement certaines adresses IP, certains utilisateurs ou certains groupes d’utilisateurs à accéder à une partie de votre site.

Par exemple, voici un extrait de configuration d’un serveur nginx utilisant la méthode d’authentification JWT (Json Web Token) pour n’autoriser que les utilisateurs du groupe poisson à accéder à la page qui leur est dédiée :

map $jwt_claim_scope $scope_poisson {
    "member_of_poisson" 1;
}


server {
    listen 80;

    location /poisson_login.html {
        auth_jwt          "API";
        auth_jwt_key_file conf/api_secret.jwk;
        Auth_jwt_require $scope_poisson;
    }
}

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

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://example.com/index.php/view?account=3453

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

https://example.com/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 ajoutantaccount=1, vous donnez à l’attaquant un indice sur la façon dont votre application web et votre base de données sont configurées.

Nous sommes dans ce cas présent exactement dans ce qu’on peut qualifier de référence d’objet non sécurisée, ou IDOR (Insecure Direct Object Reference en anglais). Et c’est globalement toujours le cas quand le simple changement d’URL permet d’accéder à la donnée sans aucun autre mécanisme de contrôle d’accès. 

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

Il ne faudra jamais se contenter de cacher des URL ou d’éviter de donner des indices, mais toujours mettre en place un mécanisme de contrôle, couplé à une authentification forte.

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

Une attaque d’octet null permet de contourner certains filtres au niveau du serveur http, en créant une confusion entre l’adresse demandée et celle comprise par l’application.

En effet, en insérant la chaîne de caractères “%00” dans une URL, il y a de fortes chances pour que l’application web remplace cette chaîne par un caractère de code ASCII 0, qui sert de marqueur de fin de chaîne de caractères dans de nombreux langages de programmation.

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.htmou similaire.

example.org/fight/default.aspx?content=about_us.htm

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

Il va donc tenter d’accéder à l’adresse suivante :

example.org/fight/default.aspx?content=./default.aspx.cs

Pour des raisons de sécurité, le serveur web (Apache httpd, ou nginx par exemple) est configuré pour refuser toutes les requêtes se terminant par “.cs”, et l’attaque échoue.

Un octet nul (%00) permet de faire croire au serveur web que l'URL est valide, tout en poussant l’application web à traiter une URL invalide.

L’attaquant va donc envoyer la requête suivante :

example.org/fight/default.aspx?content=./default.aspx.cs%00.htm

L’adresse demandée se termine par “.htm”, et non par “.cs”, donc le serveur web considère l’URL comme valide et la transmet à l’application. L’application va décoder l’URL et transformer la chaîne “%00” en octet nul. Comme l’octet nul marque la fin de la chaîne de caractère, l'application traiterait en fait la requête comme si l’URL demandée était la suivante :

example.org/fight/default.aspx?content=./default.aspx.cs

L'attaquant verra donc le contenu du fichierdefault.asps.cs. Il sera ici possible d'accéder à n'importe quel fichier sur le serveur et donc de contourner les contrôles d'accès mis en place.

Comme il n’y a pas d’usage normal pour l’octet nul dans une application web, le plus simple est de le détecter au niveau de serveur web ou du pare-feu et de rejeter toute requête en contenant.

Cachez des données sensibles dans une base de données

Il existe plusieurs techniques qui permettent de cacher les données sensibles d’une base de données et donc de sécuriser une application.

• L'anonymisation est une technique recommandée par l’OWASP pour cacher des données privées en chiffrant, brouillant et supprimant des parties des données. Par exemple, si une demande est faite pour la date de naissance d'une personne pour s’authentifier, seule l'année sera fournie par la base de données.

• La pseudonymisation est une technique recommandée par le RGPD. Elle remplace les données personnelles par des identifiants et des pseudonymes artificiels pour cacher les données sensibles.

• La minimisation des données permet de se conformer à l'ensemble de règles du RGPD. L'entreprise doit uniquement demander, enregistrer et traiter les données personnelles requises. En d'autres termes, toute donnée personnelle demandée doit avoir un motif commercial solide.

Il existe deux façons d'appliquer ces techniques à votre base de données.

• Le masquage dynamique des données est un moyen d'appliquer des règles d'anonymisation sur les colonnes de données sensibles. Lorsqu'une demande est faite pour récupérer les données des colonnes masquées, elle n'apparaîtra pas dans sa forme complète. Ces données peuvent également être cachées aux administrateurs de bases de données avec des rôles qui bloquent l'accès aux données sensibles.

• Cloner et générer des masques de données utilisant plusieurs bases de données. En utilisant le même schéma, une base de données supplémentaire utilisée pour récupérer des informations peut contenir des données masquées pour les colonnes sensibles déjà présentes.

Gérez l'authentification

Pour sécuriser l’authentification, il existe de bonnes pratiques de sécurité simples à appliquer :

• Supprimer les comptes par défaut en changeant les mots de passe connus.

• Refuser l’accès par défaut : on accorde l’accès seulement sur confirmation de l’authentification.

• Utiliser le principe de moindre privilège pour vous assurer qu'un ou deux comptes seulement ont des privilèges élevés.

• Contrôler l’accès depuis le serveur et non pas côté client.

Si vous êtes développeur, voici quelques astuces pour sécuriser les contrôles d’accès :

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

Dans le prochain chapitre, verrez comment sécuriser les données sensibles grâce à la cryptographie.