Details
-
Type:
New Feature
-
Status: Resolved
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 5.0.15
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
Description
Using ClientPersistentFieldStorage (t:state:client parameter) an external user can
'inject' arbitary serialiable objects.
An external user can inject for example a very big byte array consuming a lot of memory.
One solution would be to add a keyed secure hash (HMAC to be precise) to the binary blob to Tapestry can detect that the blob has been tampered with. It be nice if the packing/unpacking (currently done by Base64ObjectInputStream) would be serviced (that is make it a service) so it would be easy to override this behaviour.
Same applies to t:formdata although the impact is less because it only accepts objects implementing ComponentAction.
'inject' arbitary serialiable objects.
An external user can inject for example a very big byte array consuming a lot of memory.
One solution would be to add a keyed secure hash (HMAC to be precise) to the binary blob to Tapestry can detect that the blob has been tampered with. It be nice if the packing/unpacking (currently done by Base64ObjectInputStream) would be serviced (that is make it a service) so it would be easy to override this behaviour.
Same applies to t:formdata although the impact is less because it only accepts objects implementing ComponentAction.
Activity
The recently added ClientDataEncoder service is the hook you need to implement this. Given that, it may be that this doesn't have to be fixed in tapestry-core, but can be an add-on that provides the override of CDE that's needed.
Show
Howard M. Lewis Ship
added a comment - The recently added ClientDataEncoder service is the hook you need to implement this. Given that, it may be that this doesn't have to be fixed in tapestry-core, but can be an add-on that provides the override of CDE that's needed.
Please open a new one for 5.3 if this still applicable
Show
Massimo Lusetti
added a comment - Please open a new one for 5.3 if this still applicable
MARKER: INVALID FIX RELEASE
Show
Howard M. Lewis Ship
added a comment - MARKER: INVALID FIX RELEASE
Due to limitations in JIRA, the resolution on some issues had to be changed, as part of removing the fix release from the issue. Only issues that are actually fixed should have a fix release.
Show
Howard M. Lewis Ship
added a comment - Due to limitations in JIRA, the resolution on some issues had to be changed, as part of removing the fix release from the issue. Only issues that are actually fixed should have a fix release.
My solution for this can be found at http://wiki.apache.org/tapestry/Tapestry5PreventClientSideChanges