L'exposition de vos clés primaires (en particulier si elles sont prévisibles) est une vulnérabilité appelée Insecure Direct Object Reference.
En ayant une URL (ou tout autre paramètre fourni par le client) comme ceci :
http://www.domain.com/myaccount?userid=12
Vous donnez à vos utilisateurs finaux la possibilité de jouer avec ces variables et de transmettre toutes les données qu'ils souhaitent. La contre-mesure pour atténuer cette vulnérabilité consiste à créer des références d'objet indirectes à la place. Cela peut sembler être un grand changement, mais ce n'est pas nécessairement le cas. Vous n'avez pas besoin d'aller ressaisir toutes vos tables ou quoi que ce soit, vous pouvez le faire simplement en étant intelligent avec vos données grâce à l'utilisation d'une carte de référence indirecte.
Considérez ceci :vous avez un utilisateur qui effectue un achat sur votre site. Et quand il est temps de payer, on leur présente une liste déroulante des numéros de carte de crédit que vous avez "dans le dossier". Si vous regardez le code de la liste déroulante, vous voyez que les numéros de carte de crédit sont associés aux clés 8055, 9044 et 10099.
L'utilisateur pourrait regarder cela et penser qu'ils ressemblent beaucoup à des clés primaires à incrémentation automatique (l'utilisateur aurait probablement raison). Il commence donc à essayer d'autres clés pour voir s'il peut payer avec la carte de quelqu'un d'autre.
Maintenant, techniquement, vous devriez avoir un code côté serveur qui garantit que la carte sélectionnée fait partie du compte de l'utilisateur et qu'il peut l'utiliser. Ceci est un exemple artificiel. Pour l'instant, nous supposerons que ce n'est pas le cas ou qu'il s'agit d'un autre type de formulaire qui n'a peut-être pas ce type de contrôle côté serveur.
Alors, comment empêcher l'utilisateur final de choisir une clé qui ne devrait pas être disponible ?
Au lieu de leur montrer une référence directe à l'enregistrement dans la BD, donnez-leur une référence indirecte.
Au lieu de mettre les clés DB dans la liste déroulante, nous allons créer un tableau sur le serveur et le remplir dans la session de l'utilisateur.
Array cards = new Array(3);
cards[0] = 8055;
cards[1] = 9044;
cards[2] = 10099;
Dans la liste déroulante, nous fournissons maintenant la référence à l'index du tableau où la carte est stockée. Ainsi, au lieu de voir les clés réelles, l'utilisateur final verra les valeurs 0, 1 et 2, s'il affiche la source.
Lorsque le formulaire est soumis, l'une de ces valeurs sera transmise. Ensuite, nous sortons le tableau de la session de l'utilisateur et utilisons l'index pour obtenir la valeur. La clé réelle n'a jamais quitté le serveur.
Et l'utilisateur peut transmettre différentes valeurs tout au long de la journée s'il le souhaite, mais il n'obtiendra jamais, au grand jamais, un résultat autre que ses propres cartes, quel que soit le contrôle d'accès côté serveur en place.
Gardez cependant à l'esprit que lorsque vous utilisez l'index transmis pour obtenir la valeur, si l'utilisateur s'en mêle, vous pourriez obtenir des exceptions (ArrayOutOfBounds, InvalidIndex, peu importe). Enveloppez donc tout cela dans un try/catch afin de pouvoir supprimer ces erreurs et consigner les échecs pour rechercher les tentatives de piratage.
J'espère que cela vous aidera.
Pour en savoir plus sur les références d'objets directes non sécurisées, consultez le Top 10 de l'OWASP. Il s'agit du risque numéro A4. https://www.owasp.org/index.php/Top_10_2010-A4 -Insecure_Direct_Object_References
