Broken Access Control

Broken Access Control : Vulnerability

Description

Une vulnérabilité de type “Broken Access Control” est une vulnérabilité qui permet de charger une page web qui n’est pas sensé être accessible depuis la session active due à une mauvaise configuration de l’administrateur de la page.

Vulnérabilité

Par exemple l’url comportant un panel d’administration d’un site web est accessible via le navigateur directement sans avoir eu le besoin de s’authentifier avant.

C’est une vulnérabilité directement créé dans la conception même du site.

Exemple 1 - Robots.txt

Il est possible de regarder si un fichier “robots.txt” existe afin de pouvoir regarder les pages qui ne sont pas autorisés à être afficher dans un moteur de recherche

Exemple pratique

Exemple de fichier :

User-agent: *
Disallow: /administrator-panel

La page “/administrator-panel” ne sera donc pas répertorié sur un moteur de recherche cela ne veut pourtant pas dire qu’elle est innaccessible.

Exemple 2 - obfuscate URL

L’URL d’accès pour une page “sécurisée” peut aussi être écrite de manière à ne pas pouvoir la retrouver facilement.

https://insecure-website.com/administrator-panel-yb556

Exemple pratique

L’url semble au première abord impossible à découvrir sans la connaître préallablement. Il est cependant possible que le serveur en utilisant du javascript directement côté client affiche l’url dans le code source de la page comme ceci :

<script>
	var isAdmin = false;
	if (isAdmin) {
		...
		var adminPanelTag = document.createElement('a');
		adminPanelTag.setAttribute('https://insecure-website.com/administrator-panel-yb556');
		adminPanelTag.innerText = 'Admin panel';
		...
	}
</script>

Exemple 3 - Vertical privilege escalation

L’application peut aussi vérifié que l’utilisateur est bien le bon suite après s’être loggé directement. Afin de vérifier que l’utilisateur est bien connecté, le serveur peut indiquer au client d’utiliser par exemple : un cookie, un champ caché ou un paramètre.

Exemple avec un paramètre :

https://insecure-website.com/login/home.jsp?admin=true
https://insecure-website.com/login/home.jsp?role=1

Exemple pratique

Par exemple après s’être log sur une page, en regardant la requête faite au navigateur :

GET /admin HTTP/2
Host: 0a6d00a2034989a580f46c77004000e2.web-security-academy.net
Cookie: Admin=false; session=NOFhwlLAPpqJhOxpyhMYta3MookyOPvt
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.5938.63 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Sec-Ch-Ua: "Chromium";v="117", "Not;A=Brand";v="8"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Linux"
Referer: https://0a6d00a2034989a580f46c77004000e2.web-security-academy.net/admin
Accept-Encoding: gzip, deflate, br
Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7

Il suffit de modifier le cookie envoyé avec “Admin=true” pour faire croire au serveur que l’utilisateur est bien un administrateur.

Exemple 4 - Horizontal privilege escalation

Dans cette exemple ci un utilisateur quelconque pourrait avoir accès à des pages d’un autre utilisateur. Cela se base sur le même principe que l’exemple précédent.

exemple :

https://insecure-website.com/myaccount?id=123

En changeant l’id :

https://insecure-website.com/myaccount?id=124

L’utilisateur pourrait accéder aux informationss de l’utilisateur ayant l’id 124 plutôt que le sien et ainsi accéder à une page qui n’est normalement accessible qu’à cet utilisateur.

Dans certaines applications, le paramètre exploitable n’a pas de valeur prévisible. Par exemple, au lieu d’un nombre incrémentiel, une application peut utiliser des identifiants uniques globaux (GUID) pour identifier les utilisateurs. Cela peut empêcher un attaquant de deviner ou de prédire l’identifiant d’un autre utilisateur.

Toutefois, les GUID appartenant à d’autres utilisateurs peuvent être divulgués ailleurs dans l’application où les utilisateurs sont référencés, par exemple dans les messages ou les avis des utilisateurs.

Exemple pratique :

Sur un blog - je dois prendre le contrôle de l’utilisateur : carlos.
Pour prendre le contrôle je possède un compte utilisateur différent.

Pour se faire, je cherche les posts créé par l’utilisateur carlos pour récupérer son GUID :

<span id=blog-author><a href='/blogs?userId=4b6c393c-bc98-451b-9d23-55c317b1b995'>carlos</a></span> | 30 August 2023

son GUID est donc : 4b6c393c-bc98-451b-9d23-55c317b1b995

Je me connecte ensuite à la page afin d’accéder à la page my account :

https://www.0a2b005e047ab07080ce58f600e40024.web-security-academy.net/my-account?id=eecfbbef-6ac7-46ab-92fd-1301e6a025c2

Je remplace simplement l’id de mon utilisateur par celui de carlos :

https://www.0a2b005e047ab07080ce58f600e40024.web-security-academy.net/my-account?id=4b6c393c-bc98-451b-9d23-55c317b1b995

Exemple 4 - Horizontal to vertical privilege escalation

Ce type d’attaque est le même que dans le point précédent cependant l’attaque va privilégié des utilisateurs privilégiés dans le but de s’octroyer plus de pouvoirs.