Vous êtes sur la page 1sur 5

Contrôle d'accès cassé vs

authentification cassée
Avant de pouvoir parler de deux vulnérabilitré  , nous devons d'abord comprendre la
différence entre l’authentification et l’autorisation .donc

Authentification et autorisation sont les deux mots utilisés dans le monde de


la sécurité. Ils peuvent sembler similaires mais sont complètement différents
les uns des autres. L'authentification est utilisée pour authentifier l'identité de
quelqu'un, tandis que l'autorisation est un moyen de donner à quelqu'un la
permission d'accéder à une ressource particulière. 

IMPACTS :
Exposition de contenu non autorisé
Une fois qu'un attaquant a obtenu des privilèges d'accès non autorisés, il
explore généralement le site pour obtenir des informations sur l'obtention de
plus d'autorisations. Ce faisant, ils accèdent à des données système et
utilisateur sensibles, qu'ils peuvent obtenir du marché noir ou d'autres actes
malveillants. En cas d'attaque réussie, le pirate peut afficher, modifier ou
même supprimer les données sensibles,

Déni de service distribué


Avec l'accès à de nombreux comptes d'utilisateurs, les attaquants peuvent
déployer des bots sur ces comptes et les utiliser pour faire planter le système
en envoyant de nombreuses requêtes à la fois. De plus, ils déploient des
charges utiles malveillantes qui rendent l'application inaccessible et
indisponible pour les utilisateurs et les services autorisés.

3. Il existe des possibilités d' attaques par déni de service distribué


(DDOS) . Avec l'accès à ces comptes d'utilisateurs, les attaquants
peuvent tenter de perturber le trafic normal d'un serveur ciblé, en
déployant des bots. Il est donc difficile pour le serveur de distinguer le
trafic utilisateur légitime du trafic d'attaque.
Escalade des privilèges
Les pirates exploitent les failles d'accès principalement pour obtenir un accès
privilégié aux ressources et aux services généralement protégés des
utilisateurs et des applications normaux. Le plus souvent, les pirates ont
initialement l'intention de prendre le contrôle d'autant de comptes
d'utilisateurs que possible. Avec une élévation de privilèges, les pirates
peuvent facilement voler les données des utilisateurs ou déployer des
charges utiles malveillantes qui peuvent endommager l'ensemble de
l'écosystème d'hébergement d'applications.

2. Les pirates peuvent profiter des failles d'accès pour accéder aux
ressources et aux services qui ne devraient pas être accessibles aux
utilisateurs normaux. 
Par exemple , la page d'administration d'une application Web ne doit
être accessible qu'à l'administrateur et ne doit être accessible à aucun
autre utilisateur. Cependant, si le contrôle d'accès est brisé, les pirates
peuvent facilement y accéder en apportant simplement quelques
modifications à l'URL. Avec ce privilège, ils peuvent voler les données
d'autres utilisateurs ou déployer des charges utiles malveillantes pour
détr

1.  Chaque fois que nous créons un compte sur un site Web, nous
recevons un identifiant unique. En utilisant cet identifiant, nous
pouvons accéder à la base de données où tous nos contenus
sensibles sont enregistrés. Supposons que vous vous soyez connecté
à un site Web et que votre ID utilisateur soit 986 . L'URL de votre page
de profil devrait ressembler à
ceci : https://brokenaccesscontrol.com/profile?id=986 . Nous devons
garder à l'esprit que, comme vous, tous ceux qui créent leur compte
sur ce site Web reçoivent un identifiant d'utilisateur unique. Ainsi, si
vous remplacez votre identifiant par l'identifiant de quelqu'un d'autre,
vous pouvez accéder à son profil. Oui, cela peut arriver si le contrôle
d'accès n'est pas correctement implémenté dans le serveur.
uire l'ensemble de l'écosystème d'hébergement d'applications.

Exemples de contrôle d'accès cassé


 Identifiants non sécurisés : lorsque nous recherchons quelque
