L’autorisation

Nous rappelons que l’autorisation permet de vérifier les droits d’accès (aux ressources) pour un utilisateur authentifié. Elle est donc différente de l’authentification qui vérifie uniquement si les identifiants d’un utilisateur sont corrects. L’autorisation présente un risque de sécurité en cas d’absence de vérification systématique des rôles et des droits d’accès (aux ressources). Dans ce cas, un attaquant peut obtenir l’accès aux données et aux fonctions non-autorisées (données des autres utilisateurs, fonctionnalités administrateur etc). Les risques liés à l’autorisation sont placés en 1e position du OWASP Top 10 du 2021 (et en 5e position dans l’édition 2017).

Nous aimerons souligner que souvent un problème d’autorisation donne l’accès aux informations privées d’autres utilisateurs ce qui représente une violation du RGPD et peut entraîner des sanctions de la part du CNIL. Par exemple, une agence immobilière à été sanctionnée de 400.000€ parce qu’elle a pris trop de temps pour remédier une faille de ce type.

Nous donnons ci-dessous deux scénarios typiques d’exploitation. Ces exemples sont délibérément simplifiés, afin de montrer les idées principales. Dans des situations réelles il est plus difficile de deviner comment exploiter la vulnérabilité.

Scénario 1 (changement de rôle) :

  • L’attaquant remarque l’URL de son rôle : /user/getAccounts
  • Il le modifie pour un autre répertoire (rôle) : /admin/getAccounts
  • L’attaquant obtient l’accès à des droits plus importants.

Scénario 2 (accès à l’information d’un autre utilisateur) :

  • L’attaquant remarque son id : /compte?id=6065
  • Il le modifie par un autre numéro : /compte?id=6066
  • L’attaquant obtient l’accès à un autre compte.

« Sécurisation » par modification de l’IU

Dans certains cas les développeurs « restreignent » l’accès aux fonctionnalités de l’application en affichant dans l’interface utilisateur uniquement les liens, les menus et les objets « autorisés » sans enforcer les vérifications du coté backend. C’est un exemple typique de « sécurité par l’obscurité » qui repose sur la non-divulgation d’information relative au fonctionnement pour en assurer la sécurité. Il est bien évident que la sécurité dans ce cas est éphémère : c’est contrôle d’accès au niveau présentation et il peut être facilement contourné, car l’attaquant peut accéder directement au pages « non-autorisées » en « devinant » ou observant le nom de la ressource.

Une autre erreur courante est la « restriction » des types sur le frontend à l’aide du HTML/JavaScript. Comme dans le cas précédent, l’attaquant peut directement envoyer des valeurs falsifiées à l’application (par exemple via les outils du navigateur, un proxy intercepteur ou une connexion directe).

Références directes

Lorsqu’on affiche l’information il est souvent nécessaire d’inclure des références vers des objets (par exemple vers les détails d’une commande) pour faciliter la navigation. L’utilisation des références directes (par exemple des clef primaires des tables correspondantes) pose à longue terme des soucis de sécurité, car cela permet théoriquement de deviner et d’énumérer d’autres références valides (qui pointent vers des objets existants). Si le contrôle d’accès est systématique, cela ne pose que des inconvénients légers (par exemple un attaquant pourrait estimer le nombre d’enregistrements dans une table). Par contre, en cas d’absence de contrôle (n’est-ce qu’à un seul endroit), cette énumération permet de retrouver et d’accéder facilement aux autres enregistrements valides.

Une politique plus sécurisée (mais demandant plus de ressources) consiste dans le remplacement de ces références par des identifiants dérivés (hash, guid, table de traduction dans une session). C’est surtout intéressant en cas d’APIs ou il est recommandé d’utiliser des guid pour améliorer la sécurité.

Remédiation

La vérification systématique implique que n’importe quel accès à l’application doit passer par une autorisation. Il faut s’assurer que les droits des utilisateurs sont restreints par rapport à leur rôles et que la politique de sécurité se fonde sur une liste blanche (indiquant les dérogations) et un accès interdit par défaut.

Il est important de souligner que la politique d’autorisation doit inclure la gestion correcte des adresses erronées, l’utilisation des différents verbes de HTTP (comme par exemple DELETE et PUT), la vérification du mode d’accès à la ressource (par exemple : lecture, écriture, suppression), ainsi que l’application des restrictions sur les fichiers téléversés.

Il est préférable de ne pas utiliser des valeurs prédictibles comme identifiants et de les remplacer par des références indirectes, surtout dans les cas des APIs.

Comme la découverte des failles liées au contrôle d’accès nécessite de « deviner » le nom ou l’identifiant de la ressource/fonction, les attaques correspondantes génèrent beaucoup de trafic en essayant des différentes possibilités (par brute-force). Il est donc très important d’utiliser des outils d’anti-automatisation, comme par exemple le limitateur de vitesse, car cela ralentira fortement la progression de l’attaquant. Il est également recommandé de bloquer l’accès aux fichiers non-nécessaires, comme les fichiers de configuration ou journal et de loguer toutes les erreurs d’autorisation, car c’est un indicateur fiable de début d’attaque.

Les principaux CWE’s associés

Les CWE’s principaux associés à cette entrée sont :