MongoDB: is it safe to use document's ID “in p

问题:

I really like MongoDB's automatically generated ids. They are really useful.

However, is it save to use them publicly?

Let's say there is a posts collection, and the /posts page that takes id paramater (something like /posts/4d901acd8df94c1fe600009b) and displays info about it.

This way the user/hacker will know the real object id of the document. Is it okay or is it not secure?

Thanks

回答1:

The ObjectID documentation states that the automatically generated IDs include a 3-byte machine ID (presumably a hash of the MAC address). It's not inconceivable that someone could figure out things about your internal network by comparing those three bytes in various ids, but unless you're working for the Pentagon that doesn't seem worth worrying about (you're much more likely to be vulnerable to something more boring like a misconfigured Apache).

Other than that, Epcylon's right; there's nothing inherently insecure about exposing ids through URLs. Whether it's ugly is another matter, of course. You can base64 them to make them shorter (been thinking about this myself), but then there's the weird fact that they're all about half the same.

回答2:

I have no experience with MongoDB in a production environment, so don't take my answer as the truth, but I can't imagine why it shouldn't be safe.

Compare to a Auto-ID type column in a RDBMS. You expose those to the outside all the time, I don't know of any reason for not doing the same with MongoDB ids.

As always, the security should be in validating your input and not letting anyone near your database without proper protection. Do it properly and it shouldn't matter if they know how to pick a particular object in your database, as they still can't do anything with it.

回答3:

I thought mongodb _id was based on a datestamp, and sever address and other things you might prefer to keep private.

If you're worried it might be worth encrypting mongoids and using the result as a client-side identifier (and then un-encrypting when requests come back in).

If the encryption key is partially based on some unique attribute of the user or session in question, that makes it difficult for users to access content when they shouldn't.

Obviously still important to validate the user by other means!

回答4:

Perhaps think of this more as a privacy than security issue.

I'm facing exactly the same issue. In storing user contributed content in web-accessible directories based on the Mongo-generated ID, there's a risk if those IDs are predictable that one user could access another user's content.

I think the advice of others is the right route: knowing the URL of user-specific private content shouldn't be enough to access it. An attempt to access should check the matching user is making the request.

I intend to do this in Symfony2 by storing the user content outside of the web root, then allowing access to it via a new route/Controller which before passing the response will validate some identifying information about the user.

回答5:

It's not any more unsafe that using the value of auto increment id from MySql. It's not a security breach in any way.

回答6:

1. If id gives link to "unlisted" content that requires only link - it's privacy issue.

2. If id gives a link to content that is under user login - not a problem.

No matter if it's MongoDb, SQL or any other id. Id is the key to data. If this key is only thing you need to view content that you should not - that's an issue. For such situation - generate unguessable id.