Exposer les ID de base de données - risque de sécurité?
J'ai entendu dire que l'exposition des ID 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 sur les raisons pour lesquelles il s'agit d'un risque, ou pourquoi il ne l'est pas?
EDIT: bien sûr, l'accès est limité, par ex. si vous ne voyez pas la ressource foo?id=123 vous 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 jeton 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 (mois plus tard): ma pratique préférée actuelle consiste à utiliser UUIDS pour les identifiants et à les exposer. Si j'utilise des numéros séquentiels (généralement pour des 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.
Compte tenu des conditions appropriées, l'exposition des identifiants n'est pas un risque pour la sécurité. Et, dans la pratique, il serait extrêmement onéreux de concevoir une application Web sans exposer les identifiants.
Voici quelques bonnes règles à suivre:
- 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 effectué 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 certaine autorité.
- Utilisez la sécurité programmatique pour contrôler l'accès à un objet. C'est plus difficile à faire au niveau du cadre. Plus souvent, c'est quelque chose que vous devez écrire dans votre code et est donc plus sujet aux erreurs. Cette vérification va au-delà de la vérification basée sur les rôles en garantissant non seulement que l'utilisateur a l'autorité pour l'opération, mais également les 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à, vous devez vous assurer que l'employé appartient au département du manager en question.
- Pour la plupart des enregistrements de base de données, les conditions 1 et 2 sont suffisantes. Mais ajouter des identifiants imprévisibles peut être considéré comme une petite assurance supplémentaire, ou une "sécurité en profondeur", si vous adhérez à cette notion. Un endroit où les identifiants imprévisibles sont une nécessité, cependant, est dans les ID de session ou autres jetons d'authentification, où l'ID lui-même authentifie une demande. Ceux-ci devraient être générés par un RNG cryptographique.
Cela dépend de la signification des ID.
Considérons un site qui, pour des raisons de concurrence, ne veut pas rendre public le nombre de membres qu'il possède, mais en utilisant des ID séquentiels, il le révèle de toute façon dans l'URL: http://some.domain.name/user?id=393
D'un autre côté, s'ils ont utilisé le nom de connexion de l'utilisateur à la place: http://some.domain.name/user?id=some ils n'ont divulgué rien de ce que l'utilisateur n'a pas déjà fait savoir.
L'idée générale va dans ce sens: "Divulguez à quiconque le moins d'informations sur le fonctionnement interne de votre application."
L'exposition de l'ID de la base de données équivaut à divulguer 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 changer l'URL pour accéder à une base de données qu'il/elle n'est pas censé voir?
Bien qu'il ne s'agisse pas d'un sécurité des données il s'agit d'un risque sécurité de l'intelligence d'affaires risque car il expose à la fois la taille et la vitesse des données. J'ai vu des entreprises lésées par cela 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 vue du public. https://medium.com/lightrail/prevent-business-intelligence-leaks-by-using-uuids-instead-of-database-ids-on-urls-and-in-apis-17f15669fd2e
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 aider les utilisateurs à 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 back-end aussi cohérent système dans 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 les identifiants locaux de session synthétique car ils cachent autant que possible.
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 vous retrouviez comme petites tables de dépôt de bobby .