Using ClientPersistentFieldStorage (t:state:client parameter) you can 'inject' arbitary serialiable objects so it would be easy to 'inject' a huge byte array that consumes all memory. Securing this with an HMAC would not be that hard because it only requires changes to Base64ObjectInputStream. I think it would be even better if the 'packer/unpacker' would be a service so anyone wishing to create a new version can override it.
> Anyway, I think, "security by obscurity" not very good approach to > secure code. Cannot agree more. Martijn Brinkers On Mon, 2008-06-23 at 14:32 +0700, Ivan Dubrov wrote: > Howard Lewis Ship wrote: > > 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. > > > Could it be used for DOS attacks? For example, by forcing server to > instantiate something "heavy". > > Anyway, I think, "security by obscurity" not very good approach to > secure code. > > > 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. > > > In my opinion, signing is better, because it allows you to stay > stateless in that case, which is good for scalability. The secret key > could be generated during framework initialization, for example, so > formdata will be valid until application is restarted (which is > acceptable for most cases). > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
