probably added soon :
> - insecure use of databinding.
> frameworks like webwork and spring come with databinding mechanisms that automaticly bind form fields to beans using reflection. which is great and all but you have to be very carefull that users cannot set values they aren't supposed to be able to set, say a lastModifiedBy field. so you have to explicitly disallow this in code. As I recall xpetstore has / had (haven't checked the recent version) some huge problems in this regard.
Interesting thought, but I'm not sure how much this occurs in real applications. I don't know about WebWork and Spring, but using Tapestry, you can't force a change to an arbitrary object property. Even Struts will have an ActionForm as a kind of isolation layer between the incoming query parameters and the objects that are ultimately updated.
For your scenario to work, it requires what I call an "orchestrated coincidence". For example, you could imagine a servlet that updates a particular object and expects the query parameters to be the names of properties of the object to update. The orchestrated coincidence would be that the form control element names match the property names of the bean. The security issue would be passing additional query parameters ("lastModifiedDate" for example) that force additional properties to be changed beyond those intended in the form.
Again, Tapestry, Struts and other frameworks I'm familiar with don't behave in this way at all. In Tapestry, a specific component will edit a specific property of some object (it's all connected together using OGNL). The form element name is arbitrary (possibly generated automatically by the framework). There's no way for a client to "force" an update to some other object property.
Using Struts, you could force the update of additional properties to an ActionForm instance, but the ActionForm is generally not the data object persisted to a database, and explicit code moves data from the ActionForm to the data object.
There are always holes; for example, it is common to include a hidden field in a form to identify the object to be editted (i.e., store the primary key). A clever hack could submit a form with this value changed. An insecure application might trust that the primary key provided in the form submission is ok to update ... a secure application will double check.