You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org> on 2006/03/10 03:08:42 UTC
[jira] Resolved: (TAPESTRY-158) differentiating between hidden
fields by sematics to make Tapestry more secure
[ http://issues.apache.org/jira/browse/TAPESTRY-158?page=all ]
Jesse Kuhnert resolved TAPESTRY-158:
------------------------------------
Resolution: Won't Fix
Assign To: (was: Tapestry Developer List)
> differentiating between hidden fields by sematics to make Tapestry more secure
> ------------------------------------------------------------------------------
>
> Key: TAPESTRY-158
> URL: http://issues.apache.org/jira/browse/TAPESTRY-158
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 3.0
> Environment: Operating System: Other
> Platform: Other
> Reporter: Norbert P.
>
> I'm currently developing a very security critical web application using
> Tapestry. I would like to use the default components, not to reinvent the wheel.
> I will disable BACK button (using server side solutions), encode all links to
> prevent "trial and error", and I would like to store the rewind-related hidden
> field values in a custom location: in the session.
> There are two types of hidden fields stored in a Form (I will refer to them
> later as category 1 and 2):
> 1. Hidden fields which will be modified on the client side because of user
> interaction or browser events.
> 2. Hidden fields which are NOT intended to modify on the client side because
> the modification of them will result some server side exception or security
> risk. The following components create such hidden fields: Form, ListEdit,
> FormConditional.
> Tapestry should have some simple functionality to allow the application to
> protect the hidden fields in category 2 from talented professional hackers. I
> have the following simple idea.
> Form should have two separate method for adding hidden values: addHiddenValue()
> and addSecureHiddenValue() (this method name is only for the example).
> addHiddenValue() would be for adding hidden fields in category 1,
> addSecureHiddenValue() for adding hidden fields in category 2.
> For example ListEdit and FormConditional would use addSecureHiddenValue(), but
> Hidden would use addHiddenValue().
> The default implementation of addSecureHiddenValue() would be simply calling
> addHiddenValue() but application developers would have the possibility to
> subclass Form and provide their own addSecureHiddenValue() implementation. This
> implementation could be for example:
> - encrypt the hidden field values using RSA
> - storing them in the session (this would require some more support from
> Tapestry because in this case session attributes may act as request parameters)
> Norbi
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org