Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Baker's SSO cookie causes authentication to occur without the need for a valid Drupal session. This is by design and in the nature of how Bakery provides cross-site SSO. However, it can be exploited should someone steal a user's SSO cookie. Even if that user logs out of the Drupal site a request with their SSO cookie will authenticate.
Steps to reproduce:
- Authenticate on a Bakery-enabled Drupal site
- Save the CHOCOLATECHIP cookie (using something like the Firefox extension Cookie Exporter)
- Log out and then import the CHOCOLATCHIP cookie
- Request a page and see an authenticated response back
Bakery should associate the CHOCOLATECHIP cookie to the user's session on the master and check it during validation.
Related issues:
#1450842: Set SSO cookie only on master
#1278168: SSO cookie reset before authentication is complete on subsite
Credit to Tejash Patel for original report on this
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 1964686-bakery-cookie-session-d7-7.patch | 535 bytes | irek02 |
| #6 | 1964686.patch | 3.05 KB | drumm |
| #5 | 1964686-bakery-cookie-session-d7-5.patch | 3.04 KB | vlad.pavlovic |
Comments
Comment #1
Parveen CreditAttribution: Parveen commentedSir,kindly give credits to Tejash patel and Parveen yadav both as this is reported by both of us and if you are giving us credis then give it on drupal hall of fame if you have one.
Thanks.
Comment #2
scor CreditAttribution: scor commentedComment #3
vlad.pavlovic CreditAttribution: vlad.pavlovic commentedAttached is a patch that should fix this issue.
It adds 2 new items to the cookie payload.
1) An array of session_ids using the $base_url as index.
Since the session ID is different between servers, we need to store them all (ie: we cannot rely on just one). The logic within bakery will be updated to do the following:
i) If a session is not found for current base_url (but everything else is valid), we will allow the session to proceed under the assumption that you are a new arrival/login to this url.
ii) if a session is found for the base_url, then the session_id MUST match. If it doesn't then we deny access.
So the entire array of all session IDs now becomes part of the payload of the cookie and is pervasive across all sites (ie: we preserve the data when the cookie is rebaked).
2) We will store the IP address of the user as well and confirm that it doesn't change during the session. This will prevent a cookie from being copied from valid machine to another one, and the session being continued on the other machine (while the original session is still valid).
Comment #4
vlad.pavlovic CreditAttribution: vlad.pavlovic commentedAfter some thought and external discussions about this, it might be best to exclude the IP Address check from this patch as it doesn't really have anything to do with this issue and might cause some unwanted over-aggressive logouts.
Attached is a patch that still stores the session IDs as described above, but excludes the IP address checks.
Comment #5
vlad.pavlovic CreditAttribution: vlad.pavlovic commentedHere is another patch. Discovered an issue with using Masquerade or Devel to switch users. It would return 403s. So this patch adds the e-mail address as an additional array key when storing the session ID.
Comment #6
drumm#1450842: Set SSO cookie only on master made this patch not apply. Attached is an untested patch with the conflicts resolved. I'm guessing this might no longer work since the cookie isn't baked on subsites.
Comment #7
irek02 CreditAttribution: irek02 at Acquia commentedThis additional patch is required to prevent hook_boot from signing in users in by using a hijacked cookie.Never mind, this breaks the masquerade feature so more work needed.