7 Replies Latest reply on Apr 5, 2013 9:30 AM by harebo

    J2EE session variables & Non Random Session IDs

    AmpliconLtd1 Level 1

      Our server keeps failing our PCI compliance test due to the Session ID's being non random.

       

      Description: Web Server Uses Non Random Session IDs       Synopsis: The remote web server generates predictable session IDs.      Impact: The remote web server generates a session ID for each connection.  A session ID is typically used to keep track of the actions of a user while he visits a web site.  The remote server generates non-random session IDs.  An attacker might use this flaw to guess the session IDs of other users and therefore steal their session.  See also : http://pdos.csail.mit.edu/cookies/seq_sessionid.html        Data Received: Sending several requests gives us the following session IDs : CFID=896744 CFID=896745 CFID=896746 CFID=896747 CFID=896748      Resolution: Configure the remote site and CGIs so as to use random session IDs.       Risk Factor: Medium/ CVSS2 Base Score: 6.4       AV:N/AC:L/Au:N/C:P/I:P/A:N

       

      We are using which I though was the more secure option. Is there something else you have to do to guarentee that the Session ID's are non random or is this the Compliance test picking up on a false positive?

       

      P.S. It's a recent migration to CF10, don't know if that has anything to do with it.

        • 1. Re: J2EE session variables & Non Random Session IDs
          12Robots Level 4

          Even if you have JEE sessions enabled, CF will continue to set CFID and CFToken cookies unless you tell it not to.  It does this for use with the CLIENT scope.

           

          If you are not using the client scope for anything then you can safely tell CF to stop setting those client cookies.

           

          If you are using Application.cfc then add this to your pseudocontstructor area:

           

          <cfset this.setClientCookies = false />

           

          If you are using Applicaiton.cfm, then I begrudingly tell you to add this to your <cfapplication /> tag

           

          <cfapplication ... other settings... setclientcookies="false" />

           

           

          If you are using the client scope then you may be out of luck and will need to reimplement whatever you are using the client scope for using the session scope instead.

           

          jason

          • 2. Re: J2EE session variables & Non Random Session IDs
            AmpliconLtd1 Level 1

            Thanks, I'll give that a try.

            • 3. Re: J2EE session variables & Non Random Session IDs
              AmpliconLtd1 Level 1

              That worked so thank you very much.

              • 4. Re: J2EE session variables & Non Random Session IDs
                harebo

                I just got alerted of the same issue.


                So wait...you're saying that in order to truly be within PCI compliance, you cannot use the client scope at all?  That would really suck.  What's really nice about the client scope is that you don't have to worry about sticky sessions in an environment with multiple web servers (as long as they have a common database behind the scenes).  That's the scenario I have set up, and I cannot imagine that fundamental a change to my architecture.  Is there really no other way?

                • 5. Re: J2EE session variables & Non Random Session IDs
                  12Robots Level 4

                  Personally, I think that this warning is a false positive. CF gets flagged because CFID is not randomly generated, however CFToken (in CF9 and higher) is random (at least partly).  I cannot say for certain if the combined to values are random enough for PCI compliance, that is something you would have to ask a PCI expert.

                   

                  But if it is required that there are NO warnings in the automated test, including false positives, then no, you cannot use the client scope and be PCI complaint.

                   

                  Remember that automated tools are stupid. It is only recognizing that the CFID value is not random, even if the CFToekn value is. It does not understand that the two are related and that both pieces are rquired as part of the session token, so even if the two combined are sufficiently random, the test will always fail due to the lack of randomness in the one part of the token.

                   

                  Jason

                   

                  P.S.  You should also keep in mind that the client scope sucks. It may seem convenient, but it has enough drawbacks that it is probably not worth using. http://www.dopefly.com/pages/ColdFusionClientVariablesFinalNail.cfm

                  • 6. Re: J2EE session variables & Non Random Session IDs
                    12Robots Level 4

                    Actually, thinking about this, since CFID and CFToken are NOT being used for session management when JEE Tokens are enabled, I would think that they could safely be ignored in the PCI scan for session vulnerabilties. They are really just two cookies that happen to have the same name as CF Session Tokens (when JEE Tokens are not enabled) but they have nothing to do with session management. 

                     

                    That said, is the CLIENT scope a secondary form of session management?  If those cookies need to be protected in the same way as session tokens, then you are back to having issues with PCI.

                     

                    I have submitted a request to Adobe to clarifiy if the CFID + CFToken combination are suffiecient for PCI compliance and to find out if CFID can be made into a random LongInt instead of the not-random tiny number that it is. That of course, would not help you know, but perhaps the first part would.

                     

                    jason

                    • 7. Re: J2EE session variables & Non Random Session IDs
                      harebo Level 1

                      Personally, I use the client scope instead of the session scope so that I don't have to worry about sticky sessions.  That has always worked out nicely for me.

                       

                      I read that article you referenced, and it's got some interesting stuff.  In particular, I have seen the client scope database tables not purge as they're supposed to.  And the stuff about preparing, executing, and then unpreparing SQL statements on each request is alarming, if true.

                       

                      However, I have to say that I have never, ever, ever, ever had performance issues due to client variables.  Not once.  Whatever performance hit my application may incur from using client variables has, to this point, been completely dwarfed by the performance of the application itself.  And, c'mon, the stuff about being lazy because you don't want to spend precious engineering time worrying about something like session management (which is never going to add value to your product) rather than coding something actually useful to your end users...that seems overly harsh to me.

                       

                      I completely agree that storing client vars in the Windows Registry is bananas, as is the defualt 90 day purge limit (though as of CF 9.0.whatever, the default is 1 day, 7 hours, so clearly they've made some changes since this article was written).  But I'm loathe to throw away client-based management.

                       

                      I think, getting back to the issue at hand, that this may be a false positive.  CFID is sequential, but CFTOKEN is not; that should really be the end of the story.  I'll see if McAfee will listen.  (-;