Although you could use this technique (severe hacking of t:formdata) to control what ComponentAction was instantiated at what point in the form submission, the security effects of this are minimal; Tapestry includes only a finite set of ComponentAction classes and each has a very specific job; the worst that you could do would be to redirect certain property updates to certain other fields, and doing even that would require deep understanding of Tapestry and of the specific application.
More serious damage could occur if you could deploy your own .class files into the application, but in order to do that, you'd need shell (or equivalent) access to the server, which means you would already have the keys to the kingdom. There's an outstanding issue concerning this; the best security is not to encrypt or checksum the data, but not to send it to the client at all. Instead, store the bytestream on the server, and send a token to the client. This will mean smaller rendered pages, smaller requests, and (probably) better throughput along with improved security. However, managing these server-side bytestreams (knowing how long to retain them, when to discard them, and which ones are useable with with sessions) is a challenge, especially in a cluster. On Fri, Jun 20, 2008 at 12:47 PM, Martijn Brinkers <[EMAIL PROTECTED]> wrote: > Hi Howard, > > While reading through some of Tapestry's classes I noticed that > Form.java reads a byte array encoded in t:formdata and deserializes this > byte array. I was wondering whether this can be misused somehow because > it allows an external user from 'uploading' an instance of > ComponentAction that has not been instantiated by Tapestry. I tried to > see what would happen if I replaced the byte stream by a serialized > object not implementing ComponentAction, which will of course result in > a ClasscastException, but I wanted to see whether it would allow me to > instantiate a 'random' serializable object. It seems that JVM is smart > enough to check before doing the actual instantiation so that seems not > to be possible. It is however possible to instantiate a class that > implements ComponentAction even though that instance was not created by > the Tapestry application. Now I do not know if this can be misused in > some way to bypass security checks (like authorization checks) or doing > some other nasty things. > A possible solution to prevent external users from 'injecting' a byte > array would be to add something to to the byte array that allows > Tapestry to distinguish between blobs generated by the web application > itself and blobs from external sources. An HMAC is quite often used for > adding message authentication (http://en.wikipedia.org/wiki/HMAC). > > What's your view on this? > > Thanks, > > Martijn Brinkers > > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
