DO NOT REPLY [Bug 28382] New: - differentiating between hidden fields by sematics to make Tapestry more secure

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=28382>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28382

differentiating between hidden fields by sematics to make Tapestry more secure

           Summary: differentiating between hidden fields by sematics to
                    make Tapestry more secure
           Product: Tapestry
           Version: 3.0
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Framework
        AssignedTo: tapestry-dev@jakarta.apache.org
        ReportedBy: programozas@hotmail.com


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

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org