Does MongoDB support Cell Level security? I have found a few references claiming that it does (as of MongoDB 2.6), but I cannot find anything to verify this. I was hoping that if MongoDB did support this that I could find something in the documentation referencing this, but I have not.
If this is supported, do you use roles to handle this?
I do not even understand how "cell based security" really fits into the MongoDB model since documents are stored as JSON.
I am told that the application is essentially identical to the governments way of handling classified materials. I might have something "business sensitive" that only a person with an "employee role" role could access. I might also have project level roles, or even a manager for that project to limit what is seen.
Any help, pointers, or links are appreciated.
MongoDB has field-level access via $redact. It isn't as secure as Accumulo's cell-level security because it isn't enforced by default. Read more here, https://docs.mongodb.org/manual/tutorial/implement-field-level-redaction.
Related
I started working on a small POC and decided to give Sails.js a try :)
Part of the POC we wanted to use DynamoDB since the project will eventually involve high scalability and we're not looking to hire full-time MongoDB expert at this point.
We used the module: https://github.com/gadelkareem/sails-dynamodb
Problem is there is no documentation and the module does not even work...
It seems the sails ORM is not ideal for DynamoDB and requires writing custom DB services. Does anyone have experience with this?
I was very excited to come across Sails but if it won't let us play nice with DynamoDB then it might very well be out as an option to us....
Anyone have experience with this or maybe something I'm missing?
One of the important plus of vogels is excellent documentation.
Sails-dynamodb adapter based on the vogels, but not all features are implemented in sails-dynamodb adapter. For example, vogels has Expression Filters.
Vogels able to create tables. Adapter can't. An adapter needs duplication table schema in sails files and dynamodb shell.
Vogels has some own types, such as uuid type, StringSet, NumberSet, TimeUUID. (Adapter can use it too, if includes Vogels and Joi lib)
Vogels and adapter have the same query (create, update, delete, find) capabilities.
Adapter allows without changing the code switch to another data base. Adapter encapsulates establishment of connection to database.
Conclusion - for most purposes this adapter is suitable for the work and do not need to work directly with the Vogels
Sails comes loaded with an ORM called "Waterline". There are some official waterline plugins such as mongodb, postgresql, mysql and then there are some unofficial ones created by the community. I'd assume right now that Dynamo is in the latter category since I have not come across it before. However, with that being said I would not take this experience as a reason to ditch Sails.js.
Sails.js is built with the intention that all of its components can be swapped out, this means you are not tied to a specific template engine, authentication libraries etc. and including your ORM choice.
Waterline is still being actively developed but it is sat at v0.12.1 as of writing this response. It isn't fully there yet so there will be the odd issues still around!
My recommendation? Take a look at swapping out waterline for a different ORM. Keep the flexibility Sails gives you and change out the component that doesn't meet your criteria. There are still many benefits to Sails you can utilise.
Vogels might be worth checking out: https://github.com/ryanfitz/vogels
Turning off waterline: Is there a way to disable waterline and use a different ORM in sails.js?
I'm bulding a small web application using mongodb and just thought if it's a good practice to show mongoIds publicly, in urls for example.
Now I'm using the following url structure for user profiles: http://example.com/user/MONGOID
Does this have any security flaws or is it discouraged in some other way?
The answer depends on many of things...
Using an ID in a URL is generally a bad idea. According to OWASP, it ranks #4 in the top 10 web security vulnerabitiy list. But using it will not ruin your project.
To prevent the security vulnerability, you must either :
Use it only on data that is public (like StackOverflow profiles)
Have some code intercept the request and validate that the user has the rights to see the resource (a profile, a page, a document, etc.)
Using _id It also ties your public URL to the back-end. You will need some conversion if you change database technology. Or maybe you will need to run some changes that will result in the object being destroyed and created again, but with a different _id, like merging databases or something. You don't want your URL to change because of that.
Another thing is that _id does not have a good spatial distribution. It does not make a good sharding key. Being derived from a time stamp, all _id are close together, linear if you will. They will tend to go in the same shard (Mongo will spread them later, but you want a key that has high cardinality).
So I prefer to pay now, and use a id field that is private to the application from the start. You can store it in the _id field if you want, but consider adding another key to your document, index it, and use that in your URLs.
No it does not have security implications.
All the person would be able to do is to guess the Id of some user or to try to go through all Ids to get all users of the system.
Take stackoverflow as an example. They have the same pattern as you: http://stackoverflow.com/users/352959 this is 352959 is you and there is nothing bad with it. The only thing that whenever you will enter this in your browser you will be redirected to http://stackoverflow.com/users/352959/king-julien.
I can try to iterate through these numbers and the next guy is http://stackoverflow.com/users/352960 but all I can found is that this is some john. And surely http://stackoverflow.com/users/1 is the creator of the resource.
I've been told that it's bad to expose database internals but I've started noticing lots of relatively high profile sites doing it, e.g. Chartboost and ServerDensity both expose the MongoDB document _id field in their URLs.
Can someone shed some light as to why that's bad to do? The only thing I can think of is that it's bad for SEO because they're not human readable URLs, but is this even true?
By "exposing database internals" I understand stuff like exposing the database server to the internet or letting user run arbitrary queries. This stuff is unquestionably bad. Or, if you somehow expose your database schema, a malicious user can use this to his advantage.
Using object ids in urls is fine. Humans do not memorize urls anyway, and search engines don't care if link to a post is made of post slug or post id.
Even stackoverflow show its database ID-s in URL. It could be surrogate key or natural, anyway you have to identify resource somehow. Basically, every single site use some kind of identification in URL, usually PK. Why do you think they use MongoDb ? It could be even relation database with GUID instead of Long PK
Even if you show someone database schema, nothing will happen, until you are protected from sql-injection.
Can you have collection level permissions in MongoDB? Similar to table level permissions in a SQL database?
This is the only thing I could find on it. Looks like an old ticket.
https://jira.mongodb.org/browse/SERVER-1105
For anyone coming to this late (like I did), MongoDB now has support for collection-level authorization.
See: http://docs.mongodb.org/manual/core/collection-level-access-control/
Nope, not yet, MongoDB access control is currently only available at the database level. Depending on your requirements, it might be an option to implement a security model in application code that controls access down to the collection level.
Document databases that support REST-style JSON over HTTP access seem ideal for supporting AJAX-rich applications where the browser is making direct calls to the database, bypassing the traditional web server / application logic components. An example of this might be retrieving user preferences once a user has been authenticated. (BBC Homepage might be a good example of this, prior to crashing under the load!)
The problem with this scenario is the security issue - if a user is authenticated using a web server (e.g. basic forms authentication), how is this identity carried over to the document DB. Is the only answer to proxy all requests to the DB through the web server anyway - i.e. secure the document DB so that there is no direct external access?
This seems to make most sense, and is the easiest to implement, but I was wondering whether anyone out there had an experience and / or advice on using document dbs in a heterogeneous environment?
This probably differs in every database you mention. Here's how it works in CouchDB.
CouchDB allows you to manage users and roles.
You can use the validate_doc_update function in your design documents to restrict document creation/update. For example, you can write a validation that denies document update to anyone but its author.
To restrict who can read documents from a database, you can edit the /db_name/_security document and list the users or roles.
However, I don't think you can make the read access more granular (i.e. allow a user to read only the documents they created).
To achieve that, you have to put the CouchDB behind a proxy and use views to serve the documents to authenticated users. You can still use CouchDB user management this way. The proxy just hides the direct access to the database.
For more detailed info, check the security overview on CouchDB wiki, the security chapter of the Relax book and this short screencast.
Well, I only have experience with CouchDB, but hope I can help you nonetheless.
CouchDB has a validation process built-in, you write your validation rules in javascript, and have access to the group in which the current user is. It's all handled by CouchDB itself basically, you don't have to care how you get to login information.