Le quatrième article de cette série est consacré aux failles de type Références Directes à un Objet non Sécurisées (classées n°4 à l’OWASP Top 10).
Derrière cette appellation un peu barbare au premier abord se trouve un type de vulnérabilité assez facile à exploiter, et bien que facile à détecter et corriger, très répandue dans les applications web.

Regardons de plus près ce que ce nom signifie :

“Objet” : Par objet, vous pouvez comprendre : n’importe quelle ressource, fichier, URL, fonction ou donnée qui peut être accessible dans une application donnée. Par exemple, une photo peut être l’objet.

“Référence” : La référence est l’élément qui désigne l’objet et que l’utilisateur va utiliser pour dire à l’application web à quel objet il souhaite accéder. Supposons que notre photo ait un identifiant tel que 002546. L’utilisateur va accéder à la photo via une URL du type http://www.example.com/photos/002546

“Directe” : Directe signifie que la référence (002546) fait une référence immédiate à la photo, qui est peut être nommée “002546.jpeg” dans le système de fichiers du serveur.

“non sécurisées” : Vous l’aurez compris, le système qui a été implémenté sur le site pour accéder aux photos a quelque chose de non sécurisé. Par exemple, si l’application est sensée gérer des photos privées, tel que sur certains réseaux sociaux, ou dans un site internet gérant des albums photos, l’aspect non sécurisé peut donner accès aux photos à n’importe qui, simplement en tapant l’URL dans un navigateur web. Un utilisateur lambda pourra ainsi changer l’URL dans son navigateur et essayer d’accéder à http://www.example.com/photos/002547, ou http://www.example.com/photos/002548, affichant ainsi des photos qui peut être ne lui appartiennent pas!


Illustration - espionnage

D’accord, accéder à des photos que vous n’êtes pas sensé pouvoir voir est dangereux. Bien entendu, l’impact est important, puisque votre application web ne stocke pas de manière sûr les photos : tout le monde peut accéder à n’importe quelle photo sur le serveur. Mais l’impact pourrait être réellement plus important si l’application en question manipulait des données sensibles (données personnelles, données bancaires, factures, ou tout autre document privé…).

Donc, comment se protéger contre de telles vulnérabilités?
Deux approches peuvent être adoptées (une est suffisante) :
– Utiliser des références indirectes, par utilisateur ou par session.
– Vérifier les droits d’accès pour les références directes.

Utiliser des référence indirectes, par utilisateur ou par session

L’idée est assez simple : L’application web va fournir à l’utilisateur des liens/paramètres que n’ont de sens que dans sa propre session web.
Si l’on revient à l’exemple précédent, l’utilisateur pourra être capable d’accéder à des photos en utilisant une URL du type : http://www.example.com/mesphotos/36.
En fonction de la personne connectée, la même URL n’affichera pas la même photo, rendant impossible tout accès à des photos d’autres utilisateurs.
A l’intérieur de l’application, http://www.example.com/mesphotos/36 fera référence à une photo qui n’a pas “36” comme identifiant, mais peut être “002546”. La correspondance entre la référence indirecte (36) et la photo elle même est invisible pour l’utilisateur.

Vérifier les droits d’accès pour les références directes

Utiliser des références directes n’est pas toujours possible. Vous pouvez utiliser des caractères aléatoires pour les références, rendant beaucoup plus difficile le fait de deviner les URL des photos, mais dans beaucoup de situation vous aurez à contrôler qui a le droit d’accéder à une ressource donnée.

Par exemple, si l’application de photos permet le partage, l’URL devra être la même pour plusieurs utilisateurs afin de faciliter les échanges, mais ne devra pas être accessible à tout le monde.
Dans ce cas, un mécanisme de gestion des droits d’accès devra être mis en place.
L’URL à partager pourra par exemple être  http://www.example.com/photos/bryan/dga7asg5s0sbaeaa7sba et accéder à cette URL déclenchera une vérification des droits pour savoir si oui ou non l’accès à la photo vous est autorisé.

Autres articles dans cette série :