https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206
Bug ID: 39206
Summary: Koha improperly tries to remove foreign cookies on
logout (and in general the cookies aren't actually
removed, but set to empty values)
Change sponsored?: ---
Product: Koha
Version: 24.05
Hardware: All
OS: All
Status: NEW
Severity: minor
Priority: P5 - low
Component: Authentication
Assignee: [email protected]
Reporter: [email protected]
QA Contact: [email protected]
CC: [email protected]
So Koha tries to remove all cookies on logout apparently, even if they don't
belong to her. It does so improperly though, only resulting in a new cookie
being created.
So we have Koha's CGISESSID on opac.library.com and then WEB360SESSID on
.library.com (ie. library's main site, that set the cookie on subdomains,
because the main site also has some sub-domains).
With the above, removing such a cookie is NOT EXPECTED, because logging out
from Koha will interfere with independent unrelated sites on other subdomains.
Koha ideally SHOULD NOT try to remove cookies from a different domain. The
problem is, the cookies are innocently sent like this:
Cookie: WEB360SESSID=ab2e1sngdb7odgfh68h1vp4j8l;
CGISESSID=f4b8837f0bb7040ac96c2c9361cdcc02
So how can we even tell if a cookie is to be removed or not???
Anyway what Koha tries to do is:
set-cookie: WEB360SESSID=; path=/; secure
set-cookie: CGISESSID=7b5138e06ed10fd6c11e4c8d5de73c73; path=/; secure;
HttpOnly; SameSite=Lax
Well, this simply ends up creating a brand new new empty WEB360SESSID cookie on
opac.library.com, while the cookie at .library.com remains intact, which is
obviously a broken behavior.
The actual removal attempt happens here it seems, just as some initial pointer:
https://github.com/Koha-Community/Koha/blob/a524d94abb9b3634ed92186e94d68fdb7db1d50e/Koha/CookieManager.pm#L107-L114
But we should abuse the fact that Set-Cookie defaults to the current subdomain,
and use Max-Age=0 to immediately delete the cookie (this is the other side of
the coin, current behavior won't remove the cookie, it will just set it to
empty value with indefinite expiration!). This way we'd both improve the
behavior by actually cleaning up the cookies, and still not making Koha end up
overreaching what it might remove, given there's no way to tell from Cookie
header what subdomain the cookie was set for.
Of course if someone wanted to push another avenue of removing cookies of
higher-level domain, they'd need to use JavaScript to do that probably. But
they shouldn't, since Koha shouldn't touch other sites, period.
Also the comment in linked code is: "-expires explicitly omitted to create
shortlived 'session' cookie"; and that's wrong because a session could last for
months or years. It's not said that the browser will clear it on its restart
either.
Another cherry on top: path also isn't set on clearout. This will also miss
clearing out some cookies, even ones on the same subdomain. See:
https://stackoverflow.com/questions/20320549/how-can-you-delete-a-cookie-in-an-http-response
RFC 6265:
> Finally, to remove a cookie, the server returns a Set-Cookie header with an
> expiration date in the past. The server will be successful in removing the
> cookie only if the Path and the Domain attribute in the Set-Cookie header
> match the values used when the cookie was created.
But now that I think about it, you don't get path in Cookie header either. Uh,
so I guess JavaScript cookie cleaning it is then?
Okay some short summary TLDR:
Koha tries to "remove" a cookie by setting it to an empty value, but it fails
in that:
- no Max-Age=0 is set, meaning a cookie with empty value is created instead,
indefinitely (possibly a new redundant one, as in next point)
- no Path or Domain are passed, meaning that the cookies with these set to
non-default values will not be cleared out (and a new empty cookie will be
created instead, without touching the cookies that we want to remove)
- different Domain is expected to NOT be cleared out, as that's another site
than Koha and we cannot interfere with that
- different Path is within Koha subdomain, so not clearing it is problematic
in regards to something like Bug 29956
--
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.
_______________________________________________
Koha-bugs mailing list
[email protected]
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
