Tapestry 5
  1. Tapestry 5
  2. TAP5-111

Protect serialized object blobs from being tampered by external user

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major 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.

        Activity

        Hide
        Martijn Brinkers added a comment -
        Show
        Martijn Brinkers added a comment - My solution for this can be found at http://wiki.apache.org/tapestry/Tapestry5PreventClientSideChanges
        Hide
        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.

        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.
        Hide
        Massimo Lusetti added a comment -

        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
        Hide
        Howard M. Lewis Ship added a comment -

        MARKER: INVALID FIX RELEASE

        Show
        Howard M. Lewis Ship added a comment - MARKER: INVALID FIX RELEASE
        Hide
        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.

        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.

          People

          • Assignee:
            Howard M. Lewis Ship
            Reporter:
            Martijn Brinkers
          • Votes:
            2 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development