The "Secure SSO Cookie" setting ensures that anytime a SSO session is started by Drupal (e.g., a user logs in via a Drupal interface) the SSO cookie created by the module, and sent back to the browser, will have the "secure" flag set on it. It will therefore later only be sent by the user's browser over https. However, if a Drupal session is started over an insecure connection, the cookie will initially be sent to the browser in the clear, despite the fact that is has the "secure" flag.

The module simply uses setcookie() to set the SSO cookie during a Drupal-based authentication. However, if the "Secure SSO Cookie" setting is active it does not also verify if the current request is secure before calling setcookie(). The php setcookie() docs states the following about secure cookie creation:

On the server-side, it's on the programmer to send this kind of cookie only on secure connection.

The module it simply not doing that.

I'm not categorizing this as a private security issue because it can only be a vulnerability if sessions are allowed to be initiated over http. This is a condition by which session hijack risks are already inherit, and data that is equally sensitive to the SSO cookie (such as the actual user's credentials) is already flowing in the clear. This means that there is no new security vulnerability here, just the potential for some buggy business logic:

  1. If the "Secure SSO Cookie" setting and the "Log out if cookie is deleted or changed" setting are enabled together the user will be logged-in and the immediately logged-out over http (the cookie set over http will be inaccessible via http), this breaking authentication entirely.
  2. If the "Secure SSO Cookie" setting is active it's confusing that the same SSO session can be used to start separate http and https sessions in Drupal (by default Drupal tracks these as separate sessions). The "Secure SSO Cookie" setting should help enforce this separation between protocol-specific local sessions.
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rjacobs’s picture

Status: Active » Needs review
FileSize
2.86 KB

Here's a patch that should address things. It ensures that no cookie is set when the "secure SSO cookie" option is active and the connection is insecure. In fact, this patch will totally abort the remote login methods under these conditions, as there is no sense running them if we know that no cookie can be set.

Status: Needs review » Needs work

The last submitted patch, 1: crowd-force_secure_cookie-2543110-1.patch, failed testing.

rjacobs’s picture

Status: Needs work » Needs review
FileSize
3.53 KB

Looks like I mis-rolled that last patch. Anyway, this one should be corrected and also includes some slightly stricter logic such that insecure tokens set by external applications will be ignored by Drupal.

  • rjacobs committed efbd601 on 7.x-2.x
    Issue #2543110 by rjacobs: Only set secure flag for SSO cookies set over...
rjacobs’s picture

Status: Needs review » Fixed

Ok, fix now committed.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.