chose dans une base de données, nous utilisons la plupart du
temps un identifiant unique. Souvent, cet ID est utilisé dans
l'URL pour identifier les données que l'utilisateur souhaite
obtenir. Supposons que je sois connecté à un site Web et que
mon ID utilisateur soit 1337. Lorsque j'accède à ma propre page
de profil, l'URL ressemble à
ceci : https://example.com/profile?id=1337. Cette
page peut contenir des données sensibles, que personne d'autre
ne devrait voir. Mais que se passe-t-il si je remplace l'ID par l'ID
d'un autre utilisateur ? Si le serveur Web n'est pas configuré
correctement, alors si je visite une autre page,
diteshttps://example.com/profile?id=42,
j'obtiendrai alors la page de profil d'un autre utilisateur, avec
toutes ses données sensibles. Comment puis-je connaître l'ID
d'un autre utilisateur, vous pourriez demander. Eh bien,
l'utilisation d'identifiants d'utilisateur aléatoires qui sont gardés
secrets rend les choses un peu plus difficiles, 

 Navigation forcée : La navigation forcée se produit lorsque


l'utilisateur tente d'accéder à des ressources qui ne sont pas
référencées par l'application, mais toujours disponibles. Par
exemple, une application Web peut avoir une page
d'administration, mais il n'y a pas de lien vers la page
d'administration sur d'autres parties du site Web, un utilisateur
régulier ne trouvera pas la page d'administration en cliquant
simplement autour. Mais si quelqu'un modifie directement
l'URL, par exemple visit https://example.com/admin, il
peut accéder à la page d'administration si le contrôle d'accès est
rompu.
 Mise en cache côté client : Les navigateurs stockent les sites
Web dans leur cache pour garantir un chargement plus rapide si
l'utilisateur tente à nouveau d'accéder au même site Web. Cela
peut poser problème si plusieurs personnes utilisent le même
ordinateur, par exemple dans une bibliothèque ou un
cybercafé. Les développeurs doivent empêcher les navigateurs
de stocker des données sensibles dans leur cache. Cela peut être
accompli par exemple en utilisant des balises méta HTML.

empêcher
-Refuser par défaut :  Par exemple, par défaut, chaque utilisateur de l'application
doit se voir refuser l'accès aux ressources de l'application, seul un utilisateur
légitime obtenant des autorisations pour les afficher, y accéder et les
modifier.

- Interface centrale pour les contrôles d'accès à l'échelle de l'application : Chaque


organisation a besoin d'une méthode standard pour évaluer l'efficacité des
décisions de contrôle d'accès. Il est donc essentiel de disposer d'une
interface gérée centrale pour documenter les schémas de contrôle d'accès
utilisés et aider à la conception d'un cadre utilisé pour tester le succès des
mécanismes de contrôle d'accès établis.

- Tests et audits constants des contrôles d'accès


Il est important de faire des tests de sécurité un processus continu et
cohérent en testant et en auditant en permanence les mécanismes de
contrôle d'accès pour s'assurer qu'ils fonctionnent comme prévu. De plus, des
tests efficaces aident les équipes à identifier les nouvelles vulnérabilités et
failles

- Limitation de l'utilisation de CORS  :


Le protocole CORS (Cross-Origin Resource Sharing) fournit un moyen
contrôlé de partager des ressources utilisés dans la communication
entre le client et l'application cible. Lorsque le protocole CORS est mal
configuré, il permet à un domaine d'être contrôlé par une partie
malveillante pour envoyer des requêtes à votre domaine.

-Activez le contrôle d'accès basé sur les rôles  : les utilisateurs reçoivent des
autorisations en fonction de leurs rôles.  Au lieu d'identifier chaque
utilisateur individuellement, les utilisateurs sont affectés à un groupe
de rôles,
-Activez le contrôle d'accès basé sur les autorisations  :
Il s'agit d'une méthode de contrôle d'accès, où la couche d'autorisation
vérifie si l'utilisateur a l'autorisation d'accéder à des données
particulières ou d'effectuer une action particulière, généralement en
vérifiant si les rôles de l'utilisateur ont cette autorisation ou non.

-Activez le contrôle d'accès obligatoire  :


Il s'agit d'une méthode de sécurité qui limite la possibilité d'accéder
aux ressources en fonction de la sensibilité des informations que
contient la ressource. Cette politique de sécurité ne peut être contrôlée
que par l'administrateur, les utilisateurs réguliers n'ont pas la
possibilité de modifier cette politique. En raison de cette administration
centralisée, il est considéré comme très sécurisé. 

Vous aimerez peut-être aussi