Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.1.1
    • Fix Version/s: 2.1.24, 2.2.1
    • Component/s: None
    • Labels:
      None

      Description

      The implementation of the flash scope in Mojarra 2.x is based on a cookie that contains an index into an application scoped map. This index is a simple integer. New values are obtained by the implementation by incrementing an AtomicInteger:

      ELFlash.java
      private long getNewSequenceNumber() {
          long result = sequenceNumber.incrementAndGet();
      
          if (0 == result % numberOfFlashesBetweenFlashReapings) {
              reapFlashes();
          }
      
          if (result == Long.MAX_VALUE) {
              result = 1;
              sequenceNumber.set(1);
          }
      
          return result;
      }
      

      This algorithm makes the index very predictable. Since the map that contains all flash data is application scoped, an attacker only needs to known an index in order to access data from random other users. As mentioned this index is very easy to guess. One scheme would be to observe the index being handed out for a particular request (say 1500), then take a slightly higher number (say 2000) and continuously poll the server using this cookie. Eventually this number will be generated server side and it's possible the attacker's request will reach the server before that of the legitimate user.

      This exploit is even more severe since all current Mojarra implementations (2.0.x and 2.1.x) contain other bugs that prevent the flash scope from being immediately expired (see http://java.net/jira/browse/JAVASERVERFACES-1751). The user has to do a couple of post backs before this expiration actually happens. This means in the current situation there's a very wide window where the attacker can access data with a guessed index.

      Since the Flash scope can contain any kind of data (like e.g. personal information, credit card details, messages, etc) this seems be a rather severe problem.

      One solution would be to use a GUID instead of a sequential number. Another solution could be to (optionally) store flash data in the HTTP session and thus piggyback on the security of the JSESSIONID.

      1. 20130620-1647-0500-i_moj_2126.patch
        161 kB
        Ed Burns
      2. 20130621-2335-0500-i_moj_2126.patch
        5 kB
        Ed Burns
      3. diffs.patch
        16 kB
        Ed Burns

        Issue Links

          Activity

          Hide
          Ed Burns added a comment -

          in progress. Encrypted value is unnecessary long.

          Show
          Ed Burns added a comment - in progress. Encrypted value is unnecessary long.
          Hide
          Ed Burns added a comment -

          checkpoint

          Show
          Ed Burns added a comment - checkpoint
          Show
          Ed Burns added a comment - Commit forward port when < http://hudson-sca.us.oracle.com/view/MOJARRA_ALL/job/MOJARRA_2_1X_ROLLING_DEPLOY/115/ > and < http://slc03qna.us.oracle.com:7070/hudson/view/Mojarra%202.1/job/2_1_x-test-gf-3_1_2_2/261/ > are clean.
          Hide
          Ed Burns added a comment -

          Looks like forward port went in clean.

          Show
          Ed Burns added a comment - Looks like forward port went in clean.
          Hide
          frederickkaempfer added a comment -

          Hello Ed Burns,

          great news that this bug is fixed! However one thing that is still missing is Cookie security:

          • If the request is secure (running over SSL) the Cookie should be set to secure. (Or else cookies from an https-only application will also be sent with every http request).
          • The cookie should be set to http only (because there is no reason it needs to be available to javascript, thus it prevents some XSS attacks).

          This would just be a simple change in PreviousNextFlashInfoManager#encode and would bring the cookie security on par with the jsessionid cookie.

          Thanks!

          Show
          frederickkaempfer added a comment - Hello Ed Burns, great news that this bug is fixed! However one thing that is still missing is Cookie security: If the request is secure (running over SSL) the Cookie should be set to secure. (Or else cookies from an https-only application will also be sent with every http request). The cookie should be set to http only (because there is no reason it needs to be available to javascript, thus it prevents some XSS attacks). This would just be a simple change in PreviousNextFlashInfoManager#encode and would bring the cookie security on par with the jsessionid cookie. Thanks!

            People

            • Assignee:
              Ed Burns
              Reporter:
              arjan tijms
            • Votes:
              12 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 12 hours, 40 minutes
                12h 40m