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 de sécurité, mais j'ai du mal à comprendre pourquoi.
Des opinions ou des liens sur 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=123, Vous obtiendrez une page d'erreur. Sinon, L'URL elle-même devrait ê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 valide pour 1 heure et peut seulement être utilisé une fois.
EDIT (mois plus tard): ma pratique préférée actuelle est d'utiliser des UUID pour les ID et de les exposer. Si j'utilise des numéros 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.
7 réponses
Compte tenu des conditions appropriées, exposer les identifiants n'est pas un risque pour la sécurité. Et, en pratique, il serait extrêmement fastidieux 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 fait dépend de la plate-forme et du framework 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 s'assurant non seulement que l'utilisateur dispose de l'autorité pour l'opération, mais aussi 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 gestionnaires peuvent donner soulève, mais au-delà, vous devez vous assurer que l'employé appartient au département du gestionnaire particulier.
- 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 une" sécurité en profondeur", si vous souscrivez à cette notion. Un endroit où les identifiants imprévisibles sont une nécessité, cependant, est dans les ID de session ou d'autres jetons d'authentification, où L'ID lui-même authentifie une requête. Ceux-ci devraient être généré par un RNG cryptographique.
Cela dépend de ce que représentent les identifiants.
Considérez un site qui, pour des raisons concurrentielles, ne veut pas rendre public le nombre de membres qu'il a mais en utilisant des identifiants séquentiels le révèle de toute façon 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à.
La pensée générale va dans ce sens: "divulguer que peu d'informations sur le fonctionnement interne de votre application à tout le monde."
Exposer l'ID de la base de données compte comme 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 entrer dans une base de données qu'il n'est pas censé voir?
Alors que pas un sécurité des données risque c'est absolument un business intelligence sécurité risque car il expose à la fois la taille et la vitesse des données. J'ai vu des entreprises être lésées par cela et j'ai écrit sur cet anti-modèle en profondeur. Sauf si vous construisez juste une expérience et pas une entreprise, je suggère fortement de garder vos identifiants privés hors des yeux 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 ID de base de données. La fuite est beaucoup moins dangereux.
Si vous utilisez des ID entiers dans votre base de données, vous pouvez faciliter la visualisation des données par les utilisateurs en modifiant les variables qs.
Par exemple, un utilisateur peut 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 id de base de données à votre client, vous êtes obligé de vérifier la sécurité dans les deux cas. Si vous gardez les id 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 ;) ce Peut être le cas dans votre application, mais je n'ai jamais vu un système back-end aussi cohérent dans toute ma carrière. La plupart d'entre eux ont des modèles de sécurité qui ont été conçus pour 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 possible.
Il y a aussi le problème des champs clés non entiers, ce qui peut être le cas pour les valeurs énumérées et similaires. Vous pouvez essayer de désinfecter ces données, mais les chances sont vous finirez comme peu de bobby supprimer des tables.