Security question: how to secure Hibernate collections coming back from client to server?

Question

I've got a simple pojo named "Parent" which contains a collection of object "Child".

In hibernate/jpa, it's simply a one-to-many association, children do not know their parent: these Child objects can have different type of Parent so it easier to not know the parent (think of Child which represents Tags and parents can be different object types which have tags).

Now, I send my Parent object to the client view of my web site to allow user to modify it.

For it, I use Hibernate/GWT/Gilead.

My user mades some changes and click the save button (ajax) which sends my Parent object to the server. fields of my parent has been modified but more important, some Child objects has been added or deleted in the collection.

To summary, when Parent object comes back to server, it now has in its collection: - new "Child" objects where id is null and need to be persist - modified "Child" objects where id is not null and need to be merge - potentially hacked "Child" objects where id is not null but are not originally owned by the Parent - Child objects missing (deleted): need to be deleted

How do you save the parent object (and its collection) ? do you load the parent collection from database to compare each objects of the modified collection to see if there is no hacked item ? Do you clear the old collection (to remove orphan) and re add new child (but there is some Child that has not been modified) ?

thanks

PS: sorry for my english, I hope you have understand the concept ;)

Radii

Answer 1

The best solution I've found is to manage a DTO, manually created. The DTO sends only needed datas to the client. For each fields I want to set in ReadOnly mode, I calculate a signature based on a secret key that I send to client with my dto.

When my DTO comes back to server, I check the signature to be sure that my read only fields have not changed (recalculate the signature with coming back fields and compare it to the signature coming back with dto)

It allows me to specify read only fields and be sure that my objects are not hacked.

Radii

Answer 2

Something in your stack has to supply the logic you are talking about, and given your circumstances it is probably you. You will have to get the current persisted state of the object by reading from your datasource so you can do the comparison. Bear in mind that, if several legitimate actions can update your parent object and its collection simultaneously you will have to take great care over defining your transaction grain and the thread-safe nature of your code.

This is not a simple problem by any means and there may well be framework features that can assist, but I am yet to find something which has solved this for any real world implementation I have encountered, especially where I have logic which tried to distinguish between legitimate and "hacked" data.

You may consider altering your architecture such that the parent and children are persisted in separate actions. It may not be appropriate in your case but you might be able to have a finer grain of transaction by splitting up the persistence actions and provide child-oriented security which makes your problem of hacking a little more manageable.

Good luck. I recommend you draw a detailed flow chart of your logic before you do too much coding.

Whitsun

Hello, thanks for your response ;) All my functions are transactionals so I don't have the problem of corrupting my database. All what you said is exactly what I have in mind ;) In a majority of my used cases, I've tried to persist and merge child independently of my parent (which is cleaner and easier to secure, like you say) but in some cases, I can't (my client add a little tag, but I want to wait he saves the whole parent, and not save immediatly the tag...). This is a difficult problem... – Radii