CODEWITHSUNDEEP
mongodbmeteor
mc9
mc9

Reputation: 6349

Is publishing a document's _id safe?

I would like to know if publishing _id of a document is safe.

I am using an analytics software to track behaviors of users, and I need to access _id on client for better context. However, it vexes me that I am publishing an internal information of a document.

All in all, being new to mongo and Meteor, I would like to make sure if this is safe. Any suggestions?

Upvotes: 2

Views: 389

Answers (4)

Sergio Tulentsev
Sergio Tulentsev

Reputation: 230336

It's quite safe. As other answers correctly stated, yes, it may contain some bits of information about your machine and server process (depending on where the id was generated, in meteor or mongodb server)

But to leverage them for any malicious actions is a tough task. An attacker pretty much needs to get inside your network to do anything. And if he's in your network, you're screwed anyway, regardless of what ID format you expose.

By any measure, ObjectId is more resilient to guesses than a regular auto-incrementing integer ids you find in other databases. And they're exposed all the time!

Note, though, that you shouldn't rely on the fact that an id is hard to guess. Protect private pages with authorization checks, etc. So that even if an attacker correctly guesses an id of a page he shouldn't have access to, he is refused the access.

Upvotes: 0

karthick
karthick

Reputation: 6168

Exposing document reference(_id is not only data , it is an reference, primary key) is not at all safe.

_id is 12 bytes which consist of

  1. 4 byte - timestamp
  2. 3 byte - machine id
  3. 2 byte - process id
  4. 3 byte - increment counter

There are possible way to find out all the details about document and collection of the database using _id.

Note: Exposing _id is not at all safe.

Scenario

Suppose your are using _id for some socket listener or emitter, Anyone can guess other _id using that particular exposed _id and emit some malicious data.

When you expose _id, It contains timestamp, so you are exposing the time of creation of that particular data.

Upvotes: -1

Tarang
Tarang

Reputation: 75945

If the document's _id is created using Meteor the document's _id is at best fully random.

It doesn't contain any information besides a reference to the document itself.

If you're publishing the document this should no reveal any further information.

Even when Meteor uses an ObjectID (Meteor generated) the timestamp and other identifiers are random too. The timestamp component is also random, as mentioned in the Meteor docs (http://docs.meteor.com/#/full/mongo_object_id)

If an _id is used that is an ObjectId generated by MongoDB externally, outside of Meteor contains information such as a timestamp and details about your server. But this should not be an issue if your app is a typical Meteor app.

Upvotes: 3

nneonneo
nneonneo

Reputation: 179422

If you're using the default ObjectId implementation, here's what you'd be exposing:

ObjectId is a 12-byte BSON type, constructed using:

  • a 4-byte value representing the seconds since the Unix epoch,
  • a 3-byte machine identifier,
  • a 2-byte process id, and
  • a 3-byte counter, starting with a random value.

There are some slight concerns here:

  • Knowing the time, machine ID, process ID and a previous counter lets an attacker plausibly guess other ObjectIds which might be used to obtain other rows from your database (if you enable any form of access via the ID, which seems possible given that you want the client to know the _id).
  • Knowing the machine identifier might allow an attacker to identify particular database servers (only relevant if they already have access to your network)
  • Knowing the PID might allow an attacker to figure out the uptime of your DB server (watching for when the PID changes)
  • Knowing the time gives the attacker the creation time of the document (only valuable if the attacker didn't already know that)

These are all fairly minor leaks in the grand scheme of things, although I usually lean towards avoiding unnecessary information leakage where possible. Consider using a non-default _id column (e.g. using a randomly-generated value), and whether you really need the plaintext _id column to be visible (maybe you can use a cryptographic hash of it instead, or perhaps you can encrypt it so that the client only sees an encrypted version).

Upvotes: 1

Related Questions