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).
--
WBR,
Ivan S. Dubrov
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
