Évitez d'exposer les clés primaires dans le code source d'une application web.

Question

Je rencontre souvent des applications web qui exposent les clés primaires de la base de données internes à travers des formulaires comme des cases à cocher. Et parfois je vois du javascript correspondant à une valeur magique de type int ou guid qui change la logique.

Est-ce une bonne pratique d'éviter de divulguer tous les identifiants internes des lignes de votre application web pour empêcher les externes de comprendre trop de votre système et éventuellement l'exploiter? Si oui, quelle est la meilleure façon de résoudre ce problème?

Devriez-vous exposer une autre valeur à l'application web qui peut être traduite en clé primaire?

Merci

Édition

Dans un monde parfait, votre application serait 100% sécurisée, donc il ne serait pas grave d'obscurcir les choses. De toute évidence, ce n'est pas le cas, donc devrions-nous opter pour la prudence et ne pas exposer ces informations?

Certains ont souligné que Stackoverflow expose probablement une clé dans l'URL, ce qui est probablement acceptable. Cependant, les considérations sont-elles différentes pour les applications d'entreprise?

Answer 1

Je ne suis pas d'accord avec le point de vue selon lequel exposer les clés primaires est un problème. Cela peut poser problème si vous les rendez visibles aux utilisateurs car alors elles prennent un sens en dehors du système, ce que vous essayez généralement d'éviter.

Cependant, utiliser des ID comme valeur pour les éléments de liste de la boîte de combinaison? Je dis allez-y. A quoi bon faire une traduction vers et depuis une valeur intermédiaire? Vous n'aurez peut-être pas de clé unique à utiliser. Une telle traduction introduit plus de potentiel pour des bogues.

Ne négligez simplement pas la sécurité.

Si, par exemple, vous présentez à l'utilisateur 6 éléments (ID 1 à 6), ne supposez jamais que vous n'obtiendrez que ces valeurs de retour de l'utilisateur. Quelqu'un pourrait essayer de compromettre la sécurité en renvoyant l'ID 7 donc vous devez toujours vérifier que ce que vous obtenez en retour est autorisé.

Mais éviter cela entièrement? Pas question. Pas besoin.

Comme le commente une autre réponse, regardez l'URL ici. Cela inclut ce qui est sans aucun doute la clé primaire de la question dans la base de données de SO. Il est tout à fait acceptable d'exposer les clés pour des utilisations techniques.

De plus, si vous utilisez une valeur de substitution à la place, ce n'est pas nécessairement plus sécurisé.

Answer 2

Oui à toutes vos questions. Je suis d'accord avec vos affirmations selon lesquelles vous devriez "exposer une autre valeur à l'application web qui peut être traduite en clé primaire"

Autrement, vous pourriez vous exposer à des problèmes potentiels.

Modifier

En ce qui concerne le commentaire disant que "il n'y a aucune raison de subir le coup pour des clés triviales. Regardez l'URL de votre navigateur en ce moment, je parie que vous voyez une clé!".

Je comprends ce que vous dites et, oui, je vois bien la clé dans l'URL de SO et je suis d'accord qu'elle se réfère probablement à une PK de base de données. J'admets que dans des cas comme celui-ci, c'est probablement correct s'il n'y a pas de meilleure alternative.

Je préférerais quand même exposer quelque chose d'autre qu'une PK - quelque chose avec une valeur sémantique. Le titre de la question est également dans l'URL, mais comme il serait difficile de le vérifier comme étant unique (ou de le transmettre entre utilisateurs verbalement), il ne peut pas être utilisé de manière fiable seul.

Cependant, en regardant les URL des "tags" (c'est-à-dire https://stackoverflow.com/questions/tagged/java+j2ee), les PK ne sont pas exposées et les noms des tags sont utilisés à la place. Personnellement, je préfère cette approche et je m'y efforcerais.

Je voulais aussi ajouter que les données pointées par une PK peuvent parfois changer avec le temps. J'ai travaillé sur un système où une table était remplie d'informations provenant d'un processus hors ligne - par exemple, des statistiques mensuelles où le contenu de la table de base de données était supprimé à la fin du mois et remplacé par de nouvelles données.

Si les données sont ajoutées à la base de données dans un ordre différent, les PK de points de données spécifiques changeraient, et tous les signets enregistrés à partir d'un mois précédent vers ces données pointeraient désormais vers un ensemble différent de données.

C'est un cas où exposer une PK "casserait" une application sans rapport avec la sécurité de l'application. Ce n'est pas le cas avec une clé générée.

Answer 3

Oui, exposer les clés est une information qui peut être utilisée dans une attaque. Surtout si elles sont prévisibles.

Utilisez une clé/colonne différente si vous pensez que l'information est sensible.

Par exemple, pour éviter de montrer combien d'utilisateurs vous avez, envisagez :

site.com/user/123 vs site.com/user/nom d'utilisateur

Answer 4

Exposer d'autres valeurs que la clé primaire ne vous évitera pas le fardeau de vérifier votre sécurité. En effet, si votre sécurité comporte des failles, les utilisateurs "malveillants" pourraient toujours accéder à des objets auxquels ils ne sont pas censés accéder en modifiant la valeur dans l'URL. Ils pourraient avoir moins d'indices sur quelles valeurs utiliser, mais en choisissant des valeurs au hasard, ils pourraient avoir de la chance.

Si vous souhaitez améliorer la sécurité de cette manière, vous devrez utiliser de grandes chaînes aléatoires (pour rendre les devinettes difficiles) dans l'URL, au lieu de l'identifiant, et utiliser une table d'indirection associant la valeur aléatoire au bon identifiant en arrière-plan.

Je pense que cela ne vaut pas la peine la plupart du temps.

Cela dit, c'est utile dans les cas où vous voulez une "sécurité par l'obscurité", comme par exemple lorsque vous exposez des pages pour modifier les mots de passe des utilisateurs, sans nécessiter de connexion (pour les utilisateurs ayant perdu leur mot de passe). Dans ce cas, vous devriez également associer une date de validité limite à votre clé.

Answer 5

Comme toujours, "ça dépend". Si quelqu'un pouvait tirer profit (disons) en sachant combien de transactions vous effectuez par (heure/jour/mois), et que vous exposez un ID de transaction en tant que nombre croissant de manière monotone, alors c'est un risque.

Comme d'autres l'ont dit cependant, pour une liste déroulante de valeurs, généralement aucun problème.