[SERVER-3537] Security (write-only setting for database key) Created: 04/Aug/11  Updated: 06/Dec/22

Status: Open
Project: Core Server
Component/s: Security
Affects Version/s: None
Fix Version/s: features we're not sure of

Type: New Feature Priority: Minor - P4
Reporter: Jason Voorhees Assignee: Backlog - Security Team
Resolution: Unresolved Votes: 0
Labels: query, security
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Server Security
Participants:

 Description   

Obviously Mongo isn't vulnerable to the sorts of injection that haul sensitive data off SQL databases all day, every day. However, SQL injection attacks raise a significant and broad security question: why do application servers have access to sensitive data that they don't need? Proposal:

  • Allow the user to declare a database key as "write only"
  • Queries against this key behave as normal
  • Optionally raise an error or return null on attempts to read the restricted key

This would create a strong layer of security around data such as passwords that must be written and compared but never ever read.



 Comments   
Comment by Kevin "Schmidty" Smith [ 26/Jan/15 ]

For selecting and excluding documents from queries. In the example, findOne would not return a document if the provided passwordHash didn't match. Or: imagine documents containing an Array of User role names.

{
    title: "final expenditure report",
    permissions:[ "admin", "clerical", "accounting" ]
}

With a secure index on "permissions" you could query for recent documents accessible to a specific role but not list available roles on any document.

Comment by Andreas Nilsson [ 26/Jan/15 ]

Ok I get it. We've been having discussions around different types of field-level protection mechanisms.

One clarification, what would the secure field be used for if you cannot access it from a find cursor?

Comment by Kevin "Schmidty" Smith [ 24/Jan/15 ]

Sorry, I kept back-burner-ing this because I couldn't get into the account I created this issue from.

I mean a document path. Say you have a collection Users that contains a few records:

{
    name: "Dude McManus",
    passwordHash: "gu890ew4rkj8934tkjd"
}
{
    name: "Charlie Chaplin",
    passwordHash: "phu9ft6ujrtd6igv"
}
{
    name: "Jim Jeffries",
    passwordHash: "vq3ywehiulogse"
}

Declare the "passwordHash" path as secure.

Users.ensureIndex ({ passwordHash:'secure' })

Alternately index by "passwordHash" with the secure option, to get a proper index under the constraint.

Users.ensureIndex ({ passwordHash:1 }, { secure:[ "passwordHash" ]})

Either of those options done, the secure field is projected out by default. Attempting to project it in results in a MongoError.

Users.findOne ({ name:"Charlie Chaplin", passwordHash:"phu9ft6ujrtd6igv" })
> { name:"Charlie Chaplin" }
Users.findOne ({ name:"Charlie Chaplin", passwordHash:"phu9ft6ujrtd6igv" }, { passwordHash:true })
> MongoError

Comment by Ramon Fernandez Marina [ 24/Jul/14 ]

khabok, we haven't heard back from you for a while. Are you still interested in following up with this proposal? If so, can you please review Andreas' questions above and get back to us?

Thanks,
Ramón.

Comment by Andreas Nilsson [ 13/Mar/14 ]

We are going through some old SERVER security tickets and I came across this one. khabok would you mind clarifying what you mean with database key in this context? I am not sure exactly what you are asking for.

Thanks Andreas

Generated at Thu Feb 08 03:03:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.