Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2_04
    • Fix Version/s: 1.2_05-b03
    • Component/s: None
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      612

      Description

      <quote>

      I ran into an interesting security issue using JSF client-side state saving.

      Suppose you have simple form with a couple of text fields and a command button.

      Over time, you discover that link spammers are using your form to promote a
      pharmacopeia of male enhancement drugs.

      Being the vigorous Java developer that you are, you decide to add a security
      component to your form, such as Seam's CAPTCHA implementation, to prevent the
      advertisement of these superfluous medicines.

      The link spammers are wily; they don't sit around hitting the submit button each
      time they want your business. Rather, they have some automated tools that
      schedule and submit an offline copy of your web page.

      Now, what happens when the link spammers post an older version of your form,
      i.e. a snapshot of the view before you added the security component?

      If you used client-side state saving, the UI component tree was saved along with
      the HTML, so the link spammer's form submission does not contain the recently
      added security component!

      The net result is that, due to client-side state saving, the spammer can now
      bypass your CAPTCHA security component.

      I would switch to server-side state saving for security purposes, but some
      frameworks require client-side state saving.

      </quote>

      Potential solution...

      <quote>

      Encrypting client state still leaves applications vulnerable to the issue I
      described.

      Perhaps an effective solution would be to expire the view state somehow, eg. if
      the HTTP session associated with the incoming state has expired, throw a servlet
      exception.

      I'm sure a date/time token could be added to the encoded view state to track
      when the view was serialized.

      Applications could control this via web.xml, for example by specifying the
      maximum age of the view state before it is considered invalid by the server in
      way that is similar to how browsers handle expired cookies and digital certificates.

      </quote>

      Information obtained from Ian Hlavats on a TSS discussion
      (http://www.theserverside.com/news/thread.tss?thread_id=46490#237621)

        Activity

        Hide
        Ryan Lubke added a comment -

        Cleaned up description.

        Show
        Ryan Lubke added a comment - Cleaned up description.
        Hide
        Ryan Lubke added a comment -

        Created an attachment (id=523)
        Proposed Changes (ver 1)

        Show
        Ryan Lubke added a comment - Created an attachment (id=523) Proposed Changes (ver 1)
        Hide
        Ryan Lubke added a comment -

        Fix checked in. Targeted for 1.2_05.

        Show
        Ryan Lubke added a comment - Fix checked in. Targeted for 1.2_05.
        Hide
        Ryan Lubke added a comment -

        reopening to set the proper owner.

        Show
        Ryan Lubke added a comment - reopening to set the proper owner.
        Hide
        Ryan Lubke added a comment -

        Assigned.

        Show
        Ryan Lubke added a comment - Assigned.
        Hide
        Ryan Lubke added a comment -

        Closing back out.

        Show
        Ryan Lubke added a comment - Closing back out.
        Hide
        Manfred Riem added a comment -

        Closing issue out

        Show
        Manfred Riem added a comment - Closing issue out

          People

          • Assignee:
            Ryan Lubke
            Reporter:
            Ryan Lubke
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: