goincremental / gi-security Goto Github PK

For cases where you are plugging into a legacy database that already has a role structure, allow the name of admin, restricted, sysadmin etc to be overriden by a setting. The setting name takes the form [Expected Gintellect Role Name]RoleName.

For example to override which role represents the Admin role, you would set the AdminRoleName setting.

So here is the problem, when for example we do a model.find, the object that is returned by mongoose (and passed straight through our model layer) has an update method, with direct access to the underlying database.

If an unsuspecting developer, were to say change the password on the user object, and then call update with the objects id, it would end up bypassing any useful checks the model layer was doing to protect itself.

This is too much power / responsibility for the controller, and needs to be locked down. Any methods exposed on objects that the model layer returns, must not be able to break the model.

I think that the simplest thing to do is call .toObject on the objects returned by mongoose, before returning them from the model layer. This means that there will be no functions on the objects returned to the controller layer at all.

The controllers then cannot call any methods on objects directly, but must instead use the interface provided by the model.

JSON Vulnerability Protection
A JSON vulnerability allows third party website to turn your JSON resource URL into JSONP request under some conditions. To counter this your server can prefix all JSON requests with following string ")]}',\n". Angular will automatically strip the prefix before processing it as JSON.

For example if your server needs to return:

['one','two']
which is vulnerable to attack, your server can return:

)]}',
['one','two']
Angular will strip the prefix, before processing the JSON.

This will be mildly problematic, as currently crud connects to socket.io on first initialization, which is before a user has a chance to login.

So really we need to hook into the login event on the client and only attempt to connect then.

When you logout in chrome, I'm finding that the subsequent request to /api/user is still authenticated and as such the user is logged straight back in again. Presumably cookie related, doesn't happen on Safari, so not a server side issue.

A dormant user should not be able to login to the system

We should not trust that the client has not manipulated the facebook login message to gain access to others accounts. Need to verify the hash sent with the login message against our app secret.

Needs investigating

Inactive users should not appear by default in the list of users used for assignments.