Announcement Announcement Module
Collapse
No announcement yet.
Entity IDs are hackable by default Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Entity IDs are hackable by default

    The default behaviour of Roo-generated entity controllers for an update (PUT) request is to read the entity ID from the "id" request parameter. This is a potential security flaw, as a malicious user with a request-editing tool such as Tamper Data can change the value of this parameter to update a different record to the one displayed by the form. Here's how to replicate this:
    1. Once only: install the Tamper Data extension in Firefox (it's useful for web development anyway, you won't regret it)
    2. Start up a Roo-generated web application
    3. Close all other tabs to minimise irrelevant requests from other apps (esp. AJAX based apps like GMail)
    4. Find an entity with more than one instance and note down the first two IDs
    5. Open the update form for the first instance
    6. In Firefox, choose Tools -> Tamper Data
    7. In the "Tamper Data" window, choose "Start Tamper"
    8. Submit the update form
    9. When you get the "Tamper with request?" dialog, untick "Continue Tampering?" and click "Tamper".
    10. The "Tamper Popup" appears; look through the Post Parameters on the right-hand side to find the "id" parameter, and change it to the ID of the second instance
    11. Click OK to allow the form submission to proceed
    12. Note that the first entity's values have overwritten the second entity's values instead of updating the first entity; in other words, the form allowed the user to update a different entity than was originally displayed
    This vulnerability is easily avoided by making two changes to the controller:
    • disallow binding of the "id" field in an @InitBinder method either by:
      • setting the binder's allowed fields to exclude that field OR
      • setting the binder's disallowed fields to include that field, AND
    • apply the @SessionAttributes("myEntityName") annotation to the controller class
    You can make these changes yourself, but it sounds like something that Roo could do by default in the BlahController_Roo_Controller aspect. Shall I log this as an improvement?

  • #2
    Hi Andrew

    You are right with your observation here. This is something that needs to be adjusted.

    Can you please copy your notes below in a Jira feature improvement ticket? I will see that I address this in the Roo 1.1 release train.

    I would strongly favour the 'allowed' fields approach as this is overall a recommended approach anyway.

    Cheers,
    Stefan

    Comment


    • #3
      Done

      Logged as ROO-614.

      Comment


      • #4
        As per over-beer discussions, we need to determine priority rules anyway when the URL indicates one ID and the form post indicates a different ID.

        Comment

        Working...
        X