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

Question

J'ai entendu dire que le fait d'exposer Id de base de données (dans les Url, par exemple) est un risque pour la sécurité, mais je vais avoir du mal à comprendre pourquoi.

Des avis ou des liens sur pourquoi c'est un risque, ou pourquoi il ne l'est pas?

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

EDIT: si l'URL est secret, il sera probablement contenir un jeton généré qui a une durée de vie limitée, par exemple valable pour 1 heure et ne peut être utilisée qu'une fois.

EDIT (mois plus tard): mon préféré de la pratique consiste à utiliser les UUID pour les Id et les exposer. Si je suis en utilisant des numéros séquentiels (généralement pour les performances sur certains DBs) Id j'aime la génération d'un UUID jeton pour chaque entrée d'une autre clé, et de les exposer.

Answer 1

Étant donné les bonnes conditions, d'exposer les identifiants n'est pas un risque pour la sécurité. Et, dans la pratique, il serait extrêmement lourde pour la conception d'une application web, sans exposer les identificateurs.

Voici quelques bonnes règles à suivre:

1. Utilisation sécurité basée sur les rôles pour contrôler l'accès à une opération. Comment c'est fait dépend de la plate-forme et le cadre que vous avez choisi, mais beaucoup de support déclaratif modèle de sécurité qui redirige automatiquement les navigateurs à une étape d'authentification lorsqu'une action nécessite une certaine autorité.
2. Utilisation programmatique de sécurité 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 donc plus enclins à faire des erreurs. Cette vérification va au-delà de rôle basé sur la vérification en assurer non seulement que l'utilisateur dispose de l'autorité pour le fonctionnement, mais aussi a les droits nécessaires sur l'objet en cours de modification. Dans un rôle basé sur le système, il est facile de vérifier que seuls les gestionnaires peuvent donner de l'élève, mais au-delà, vous devez vous assurer que l'employé appartient à la manager du département.
3. Pour la plupart des enregistrements de base de données, les conditions 1 et 2 sont suffisantes. Mais l'ajout d'imprévisible Id peut être considéré comme un peu plus d'assurance, ou de la "sécurité en profondeur," si vous l'achetez dans cette notion. Un endroit où l'imprévisible identifiants est une nécessité, cependant, est dans des Identifiants de session ou d'autres jetons d'authentification, d'où le code lui-même s'authentifie une demande. Ceux-ci devraient être générés par un chiffrement de RNG.

Answer 2

Cela dépend de ce que l'IDs.

Imaginez un site que pour les compétitions de la raison ne souhaitez pas rendre public le nombre de membres qu'ils ont, mais en utilisant séquentielle Id révèle de toute façon dans l'URL: http://some.domain.name/user?id=3933

D'autre part, si ils ont utilisé le nom de connexion de l'utilisateur à la place: http://some.domain.name/user?id=some ils n'ont pas divulgué tout ce que l'utilisateur ne la connaissez pas déjà.

Answer 3

L’idée générale est la suivante: "Ne divulguez à personne le peu d’informations sur le fonctionnement interne de votre application."

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

La raison en est 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 / elle n'est pas supposée voir?

Answer 4

Nous utilisons des GUID pour les identifiants de base de données. Les fuir est beaucoup moins dangereux.

Answer 5

Lorsque vous envoyez des id de base de données est à votre client que vous êtes forcé de vérifier la sécurité dans les deux cas. Si vous garder les id dans votre session web, vous pouvez choisir si vous voulez ou avez besoin de faire, ce qui signifie que potentiellement moins de traitement.

Vous êtes constamment essayer de déléguer les choses à votre contrôle d'accès ;) Ce peut être le cas dans votre application, mais je n'ai jamais vu une telle cohérente système back-end de toute ma carrière. La plupart d'entre eux ont des modèles de sécurité qui ont été conçu pour les non-utilisation du web et certains ont eu des rôles supplémentaires ajoutés à titre posthume, et certaines d'entre elles ont été vissés sur l'extérieur de la base du modèle de sécurité (parce que le rôle a été ajoutée dans un autre contexte opérationnel, dire avant le web).

Nous utilisons donc synthétique session id local est parce qu'il cache autant que nous pouvons en tirer avec.

Il y a aussi la question de la non-entier de la clé des champs, qui peut être le cas pour les valeurs énumérées et similaires. Vous pouvez essayer de désinfecter les données, mais les chances sont que vous finirez comme peu de bobby supprimer des tables.