Exposer les identifiants de base de données - risque de sécurité?

J'ai entendu dire que l'exposition des identifiants de base de données (dans les URL, par exemple) est un risque pour la sécurité, mais j'ai du mal à comprendre pourquoi.

Des opinions ou des liens expliquant pourquoi c'est un risque ou pourquoi ce n'est pas le cas?

EDIT: bien sûr, l'accès est limité, par exemple si vous ne pouvez pas voir la ressource, foo?id=123vous obtiendrez une page d'erreur. Sinon, l'URL elle-même doit être secrète.

EDIT: si l'URL est secrète, elle contiendra probablement un token généré qui a une durée de vie limitée, par exemple valable 1 heure et ne peut être utilisé qu'une seule fois.

EDIT (des mois plus tard): ma pratique préférée actuelle pour cela est d'utiliser UUIDS pour les identifiants et de les exposer. Si j'utilise des nombres séquentiels (généralement pour les performances sur certaines bases de données) comme ID, j'aime générer un jeton UUID pour chaque entrée en tant que clé alternative, et l'exposer.

Dans les bonnes conditions, exposer des identifiants ne constitue pas un risque pour la sécurité. Et, en pratique, il serait extrêmement lourd de concevoir une application Web sans exposer les identifiants.

Voici quelques bonnes règles à suivre:

1. Utilisez la sécurité basée sur les rôles pour contrôler l'accès à une opération. La façon dont cela est fait dépend de la plate-forme et du cadre que vous avez choisis, mais beaucoup prennent en charge un modèle de sécurité déclaratif qui redirigera automatiquement les navigateurs vers une étape d'authentification lorsqu'une action nécessite une autorisation.
2. Utilisez la sécurité par programmation pour contrôler l'accès à un objet. C'est plus difficile à faire au niveau du cadre. Le plus souvent, c'est quelque chose que vous devez écrire dans votre code et qui est donc plus sujet aux erreurs. Cette vérification va au-delà de la vérification basée sur les rôles en s'assurant non seulement que l'utilisateur dispose des droits pour l'opération, mais également des droits nécessaires sur l'objet spécifique en cours de modification. Dans un système basé sur les rôles, il est facile de vérifier que seuls les managers peuvent donner des augmentations, mais au-delà de cela, vous devez vous assurer que l'employé appartient au département du manager particulier.
3. Pour la plupart des enregistrements de base de données, les conditions 1 et 2 sont suffisantes. Mais l'ajout d'identifiants imprévisibles peut être considéré comme une petite assurance supplémentaire, ou «sécurité en profondeur», si vous adhérez à cette notion. Un endroit où les identifiants imprévisibles est une nécessité, cependant, est dans les ID de session ou d'autres jetons d'authentification, où l'ID lui-même authentifie une demande. Ceux-ci doivent être générés par un RNG cryptographique.

Bien qu'il ne s'agisse pas d'un risque pour la sécurité des données, il s'agit absolument d'un risque de sécurité de l'intelligence d'affaires car il expose à la fois la taille et la vitesse des données. J'ai vu des entreprises en souffrir et j'ai écrit en profondeur sur cet anti-modèle. À moins que vous ne construisiez simplement une expérience et non une entreprise, je vous suggère fortement de garder vos identifiants privés hors de la vue du public. https://medium.com/lightrail/prevent-business-intelligence-leaks-by-using-uuids-instead-of-database-ids-on-urls-and-in-apis-17f15669fd2e

Cela dépend de ce que représentent les ID.

Considérons un site qui, pour des raisons de concurrence, ne souhaite pas rendre public le nombre de membres dont il dispose, mais en utilisant des ID séquentiels, il le révèle quand même dans l'URL: http://some.domain.name/user?id=3933

D'autre part, s'ils ont utilisé le nom de connexion de l'utilisateur à la place: http://some.domain.name/user?id=some, ils n'ont rien révélé que l'utilisateur ne savait pas déjà.

L'idée générale va dans ce sens: "Ne divulguez que peu d'informations sur le fonctionnement interne de votre application à quiconque."

L'exposition de l'ID de la base de données compte comme la divulgation de certaines informations.

Les raisons en sont que les pirates peuvent utiliser n'importe quelle information sur le fonctionnement interne de vos applications pour vous attaquer, ou qu'un utilisateur peut modifier l'URL pour accéder à une base de données qu'il n'est pas censé voir?

Nous utilisons des GUID pour les identifiants de base de données. Leur fuite est beaucoup moins dangereuse.

Si vous utilisez des ID entiers dans votre base de données, vous pouvez permettre aux utilisateurs de voir facilement les données qu'ils ne devraient pas en modifiant les variables qs.

Par exemple, un utilisateur pourrait facilement changer le paramètre id dans ce qs et voir / modifier les données qu'il ne devrait pas http: // someurl? Id = 1

Lorsque vous envoyez des identifiants de base de données à votre client, vous êtes obligé de vérifier la sécurité dans les deux cas. Si vous conservez les identifiants dans votre session Web, vous pouvez choisir si vous voulez / devez le faire, ce qui signifie potentiellement moins de traitement.

Vous essayez constamment de déléguer des choses à votre contrôle d'accès;) Cela peut être le cas dans votre application mais je n'ai jamais vu un système back-end aussi cohérent de toute ma carrière. La plupart d'entre eux ont des modèles de sécurité conçus pour une utilisation non Web et certains ont eu des rôles supplémentaires ajoutés à titre posthume, et certains d'entre eux ont été boulonnés en dehors du modèle de sécurité de base (parce que le rôle a été ajouté dans un contexte opérationnel différent, par exemple avant le web).

Nous utilisons donc des identifiants locaux de session synthétiques car ils cachent autant que nous pouvons nous en sortir.

Il y a aussi le problème des champs de clé non entiers, ce qui peut être le cas pour les valeurs énumérées et similaires. Vous pouvez essayer de nettoyer ces données, mais il y a de fortes chances que vous finissiez par devenir de petites tables de dépôt .