Required reading for any developer working with Web Applications of any form (including both J2EE and ASP technologies, among others), the Open Web Application Security Project has released a new Top Ten list last Friday. At the very least, web application developers need to make sure this checklist of attack vectors is covered.

From the list:

1. Unvalidated Input


2. Broken Access Control


3. Broken Authentication and Session Management


4. Cross Site Scripting (XSS) Flaws


5. Buffer Overflows


6. Injection Flaws


7. Improper Error Handling


8. Insecure Storage


9. Denial of Service


10. Insecure Configuration Management

Visit the list at www.owasp.org. Be sure to have a look around the rest of the site as well--good stuff.

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.

>
> - 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.

Unfortunatly I am not familiar with tapestry so I cant really comment on it
but from your post I think I understand that it doesn't quite work like what I am trying to describe
in webwork usually the action works as the model to the jsp, so you can define
some action that has say a getter and setter for Product defined within this class, then from within the jsp you could access this object like this

<webwork:property value="product/name"/>

similarly you can do this

<form method="post">
  <input name="product/name" type="text">
</form>

webwork maps the input fields to the product class. you can even traverse object graphs like this : customer/account/userId
This is all very powerfull it saves you the work of calling the getters and setters manually for each domain object all you have to do is persist it and your done. but whats stopping a user from saving the .htm to disk, hacking in a <input name="product/modifiedBy" type="text"> and submitting the form ?
You have to check they didn't, It's just asking for trouble if you ask me, It makes it too easy to mess up.

Tapestry uses OGNL, so you would bind the value parameter of a text field as so:

<input jwcid="@TextField" value="ognl:product.name"/>

Note that you don't specify the name of the form control element, Tapestry will supply that.

From you example, it looks like an "enforced coincidence" where the query parameter name lines up with an object property (or the path to one). If that is truly how WebWork operates, then it may be exposed to these kind of issues.

Tapestry keeps the property path and the OGNL expression firmly on the server side, so there's no way a bad client can "hack" a form submission to update anything beyond what the developer has already allowed.