Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-55273

cookiesecure doesn't default on

    XMLWordPrintable

Details

    • MOODLE_27_STABLE, MOODLE_28_STABLE, MOODLE_29_STABLE, MOODLE_30_STABLE, MOODLE_31_STABLE
    • MOODLE_30_STABLE, MOODLE_31_STABLE
    • MDL-55273-cookie-secure-default
    • Hide
      1. Set up apache serving on both ssl and non ssl
      2. setup a fresh moodle
      3. Confirm the default value for secure cookies is on

      With the following do a full cookie clear before each:

      1. Confirm if wwwroot is http then cookies are not secure
      2. Confirm if wwwroot is http with httpslogin on then cookies are not secure
      3. Confirm if wwwroot is https and securecookie is off then cookies of not secure
      4. Confirm if wwwroot is https and securecookie is on then cookies of not secure
      5. Confirm is wwwroot is http, and secure cookie is on, and sslproxy is set then cookies should be secure (need to setup a ssl proxy to properly test)
      Show
      Set up apache serving on both ssl and non ssl setup a fresh moodle Confirm the default value for secure cookies is on With the following do a full cookie clear before each: Confirm if wwwroot is http then cookies are not secure Confirm if wwwroot is http with httpslogin on then cookies are not secure Confirm if wwwroot is https and securecookie is off then cookies of not secure Confirm if wwwroot is https and securecookie is on then cookies of not secure Confirm is wwwroot is http, and secure cookie is on, and sslproxy is set then cookies should be secure (need to setup a ssl proxy to properly test)

    Description

      So we've just run into this bug the hard way. The cookiesecure setting isn't set, so moodle sessions are being leaked over an unencrypted network request to the http version, even though it just immediately serves a redirect back to the proper wwwroot.

      To reproduce:

      1. turn on network tab in chrome dev tools, turn on preserve log
      2. login to the secure site normally so you have a session
      3. then access the non secure version, it should served a redirect to the https version, but you can see the cookie data in the mean time

      So the things that jump out at me are:

      1) why isn't this setting on by default? If the site isn't run over https then the setting is ignored so I can't see a downside to this being on by default.

      2) Why does this setting even exist? Following on that, if there is no downside with non secure sites, and it can safely always be on, why even have the setting? I can't think of a valid use case for why you would ever want this off. It's just a big security hole waiting to happen everywhere.

      There is some overlap with MDL-50689

      Attachments

        Issue Links

          has a non-specific relationship to

          Bug - A problem which impairs or prevents Moodle from functioning correctly. MDL-50689 Improve security reporting for https settings and user enumeration risk

          • Minor - Minor loss of function where workaround is possible
          • Closed

          Improvement - An enhancement to an existing Moodle feature. MDL-42834 Deprecate loginhttps

          • Minor - Minor loss of function where workaround is possible
          • Closed
          has to be done before

          Improvement - An enhancement to an existing Moodle feature. MDL-55662 Remove cookiesecure

          • Minor - Minor loss of function where workaround is possible
          • Closed

          Activity

            People

              brendanheywood Brendan Heywood
              brendanheywood Brendan Heywood
              John Okely John Okely
              Dan Poltawski Dan Poltawski
              Simey Lameze Simey Lameze
              David Woloszyn, Huong Nguyen, Jake Dallimore, Meirza, Michael Hawkins, Raquel Ortega, Safat Shahin, Stevani Andolo
              Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:
                12/Sep/16