Many people consider this is not new. But there is a security advisory out for spring users.
http://www.springsource.com/securityadvisory
Quote:
For applications that bind request data to presentation-layer "form models", this is unlikely to be a problem since there is a one-to-one correspondence between a form backing object and a set of allowed request parameters. This issue is only relevant for applications that bind directly to a domain model which exposes properties that should not be updated by the client.
To understand it more clearly, look at an Example:
http://www.celerity.nl/blog/2008/04/security-implications-of-the-spring-databinder/
This is however an advanced usecase. If you are directly binding model to form objects you have a major design issue.
If you observe carefully, There is another case that we dont often remember. Most Web apps have CRUD jsps and the Update jsp will generally include the id of the model that is being edited. Most times, The only security is that edit url is protected. But still, if a malicious user logged in, he can manually edit the attributes to update the model, EVEN IF it DOESNOT belong to him. say a CreditCard / Address Object in db.
So What is the solution? When you have user secure model. keep the user info (acct # or user id) at the time of *login* in session. And use that for each call that you update The CreditCard or Address.
Bottom line is, if a sensitive data is being Cruded, not only does the user needs to be authed, each request needs to be re-validated for ownership in some way.
http://www.springsource.com/securityadvisory
Quote:
For applications that bind request data to presentation-layer "form models", this is unlikely to be a problem since there is a one-to-one correspondence between a form backing object and a set of allowed request parameters. This issue is only relevant for applications that bind directly to a domain model which exposes properties that should not be updated by the client.
To understand it more clearly, look at an Example:
http://www.celerity.nl/blog/2008/04/security-implications-of-the-spring-databinder/
This is however an advanced usecase. If you are directly binding model to form objects you have a major design issue.
If you observe carefully, There is another case that we dont often remember. Most Web apps have CRUD jsps and the Update jsp will generally include the id of the model that is being edited. Most times, The only security is that edit url is protected. But still, if a malicious user logged in, he can manually edit the attributes to update the model, EVEN IF it DOESNOT belong to him. say a CreditCard / Address Object in db.
So What is the solution? When you have user secure model. keep the user info (acct # or user id) at the time of *login* in session. And use that for each call that you update The CreditCard or Address.
Bottom line is, if a sensitive data is being Cruded, not only does the user needs to be authed, each request needs to be re-validated for ownership in some way.